simon-git: putty (main): Simon Tatham
Commits to Tartarus hosted VCS
tartarus-commits at lists.tartarus.org
Sat Apr 17 15:10:34 BST 2021
TL;DR:
af991096 Separate the functions of licence.pl.
97f7a7cb Enforce that NDEBUG is not defined.
c19e7215 Replace mkfiles.pl with a CMake build system.
6c783f9a Remove the NO_SECURITY compile-time option.
Repository: https://git.tartarus.org/simon/putty.git
On the web: https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer: Simon Tatham <anakin at pobox.com>
Date: 2021-04-17 15:10:34
commit af9910962abf2438458ffd41228a39532804c328
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=af9910962abf2438458ffd41228a39532804c328;hp=a0869fab25e276885261881a8a3aae79492c1c5f
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Apr 10 17:34:24 2021 +0100
Separate the functions of licence.pl.
Now you can run it with --header, --copyrightdoc or --licencedoc
depending on which file you want it to generate. mkfiles.pl only runs
the header mode; the other two modes have become rules in
Makefile.doc.
doc/Makefile | 5 ++
licence.pl | 149 +++++++++++++++++++++++++++++++++--------------------------
mkfiles.pl | 3 ++
3 files changed, 92 insertions(+), 65 deletions(-)
commit 97f7a7cb4deacbc92a9dbdc1b9394e4e1358e47a
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=97f7a7cb4deacbc92a9dbdc1b9394e4e1358e47a;hp=af9910962abf2438458ffd41228a39532804c328
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Apr 10 14:46:36 2021 +0100
Enforce that NDEBUG is not defined.
PuTTY is a security project, so assertions are important - if an
assumption is violated, proceeding anyway may have far worse
consequences than simple program termination. This check and #error
should arrange that we don't ever accidentally compile assertions out.
defs.h | 11 +++++++++++
1 file changed, 11 insertions(+)
commit c19e7215ddd1d6a890fdb94d89bc5ccb46151363
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=c19e7215ddd1d6a890fdb94d89bc5ccb46151363;hp=97f7a7cb4deacbc92a9dbdc1b9394e4e1358e47a
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Apr 10 15:21:11 2021 +0100
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.
.gitignore | 32 -
Buildscr | 140 +--
Buildscr.cv | 14 +-
CMakeLists.txt | 101 ++
README | 125 +--
Recipe | 431 ---------
charset/CMakeLists.txt | 29 +
charset/sbcsgen.pl | 12 +-
cmake/cmake.h.in | 35 +
cmake/gitcommit.cmake | 48 +
cmake/gtk.cmake | 85 ++
cmake/licence.cmake | 39 +
cmake/platforms/unix.cmake | 121 +++
cmake/platforms/windows.cmake | 171 ++++
cmake/setup.cmake | 78 ++
cmake/toolchain-mingw.cmake | 10 +
cmake/toolchain-winegcc.cmake | 33 +
cmake/winegcc | 29 +
configure.ac | 264 ------
doc/udp.but | 39 -
mkauto.sh | 11 -
mkfiles.pl | 2095 -----------------------------------------
mksrcarc.sh | 1 -
mkunxarc.sh | 10 +-
release.pl | 6 +-
unix/CMakeLists.txt | 204 ++++
unix/configure | 3 -
unix/gtkapp.c | 15 +-
unix/unix.h | 4 +-
unix/uxgss.c | 2 +-
unix/uxpeer.c | 8 +-
unix/uxpty.c | 14 +-
unix/uxutils.h | 10 +-
version.c | 5 -
version.h | 22 -
windows/CMakeLists.txt | 142 +++
windows/rcstuff.h | 15 +-
windows/window.c | 22 +-
windows/wingss.c | 2 +-
windows/winhelp.rc2 | 4 +-
windows/winhsock.c | 2 +-
windows/winmisc.c | 2 +-
windows/winmiscs.c | 2 +-
windows/winstuff.h | 11 +-
44 files changed, 1272 insertions(+), 3176 deletions(-)
commit 6c783f9ad0d2e34db0cbf3147ee872402c90dcd2
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=6c783f9ad0d2e34db0cbf3147ee872402c90dcd2;hp=c19e7215ddd1d6a890fdb94d89bc5ccb46151363
Author: Simon Tatham <anakin at pobox.com>
Date: Sat Apr 10 15:26:53 2021 +0100
Remove the NO_SECURITY compile-time option.
It's had its day. It was there to support pre-WinNT platforms, on
which the security APIs don't exist - but more specifically, it was
there to support _build tools_ that only knew about pre-WinNT versions
of Windows, so that you couldn't even compile a program that would
_try_ to refer to the interprocess security APIs.
But we don't support those build systems any more in any case: more
recent changes like the assumption of (most of) C99 will have stopped
this code from building with compilers that old. So there's no reason
to clutter the code with backwards compatibility features that won't
help.
I left NO_SECURITY in place during the CMake migration, so that _just_
in case it needs resurrecting, some version of it will be available in
the git history. But I don't expect it to be needed, and I'm deleting
the whole thing now.
The _runtime_ check for interprocess security libraries is still in
place. So PuTTY tools built with a modern toolchain can still at least
try to run on the Win95/98/ME series, and they should detect that
those system DLLs don't exist and proceed sensibly in their absence.
That may also be a thing to throw out sooner or later, but I haven't
thrown it out as part of this commit.
cmake/platforms/windows.cmake | 11 -----------
misc.c | 3 ---
windows/wincapi.c | 4 ----
windows/wincapi.h | 4 ----
windows/winnpc.c | 4 ----
windows/winnps.c | 4 ----
windows/winpgnt.c | 20 --------------------
windows/winpgntc.c | 42 ------------------------------------------
windows/winsecur.c | 8 --------
windows/winsecur.h | 4 ----
windows/winshare.c | 8 --------
11 files changed, 112 deletions(-)
More information about the tartarus-commits
mailing list