RE: reformatted: RE Build Processes

[Cameron, Steve]

Teala Spitzbarth (address@hidden) wrote:

> Part of the reason we always do formal builds pulled from a tag 
> is that we use the $Name$ keyword in ident commands to allow for
> identification of key binaries.
>
>  *Gotcha*: using $Name$ means that cvs will experience 'merge
>  conflicts' on doing updates in any working copies pulled from 
>  a tag 

The way we handle this is not to use $NAME$, or 
any other keywords, but instead have the build 
process do something like

        sed -e "s/BUILD_TAG/""$REAL_TAG""/" < \
                version.h.template > version.h

And version.h.template (which is in CVS) 
contains something like

        static char *cvs_tag = "BUILD_TAG";

(and you could put in the magic string that the 
"what" command looks for, of course, or just run 
"strings" on the binaries...)  For experimental
builds, REAL_TAG can have a default value 
"experimental"  or something.

So the build process makes "version.h" on the fly.  
Then all the key binaries have source code like:

#include "version.h"

(C code, but of course the same idea applies to 
other languages.)  This avoids the spurious merge 
conflicts completely, as the only source file which 
gets changed with the version information is 
"version.h", which is not in CVS at all.

Also, you mentioned "cvs update -A", and some of the 
pitfalls... another one: it not only takes you the trunk 
but also blows away any sticky options (e.g. -kb) that 
might otherwise be set.  Not a problem for us here 
since we only use the trunk as a place to create branches 
from and merge branches to, but if we did development 
on the trunk it might be a problem once in a while.   

-- steve