[p4] automatically building in the latest changelist number f or a build

Ivey, William william_ivey at bmc.com
Thu Mar 24 08:02:37 PST 2005

> -----Original Message-----
> From: Leo Zelevinsky [mailto:leo.zelevinsky at gmail.com]
> It feels certain that others have run into my design problem before
> and I don't want to reinvent the wheel.
> We have recently moved from SourceSafe to Perforce. Recently, we have
> decided to adopt the perforce strategy for numbering versions - so
> that in the version label is built in the latest changelist that was
> used in making the build.
> I am wondering what would be the best way to make this as foolproof as
> possible. For instance, I'd like our Help/About box to display the
> latest changelist checked in when this code was last synced. What's
> the best way to get at that information?

Our build scripts use a build number based on the highest synced change
in a branch, prefixed with a code for the branch. This, along with
version numbers, build dates and the build year (for copyright notices)
are in the environment and available to ant and make, either directly or
through various properties files (we generate files for c shell,
bourne shell/C/C++, and java .prop files). For C/C++ the make file
usually generates a version.h file on the fly - so the owner of the
Makefile can control its format to their taste. Our generic one looks
like this:

    # Build information file for Bourne shell, C/C++ or InstallShield Pro
#define BLD_REL "5.0.01"
#define BLD_NUM "1126354"
#define BLD_PATCH "0"
#define BLD_DATE "20-Mar-2005"
#define BLD_TIME "11:26"

Anyway, the branch code + bulid # works well for most major
builds - knowing the build # and product we can reproduce
it easily (in the sample above, the change # is 26354). For
builds where there are gaps in the changes (we didn't just
sync to the top of the heap), we generate a label, usually
with the build# as part of the name.

So, in practice, to reproduce a given build, we check for
a label matching the build #, and if that doesn't exist,
we sync the changelist embedded in the build #. -Wm

P.S. We've learned that build #s should never start with 0,
there's always someone who will treat it as a number and it
often gets seen as octal if it starts with 0.

More information about the perforce-user mailing list