On Mon, Nov 26, 2001 at 01:46:20PM -0500, Joey Hess wrote: > Adam Heath wrote: > > Never build a full release from the cvs work directory. Always cvs export > > to > > another directory first. > > > > Doing test builds from the cvs work dir is fine. But do final releases > > from a > > temp dir. Sometimes, the cvs work dir is poluted, and having a fresh > > checkout > > is safer for repeatability. > > It is pretty hard to cvs export when you are not on the net, or when you > are behind a dog-slow dialup connection and a cvs export would take an > hour. > > Any "pollution" of a cvs working directory should be easily detectable, > and is no more likely than "pollution" of a directory that is not > managed by cvs. Just make sure that your build script deals with .#* > files at the same time it is dealing with *~ files and so on. The real > problem to watch out for if building in this way is that any source > files you add to the tree are included in the tarball, but may not yet > be in cvs, which could result in an inconsistent tagging of your build > tree. > > I used to have my build scripts copy the working directory to a > temporary directory, remove all the cvs cruft from there, and build > there (poor man's cvs export..), but the big problem with building in a > temporary directory, no matter how it's generated is that this doesn't > let you fully test your debian/rules clean. I found that my packages > were accumulating many bugs in the clean rule and so I stopped building > in a temporary tree. > > BTW, see bug #75947 >
If the program uses automake (and the author worked good ;)), a 'make dist' suffices to build up a distribution tar.gz file, ie without CVS/RCS and other trash in it, starting from the development tree. My programs do this when I play as The Upstream Man :) -- Francesco P. Lovergine
