> 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
I use all three, in differing projects,
and at differet times on the same project.
I tend to use (1) for quick and dirty developer testing.
Building for whatever the local machine is.
I've used (2) in the past for multiplatform/multioption.
I recently abandoned such a build system, because
VPATH works best with flat directories, all the object
files in one place, and I have several .c / .cc files,
in different directories, with the same name. I.e.
the source and object files are disambiguated by
directory path. A bit more work than standard VPATH
Makefiles is needed.
Both (1) and (2) I'll build in dirty sandboxes,
for developer testing.
Regularly I'll clean the sandbox. I have a
"make cleanest" rule that removes all files
not in a Bill Of Materials (BOM) manifest
file. I'll use this and/or inspection of cvs update
for M, A, R and ?
Pretty regularly I'll extract a new view,
usually via a fresh "cvs co -d XXX Project",
rarely via cvs export. Frequency depends on
what is being integrated; usually 1-3 times per week.
I used to do it more than daily, but slow C++ compilers
have discouraged that. On other projects cron did
this for me, but I'm not doing that right now.
