I've shifted away from using the SVN revision number as a monotonic
version identifier (replacing it in the Windows version resource with
a count of days since an arbitrary epoch), and I've removed all uses
of SVN keyword expansion (replacing them with version information
written out by Buildscr).
While I'm at it, I've done a major rewrite of the affected code which
centralises all the computation of the assorted version numbers and
strings into Buildscr, so that they're all more or less alongside each
other rather than scattered across multiple source files.
I've also retired the MD5-based manifest file system. A long time ago,
it seemed like a good idea to arrange that binaries of PuTTY would
automatically cease to identify themselves as a particular upstream
version number if any changes were made to the source code, so that if
someone made a local tweak and distributed the result then I wouldn't
get blamed for the results. Since then I've decided the whole idea is
more trouble than it's worth, so now distribution tarballs will have
version information baked in and people can just cope with that.
[originally from svn r10262]
it's a pre-release of, and the revision number so you can tell two
pre-releases apart. I intend to use this for builds from branch-0.61
until I call it 0.62 proper.
[originally from svn r9343]
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]
a fourth class of PuTTY version tags in addition to release,
snapshot and unidentified: we now have `Custom build r1234',
indicating a build made from that SVN revision in a context other
than that of a dated snapshot. The build script generates these when
it doesn't know what else to do; `unidentified builds' will now only
occur when you run nmake from the command line.
Also, the build script now generates sensible version data in the
installer to match this. So I _think_ we should now be set to use
bob to generate installer builds of the nightly snapshots, although
of course I'll have to wait until tomorrow to test one.
[originally from svn r7211]
but since Simon's made the corresponding change to the build process, this bit
needs checking in now (it should be harmless).
(The documentation in Recipe is slightly out of date; with luck I'll be
checking in `win-versioninfo' changes soon, and I can't be bothered to
disentangle the relevant changes in the meantime.)
[originally from svn r6367]
sensibly, as a release or a snapshot or a local build. With any luck
this should make bug reporting easier to handle, because anyone who
sends their Event Log should automatically include the version :-)
[originally from svn r1003]
Simon Tatham
Jacob Nevins