[p4] automatically building in the latest changelist number for abuild

Grills, Jeff jgrills at soe.sony.com
Wed Mar 23 19:13:28 PST 2005

I've seen a couple responses to this issue, but none that address the
problems that we had to face when implementing the same sort of thing.

We do massively multiplayer games, and have multiple executables that
have to get built from our source tree when files update.  In the
beginning, we had a header which exposed something like "extern char
const * const VersionNumber;", and we would regenerate the corresponding
source file.  At least using the source file for the version number
reduces the number of files that have to get rebuilt when the version
number changes.

Unfortunately, this didn't work out too well for us.  As I said, we have
multiple executables that get built from the source tree.  If we
discovered a client bug in test and submitted a fix to perforce, the
build system would end up recompiling the version number file and
relinking every single executable, both client and server.  Because
every binary image was different, the deployment team (which was
actually also the build team) would have to resync all the server
executables out to the server farms, which would increase downtime and
therefore decrease testing time.  If there was a fix to the server, the
client would change due to the version number file, and we'd have to
repatch the client to all the customers.  Admittedly in this case the
delta patch would have been very small, but as we only keep a certain
number of revisions for deltas on the patch server, this pushed deltas
off the patch server more quickly, so it was still an unacceptable

Our final solution was a bit of a hack, but it really solved our
problems.  The version number source file contains a very well defined
string (something like "ApplicationVersionMarker 12345678901234567890").
When the build system was done compiling the executables, it would look
to see which executables were recreated during the build process (the
build script is in perl, and in perl files changed since the build
script started would have a negative file modification time), search the
binary images for this specific text string, and replace the text with
the version number as sync'd from perforce.  We were careful about this
binary modification process - we'd search the whole executable and make
sure the marker was found exactly once.  As I said, only executables
that actually changed during would be re-branded with the new version
number, which allowed the build and deploy team to know exactly what
executables needed to be pushed out where.  We also embed the version
number for the client in the Windows resource information, and used a
third party tool called Resource Tuner Console
(http://www.heaventools.com/command-line_resource_editor.htm) to brand
the version number into the resources after it was built.  Perhaps
Resource Tuner Console could update a string for your "About Box" as

As someone else pointed out, this doesn't address the cases where the
build team didn't sync the entire depot to a changelist.  In that case,
we would brand the executable with the top-most changelist and some
other marker (.a, .1, whatever), and the build system would run a "p4
files //...#have" and output that to a file so that we would know
exactly what source was used to build the version number.  This could
have been a label, but we had some decent reasons not to bother with the

I hope this is useful for others...


More information about the perforce-user mailing list