1999-02-09 18:18:34 +03:00
|
|
|
/*
|
|
|
|
|
* PuTTY version numbering
|
|
|
|
|
*/
|
|
|
|
|
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 15:33:29 +04:00
|
|
|
/*
|
2014-09-24 14:33:13 +04:00
|
|
|
* The difficult part of deciding what goes in these version strings
|
|
|
|
|
* is done in Buildscr, and then written into version.h. All we have
|
|
|
|
|
* to do here is to drop it into variables of the right names.
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 15:33:29 +04:00
|
|
|
*/
|
1999-02-09 18:18:34 +03:00
|
|
|
|
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 17:57:31 +03:00
|
|
|
#ifdef SOURCE_COMMIT
|
|
|
|
|
#include "empty.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
2014-09-24 14:33:13 +04:00
|
|
|
#include "version.h"
|
1999-02-09 18:18:34 +03:00
|
|
|
|
2016-04-07 09:52:55 +03:00
|
|
|
const char ver[] = TEXTVER;
|
|
|
|
|
const char sshver[] = SSHVER;
|
2017-01-21 17:55:53 +03:00
|
|
|
const char commitid[] = SOURCE_COMMIT;
|
2001-03-15 15:15:02 +03:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* SSH local version string MUST be under 40 characters. Here's a
|
|
|
|
|
* compile time assertion to verify this.
|
|
|
|
|
*/
|
|
|
|
|
enum { vorpal_sword = 1 / (sizeof(sshver) <= 40) };
|