Replace mkfiles.pl with a CMake build system.

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.

1 files changed, 7 insertions, 118 deletions

diff --git a/README b/README
index de6eb9b0..252fc6be 100644
--- a/README
+++ b/README
@@ -1,123 +1,12 @@
-This is the README for the source archive of PuTTY, a free Windows
-and Unix Telnet and SSH client.
+This is the README for PuTTY, a free Windows and Unix Telnet and SSH
+client.
 
-If you want to rebuild PuTTY from source, we provide a variety of
-Makefiles and equivalents. (If you have fetched the source from
-Git, you'll have to generate the Makefiles yourself -- see
-below.)
+PuTTY is built using CMake <https://cmake.org/>. To compile in the
+simplest way (on any of Linux, Windows or Mac), run these commands in
+the source directory:
 
-There are various compile-time directives that you can use to
-disable or modify certain features; it may be necessary to do this
-in some environments. They are documented in `Recipe', and in
-comments in many of the generated Makefiles.
-
-For building on Windows:
-
- - windows/Makefile.vc is for command-line builds on MS Visual C++
-   systems. Change into the `windows' subdirectory and type `nmake
-   -f Makefile.vc' to build all the PuTTY binaries.
-
-   As of 2017, we successfully compile PuTTY with both Visual Studio
-   7 (2003) and Visual Studio 14 (2015), so our guess is that it will
-   probably build with versions in between those as well.
-
-   (The binaries from Visual Studio 14 are only compatible with
-   Windows XP and up. Binaries from Visual Studio 7 ought to work
-   with anything from Windows 95 onward.)
-
- - Inside the windows/MSVC subdirectory are MS Visual Studio project
-   files for doing GUI-based builds of the various PuTTY utilities.
-   These have been tested on Visual Studio 7 and 10.
-
-   You should be able to build each PuTTY utility by loading the
-   corresponding .dsp file in Visual Studio. For example,
-   MSVC/putty/putty.dsp builds PuTTY itself, MSVC/plink/plink.dsp
-   builds Plink, and so on.
-
- - windows/Makefile.mgw is for MinGW / Cygwin installations. Type
-   `make -f Makefile.mgw' while in the `windows' subdirectory to
-   build all the PuTTY binaries.
-
-   MinGW and friends can lag behind other toolchains in their support
-   for the Windows API. Compile-time levers are provided to exclude
-   some features; the defaults are set appropriately for the
-   'mingw-w64' cross-compiler provided with Ubuntu 14.04. If you are
-   using an older toolchain, you may need to exclude more features;
-   alternatively, you may find that upgrading to a recent version of
-   the 'w32api' package helps.
-
- - windows/Makefile.lcc is for lcc-win32. Type `make -f
-   Makefile.lcc' while in the `windows' subdirectory. (You will
-   probably need to specify COMPAT=-DNO_MULTIMON.)
-
- - Inside the windows/DEVCPP subdirectory are Dev-C++ project
-   files for doing GUI-based builds of the various PuTTY utilities.
-
-The PuTTY team actively use Makefile.vc (with VC7/10) and Makefile.mgw
-(with mingw32), so we'll probably notice problems with those
-toolchains fairly quickly. Please report any problems with the other
-toolchains mentioned above.
-
-For building on Unix:
-
- - unix/configure is for Unix and GTK. If you don't have GTK, you
-   should still be able to build the command-line utilities (PSCP,
-   PSFTP, Plink, PuTTYgen) using this script. To use it, change into
-   the `unix' subdirectory, run `./configure' and then `make'. Or you
-   can do the same in the top-level directory (we provide a little
-   wrapper that invokes configure one level down), which is more like
-   a normal Unix source archive but doesn't do so well at keeping the
-   per-platform stuff in each platform's subdirectory; it's up to you.
-
- - unix/Makefile.gtk and unix/Makefile.ux are for non-autoconfigured
-   builds. These makefiles expect you to change into the `unix'
-   subdirectory, then run `make -f Makefile.gtk' or `make -f
-   Makefile.ux' respectively. Makefile.gtk builds all the programs but
-   relies on Gtk, whereas Makefile.ux builds only the command-line
-   utilities and has no Gtk dependence.
-
- - For the graphical utilities, any of Gtk+-1.2, Gtk+-2.0, and Gtk+-3.0
-   should be supported. If you have more than one installed, you can
-   manually specify which one you want by giving the option
-   '--with-gtk=N' to the configure script where N is 1, 2, or 3.
-   (The default is the newest available, of course.) In the absence
-   of any Gtk version, the configure script will automatically
-   construct a Makefile which builds only the command-line utilities;
-   you can manually create this condition by giving configure the
-   option '--without-gtk'.
-
- - pterm would like to be setuid or setgid, as appropriate, to permit
-   it to write records of user logins to /var/run/utmp and
-   /var/log/wtmp. (Of course it will not use this privilege for
-   anything else, and in particular it will drop all privileges before
-   starting up complex subsystems like GTK.) By default the makefile
-   will not attempt to add privileges to the pterm executable at 'make
-   install' time, but you can ask it to do so by running configure
-   with the option '--enable-setuid=USER' or '--enable-setgid=GROUP'.
-
- - The Unix Makefiles have an `install' target. Note that by default
-   it tries to install `man' pages; if you have fetched the source via
-   Git then you will need to have built these using Halibut
-   first - see below.
-
- - It's also possible to build the Windows version of PuTTY to run
-   on Unix by using Winelib.  To do this, change to the `windows'
-   directory and run `make -f Makefile.mgw CC=winegcc RC=wrc'.
-
-All of the Makefiles are generated automatically from the file
-`Recipe' by the Perl script `mkfiles.pl' (except for the Unix one,
-which is generated by the `configure' script; mkfiles.pl only
-generates the input to automake). Additions and corrections to Recipe,
-mkfiles.pl and/or configure.ac are much more useful than additions and
-corrections to the actual Makefiles, Makefile.am or Makefile.in.
-
-The Unix `configure' script and its various requirements are generated
-by the shell script `mkauto.sh', which requires GNU Autoconf, GNU
-Automake, and Gtk; if you've got the source from Git rather
-than using one of our source snapshots, you'll need to run this
-yourself. The input file to Automake is generated by mkfiles.pl along
-with all the rest of the makefiles, so you will need to run mkfiles.pl
-and then mkauto.sh.
+  cmake .
+  cmake --build .
 
 Documentation (in various formats including Windows Help and Unix
 `man' pages) is built from the Halibut (`.but') files in the `doc'