This is a "nuts and bolts" talk about several useful tricks for doing build and configuration work using Perforce. Although the tools used are Perforce-centric, there’s no reason that these techniques cannot be discussed or used on other "reasonable" SCM systems.

There’s a long-standing requirement – often unspoken – for software build systems:

This often is taken to mean "compile some nonsense string, such as ‘release 1.2.1.2.1.2.1.2.5’ into the executable," which leaves a beleaguered QA or Tech Support engineer looking through external documents to figure out what files are included in that release.

Step #1: always have a ‘token’ identifying the source set for a release

There are two reasonable ways to identify the set of source files used to build a release:

Both ways work – even though the first way is easier to explain to a Perforce-naïve manager, the second is more reliable: change numbers cannot be updated after the fact, while labels can. Either way, pick a method and stick to it – the second leverages the Perforce tools a bit more effectively.

Step #2: generate that token before running ‘make’

The build script normally does three things:

Step #3: ‘make’ should use that token to create version information

For java builds, it’s straightforward to include an application inside every .jar file that’s built, which prints out the version string. For example, the file xyz.jar would contain the application xyz.PrintVersion (stored as "xyz.PrintVersion.class") that prints out:

Note how verbose this is allowed to be: if your users are GUI folks who don’t use the CLI, giving the exact commands for an excursion into the command-line realm might be helpful.

This .class file would be built as part of the "make" process, and never included in non-official builds – a red-herring version that says "I’m not an officially-built library!" might be checked in for those cases.

The definitive Java hacker will look at this and say "there are more Java-centric ways to embed version information in the ‘envelope information’ for a .jar file" and would be right. This example is used because it extends a bit more quickly to non-Java environments.

Step #4: tell QA and Tech Support to look for these tokens

If set up this way, then the command:

becomes the standard way to identify what release you’re running or what’s in an "install area" or CD-ROM ready for installation.

If you’re doing C++ work or C work, embedding the version string in a library is much harder – but it’s still possible to pass this VERSIONSTRING information to the compiler so that "programname –version" prints it out.

Another build need is to know that what is checked in, compiles. More importantly, the question becomes "does everything else continue to compile with this change included?".

A simple review script follows:

This is a running discussion on the perforce-user mailing list, and there are arguments in both directions.

There are two sets of requirements that are part of this discussion. Choose one, but not both:

In this religious discussion, it’s important to know what the goals are, and what’s realistic. One of the great truths is that Perforce is an excellent source management system, but is neither a bug database nor a backup/archival system.