The standalone separate doc/Makefile is gone, replaced by a
CMakeLists.txt that makes 'doc' function as a subdirectory of the main
CMake build system. This auto-detects Halibut, and if it's present,
uses it to build the man pages and the various forms of the main
manual, including the Windows CHM help file in particular.
One awkward thing I had to do was to move just one config directive in
blurb.but into its own file: the one that cites a relative path to the
stylesheet file to put into the CHM. CMake builds often like to be
out-of-tree, so there's no longer a fixed relative path between the
build directory and chm.css. And Halibut has no concept of an include
path to search for files cited by other files, so I can't fix that
with an -I option on the Halibut command line. So I moved that single
config directive into its own file, and had CMake write out a custom
version of that file in the build directory citing the right path.
(Perhaps in the longer term I should fix that omission in Halibut;
out-of-tree friendliness seems like a useful feature. But even if I
do, I still need this build to work now.)
This brings various concrete advantages over the previous system:
- consistent support for out-of-tree builds on all platforms
- more thorough support for Visual Studio IDE project files
- support for Ninja-based builds, which is particularly useful on
Windows where the alternative nmake has no parallel option
- a really simple set of build instructions that work the same way on
all the major platforms (look how much shorter README is!)
- better decoupling of the project configuration from the toolchain
configuration, so that my Windows cross-building doesn't need
(much) special treatment in CMakeLists.txt
- configure-time tests on Windows as well as Linux, so that a lot of
ad-hoc #ifdefs second-guessing a particular feature's presence from
the compiler version can now be replaced by tests of the feature
itself
Also some longer-term software-engineering advantages:
- other people have actually heard of CMake, so they'll be able to
produce patches to the new build setup more easily
- unlike the old mkfiles.pl, CMake is not my personal problem to
maintain
- most importantly, mkfiles.pl was just a horrible pile of
unmaintainable cruft, which even I found it painful to make changes
to or to use, and desperately needed throwing in the bin. I've
already thrown away all the variants of it I had in other projects
of mine, and was only delaying this one so we could make the 0.75
release branch first.
This change comes with a noticeable build-level restructuring. The
previous Recipe worked by compiling every object file exactly once,
and then making each executable by linking a precisely specified
subset of the same object files. But in CMake, that's not the natural
way to work - if you write the obvious command that puts the same
source file into two executable targets, CMake generates a makefile
that compiles it once per target. That can be an advantage, because it
gives you the freedom to compile it differently in each case (e.g.
with a #define telling it which program it's part of). But in a
project that has many executable targets and had carefully contrived
to _never_ need to build any module more than once, all it does is
bloat the build time pointlessly!
To avoid slowing down the build by a large factor, I've put most of
the modules of the code base into a collection of static libraries
organised vaguely thematically (SSH, other backends, crypto, network,
...). That means all those modules can still be compiled just once
each, because once each library is built it's reused unchanged for all
the executable targets.
One upside of this library-based structure is that now I don't have to
manually specify exactly which objects go into which programs any more
- it's enough to specify which libraries are needed, and the linker
will figure out the fine detail automatically. So there's less
maintenance to do in CMakeLists.txt when the source code changes.
But that reorganisation also adds fragility, because of the trad Unix
linker semantics of walking along the library list once each, so that
cyclic references between your libraries will provoke link errors. The
current setup builds successfully, but I suspect it only just manages
it.
(In particular, I've found that MinGW is the most finicky on this
score of the Windows compilers I've tried building with. So I've
included a MinGW test build in the new-look Buildscr, because
otherwise I think there'd be a significant risk of introducing
MinGW-only build failures due to library search order, which wasn't a
risk in the previous library-free build organisation.)
In the longer term I hope to be able to reduce the risk of that, via
gradual reorganisation (in particular, breaking up too-monolithic
modules, to reduce the risk of knock-on references when you included a
module for function A and it also contains function B with an
unsatisfied dependency you didn't really need). Ideally I want to
reach a state in which the libraries all have sensibly described
purposes, a clearly documented (partial) order in which they're
permitted to depend on each other, and a specification of what stubs
you have to put where if you're leaving one of them out (e.g.
nocrypto) and what callbacks you have to define in your non-library
objects to satisfy dependencies from things low in the stack (e.g.
out_of_memory()).
One thing that's gone completely missing in this migration,
unfortunately, is the unfinished MacOS port linked against Quartz GTK.
That's because it turned out that I can't currently build it myself,
on my own Mac: my previous installation of GTK had bit-rotted as a
side effect of an Xcode upgrade, and I haven't yet been able to
persuade jhbuild to make me a new one. So I can't even build the MacOS
port with the _old_ makefiles, and hence, I have no way of checking
that the new ones also work. I hope to bring that port back to life at
some point, but I don't want it to block the rest of this change.
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]
