[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: reformatted: RE Build Processes
From: |
Cameron, Steve |
Subject: |
RE: reformatted: RE Build Processes |
Date: |
Fri, 17 Aug 2001 09:08:31 -0500 |
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