2014-09-24 10:33:13 +00:00
|
|
|
/*
|
|
|
|
|
* This header file provides the various versioning-related #defines
|
|
|
|
|
* for a particular PuTTY build.
|
|
|
|
|
*
|
|
|
|
|
* When my automated build system does a full build, Buildscr
|
|
|
|
|
* completely overwrites this file with information derived from the
|
|
|
|
|
* circumstances and type of that build. The information _here_ is
|
|
|
|
|
* default stuff used for local development runs of 'make'.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#define TEXTVER "Unidentified build"
|
|
|
|
|
#define SSHVER "PuTTY-Unidentified-Local-Build"
|
|
|
|
|
#define BINARY_VERSION 0,0,0,0
|
Show the git commit hash in local dev builds too.
This is perhaps the more useful end of the mechanism I added in the
previous commit: now, when a developer runs a configure+make build
from a git checkout (rather than from a bob-built source tarball), the
Makefile will automatically run 'git rev-parse HEAD' and embed the
result in the binaries.
So now when I want to deploy my own bleeding-edge code for day-to-day
use on my own machine, I can easily check whether I've done it right
(e.g. did I install to the right prefix?), and also easily check
whether any given PuTTY or pterm has been restarted since I rolled out
a new version.
In order to arrange this (and in particular to force version.o to be
rebuilt when _any_ source file changes), I've had to reintroduce some
of the slightly painful Makefile nastiness that I removed in 4d8782e74
when I retired the 'manifest' system, namely having version.o depend
on a file empty.h, which in turn is trivially rebuilt by a custom make
rule whose dependencies include $(allsources). That's a bit
unfortunate, but I think acceptable: the main horribleness of the
manifest system was not that part, but the actual _manifests_, which
were there to arrange that if you modified the sources in a
distribution tarball the binaries would automatically switch to
reporting themselves as local builds rather than the version baked
into the tarball. I haven't reintroduced that part of the system: if
you check out a given git commit, modify the checked-out sources, and
build the result, the Makefile won't make any inconvenient attempts to
detect that, and the resulting build will still announce itself as the
git commit you started from.
2017-01-21 14:57:31 +00:00
|
|
|
|
|
|
|
|
#ifndef SOURCE_COMMIT
|
|
|
|
|
/*
|
|
|
|
|
* git commit id from which this build was made. This is defined by
|
|
|
|
|
* Buildscr for official builds - both source archives and prebuilt
|
|
|
|
|
* binaries - in the course of overwriting this file as described
|
|
|
|
|
* above. But we put it here under ifdef, so that it can also be
|
|
|
|
|
* passed in on the command line for Unix local development builds,
|
|
|
|
|
* which I treat specially because Unix developers - e.g. me - are
|
|
|
|
|
* quite likely to run 'make install' straight out of their dev
|
|
|
|
|
* directory so as to use the bleeding-edge code for day-to-day
|
|
|
|
|
* running.
|
|
|
|
|
*
|
|
|
|
|
* Windows doesn't really need the same treatment, because the easiest
|
|
|
|
|
* way to install a build properly on Windows is to run the installer,
|
|
|
|
|
* and the easiest way to do that is to run Buildscr, which will
|
|
|
|
|
* populate this field its own way. It's only the Unix automake build
|
|
|
|
|
* where you might go straight from local 'make' to 'make install'
|
|
|
|
|
* without going through Buildscr.
|
|
|
|
|
*/
|
2017-01-21 14:55:53 +00:00
|
|
|
#define SOURCE_COMMIT "unavailable"
|
Show the git commit hash in local dev builds too.
This is perhaps the more useful end of the mechanism I added in the
previous commit: now, when a developer runs a configure+make build
from a git checkout (rather than from a bob-built source tarball), the
Makefile will automatically run 'git rev-parse HEAD' and embed the
result in the binaries.
So now when I want to deploy my own bleeding-edge code for day-to-day
use on my own machine, I can easily check whether I've done it right
(e.g. did I install to the right prefix?), and also easily check
whether any given PuTTY or pterm has been restarted since I rolled out
a new version.
In order to arrange this (and in particular to force version.o to be
rebuilt when _any_ source file changes), I've had to reintroduce some
of the slightly painful Makefile nastiness that I removed in 4d8782e74
when I retired the 'manifest' system, namely having version.o depend
on a file empty.h, which in turn is trivially rebuilt by a custom make
rule whose dependencies include $(allsources). That's a bit
unfortunate, but I think acceptable: the main horribleness of the
manifest system was not that part, but the actual _manifests_, which
were there to arrange that if you modified the sources in a
distribution tarball the binaries would automatically switch to
reporting themselves as local builds rather than the version baked
into the tarball. I haven't reintroduced that part of the system: if
you check out a given git commit, modify the checked-out sources, and
build the result, the Makefile won't make any inconvenient attempts to
detect that, and the resulting build will still announce itself as the
git commit you started from.
2017-01-21 14:57:31 +00:00
|
|
|
#endif
|