It became bash-dependent in r9229 because I used a bashism to remove
the 'r' from the front of $SVN_REV, but that's not needed any more.
[originally from svn r10281]
[r9229 == bd60f2fc5b]
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]
Previously, 'configure' and its assorted machinery lived in the 'unix'
subdir, because that seemed like a clean place to keep it given that
all the other per-platform Makefiles live in their platform
directories. However, this never sat all that happily with autotools,
and even less so now that it likes to have object file pathnames
parallel source file pathnames: if you have Makefile.am refer to
source files outside its subdir as "../terminal.c" and enable
subdir-objects then any out-of-tree build calls the corresponding
object file "../terminal.o" and so your build products mostly end up
at the directory above your build dir! And as of autotools 1.14 my
previous compensatory bodge of prefixing every source file path in
Makefile.am with "$(srcdir)" has stopped working too.
So I'm giving in to necessity, and changing policy by moving the
configure machinery up to the top level of the source tree where
autotools will be less confused by it. This should not be taken as any
indication of the primacy of the Unix port, only of the recalcitrance
of autotools.
Whereas before we had a trivial script called 'configure' at the top
level that invoked unix/configure to effectively do an 'out-of-tree
build' (for make purposes) at the top level of the source tree, we now
have a similar script in unix/configure. So this _should_ make very
little difference: people who were previously running configure from
the top level should still be able to, and likewise people who were
running it from the unix subdir.
[originally from svn r10141]
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]
revision ('Custom build r1234'). Those builds were passing
'-DSVN_REV=r1234' to version.c, instead of -DSVN_REV=1234 as they
should have, leading to silly run-time version messages such as
'plink: Custom build rr9226'.
To chop the r off the front of the revision string passed in, I've
used a bashism in mkunxarc.sh. I think this is an acceptable extra
dependency.
[originally from svn r9229]
and custom svn builds should now have appropriately named Unix
source archives and installer binaries, plus .htaccess files
providing redirects to them from totally standard filenames. I
_think_ this now makes it feasible to switch the nightly builds to
using bob.
[originally from svn r7226]
rather than relying on the user to edit the Makefile. Makefile.gtk
still works as well as it ever did, but now we get a Makefile.in alongside
it. mkunxarc.sh now relies on autoconf and friends to build the configure
script for the Unix source distribution.
[originally from svn r5673]
that in turn was confusing the new doc/Makefile mechanism. Fixed the
former, and also put an additional safeguard in the latter in a
belt-and-braces sort of fashion.
[originally from svn r4806]
pad with trailing NULs, which slightly upsets old versions of gzip (1.2.4,
not 1.3.x), which upsets some of our correspondents.
Use -f to send it to a file instead. (It's not transparently clear what
happens when you mix -f and -C; I've tested this with ixion's tar, 1.13.25.)
Also add option -o to generate POSIX tar files, as for halibut/Makefile;
apparently this shuts up a `trailing garbage' error from WinZip.
[originally from svn r4429]
Simon Tatham
Ben Harris
Jacob Nevins