My curiosity is piqued by several posts recently on the subject of
builds.
(I preface this by saying that I am fully aware that cvs is not a build
tool, nor does it enforce policy, nor does it do my taxes (regrettably),
etc. etc. etc. etc. etc. etc. ad nauseam as we have all seen in the
34734983 messages per day that deal with the subject. :-))
For those of you that do run builds of your products/systems where cvs
is the underlying version control system, how many of you:
1. Run them (let's say nightly or frequently at any rate) out of a
sandbox that has been massaged until there are no modified or ? files in
it
2. Run them using make and VPATH such that the build takes place in
directory tree B, but the source is looked up via make's VPATH mechanism
from directory tree A (which B mirrors in structure), where A has been
massaged until there are no modified or ? files in it
3. Do (2) but do a cvs -export to a fresh area first
We do not do (1) because building in your source area is a bad idea if
you want to support many platforms. This practice is explained and
recommended in O'Reilly's excellent "Applying RCS and SCCS".
We currently do (2) using a homegrown build system modeled after TCCS as
outlined in the O'Reilly book (the homegrown system basically implements
TCCS in perl using cvs as the underying VC system; complete with the
robust parallel make tool). This allows us incremental builds (i.e. we
don't have to do a full export every time we want to run a simple
build).
We do NOT do (3) because we can get the same results with (2), although
the build tools have to be more careful to make sure there are no "M" or
"C" or "A" or "?" lines after an update.
My gut hunch is that people do mostly a combination of (1) and (3). I'm
trying to figure out whether (3) is an option we should move towards.
Cheers,
Laird
