[p4] Changelist number in versions

[Ivey, William]

> You might want to put your output in a different
> location that the source, that way, all the builds you do won't
> "pollute" your source tree.

That's what we do. It goes under a special include directory that
is not under the source tree. (In general, although a given project
may have special requirements which just can't be met that way.)

Aside from the build number, we include other things as well for
consistency across the build. Here's a sample:

#define SKIP_THE_SHELL_JUNK
#ifndef SKIP_THE_SHELL_JUNK
    # Build information file for Bourne shell, C/C++ or InstallShield
Pro
    BLD_REL="7.2.00"
    BLD_NUM="1542070"
    BLD_PATCH="0"
    BLD_DATE="17-Dec-2007"
    BLD_TIME="18:15"
#endif
#define BLD_REL "7.2.00"
#define BLD_NUM "1542070"
#define BLD_PATCH "0"
#define BLD_DATE "17-Dec-2007"
#define BLD_TIME "18:15"

For Java we put the same information in a properties file.

-Wm






-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of
alex.pavloff at l-3com.com

We use the changelist in our builds, mainly by modifying our build
process to automatically generation your "version.h" on every single
build, with something like:

P4_REV = $(word 2, $(shell p4 changes -m1
$(PROJECT_ROOT)\...@$(CURRENTCLIENT) ))

The version.h doesn't get checked in, and you build your final release
when there's nothing open for edit (you could add something into the
build to check that).

Works well for us.  You might want to put your output in a different
location that the source, that way, all the builds you do won't
"pollute" your source tree.

	-Alex