nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 01:18:00 +00:00
Code Issues Projects Releases Wiki Activity
b26077b1ae
putty-source/Buildscr

339 lines
21 KiB
Plaintext
Raw Normal View History

Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 11:17:45 +00:00
# -*- sh -*-
# Build script to construct a full distribution directory of PuTTY.
Fixes for snapshot building using bob. All of releases, snapshots 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]
2007-02-05 12:49:24 +00:00
module putty
Rework versioning system to not depend on Subversion. 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]
2014-09-24 10:33:13 +00:00
# Start by figuring out what our version information looks like.
#
# There are four classes of PuTTY build:
# - a release, which just has an X.YY version number
# - a prerelease, which has an X.YY version number, plus a date and
# version control commit id (and is considered to be 'almost'
# version X.YY)
# - a development snapshot, which just has a date and commit id
# - a custom build, which also has a date and commit id (but is
# labelled differently, to stress that development snapshots are
# built from the checked-in code by the automated nightly script
# whereas custom builds are made manually, perhaps from uncommitted
# changes, e.g. to send to a user for diagnostic or testing
# purposes).
#
# The four classes of build are triggered by invoking bob with
# different command-line variable definitions:
#
# - RELEASE=X.YY makes a release build
# - PRERELEASE=X.YY makes a prerelease build (combined with the build
# date and VCS info)
# - setting SNAPSHOT to any non-empty string makes a development
# snapshot
# - setting none of these makes a custom build.
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 11:17:45 +00:00
Rework versioning system to not depend on Subversion. 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]
2014-09-24 10:33:13 +00:00
# If we need a date for our build, start by computing it in the
# various forms we need. $(Ndate) is the date in purely numeric form
# (YYYYMMDD); $(Date) is separated as YYYY-MM-DD; $(Days) is the
# number of days since the epoch.
ifeq "$(RELEASE)" "" set Ndate $(!builddate)
ifneq "$(Ndate)" "" in . do echo $(Ndate) | perl -pe 's/(....)(..)(..)/$$1-$$2-$$3/' > date
ifneq "$(Ndate)" "" read Date date
Update version number for 0.82 release.
2024-11-25 19:49:17 +00:00
set Epoch 19052 # update this at every release
Rework versioning system to not depend on Subversion. 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]
2014-09-24 10:33:13 +00:00
ifneq "$(Ndate)" "" in . do echo $(Ndate) | perl -ne 'use Time::Local; /(....)(..)(..)/ and print timegm(0,0,0,$$3,$$2-1,$$1) / 86400 - $(Epoch)' > days
ifneq "$(Ndate)" "" read Days days
# For any non-release, we're going to need the number of the prior
# release, for putting in various places so as to get monotonic
# comparisons with the surrounding actual releases.
ifeq "$(RELEASE)" "" read Lastver putty/LATEST.VER
Remove all trace of the Inno Setup installer. (Hopefully.) We haven't even built it for the past two releases.
2019-03-18 21:22:59 +00:00
# Set up the textual version strings for the docs build and installers.
Rework versioning system to not depend on Subversion. 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]
2014-09-24 10:33:13 +00:00
# We have one of these including the word 'PuTTY', and one without,
# which are inconveniently capitalised differently.
ifneq "$(RELEASE)" "" set Puttytextver PuTTY release $(RELEASE)
ifneq "$(RELEASE)" "" set Textver Release $(RELEASE)
ifneq "$(PRERELEASE)" "" set Puttytextver PuTTY pre-release $(PRERELEASE):$(Date).$(vcsid)
ifneq "$(PRERELEASE)" "" set Textver Pre-release $(PRERELEASE):$(Date).$(vcsid)
ifneq "$(SNAPSHOT)" "" set Puttytextver PuTTY development snapshot $(Date).$(vcsid)
ifneq "$(SNAPSHOT)" "" set Textver Development snapshot $(Date).$(vcsid)
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" set Puttytextver PuTTY custom build $(Date).$(vcsid)
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" set Textver Custom build $(Date).$(vcsid)
Buildscr: fix escaping in version.but. In the echo "\\versionid foo" statement, the double \ turns into a single \ during dash's expansion phase, and the remaining '\v' turns into a vertical tab when dash's 'echo' builtin processes it. We need twice as many \ to generate a literal \ in the actual output.
2022-05-25 21:55:56 +00:00
in putty/doc do echo "\\\\versionid $(Puttytextver)" > version.but
Rework versioning system to not depend on Subversion. 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]
2014-09-24 10:33:13 +00:00
# Set up the version string for use in the SSH connection greeting.
#
# We use $(Ndate) rather than $(Date) in the pre-release string to
# make sure it's under 40 characters, which is a hard limit in the SSH
# protocol spec (and enforced by a compile-time assertion in
# version.c).
Server prep: pass "implementation name" to ssh_verstring_new. The word 'PuTTY' in the outgoing SSH version string has always represented the name of the *SSH implementation* as opposed to the name of the specific program containing it (for example, PSCP and PSFTP don't announce themselves with a different banner). But I think that a change from client to server merits a change in that implementation name, so I'm removing the prefix "PuTTY" from the constant string sshver[], and moving it to a parameter passed in separately to ssh_verstring_new, so that the upcoming server can pass in a different one.
2018-10-21 08:29:17 +00:00
ifneq "$(RELEASE)" "" set Sshver -Release-$(RELEASE)
ifneq "$(PRERELEASE)" "" set Sshver -Prerelease-$(PRERELEASE):$(Ndate).$(vcsid)
ifneq "$(SNAPSHOT)" "" set Sshver -Snapshot-$(Date).$(vcsid)
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" set Sshver -Custom-$(Date).$(vcsid)
Rework versioning system to not depend on Subversion. 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]
2014-09-24 10:33:13 +00:00
# Set up the filename suffix for the Unix source archive.
ifneq "$(RELEASE)" "" set Uxarcsuffix -$(RELEASE)
ifneq "$(PRERELEASE)" "" set Uxarcsuffix -$(PRERELEASE)~pre$(Ndate).$(vcsid)
ifneq "$(SNAPSHOT)" "" set Uxarcsuffix -$(Lastver)-$(Date).$(vcsid)
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" set Uxarcsuffix -custom-$(Date).$(vcsid)
Remove all trace of the Inno Setup installer. (Hopefully.) We haven't even built it for the past two releases.
2019-03-18 21:22:59 +00:00
# Set up the filenames for the Windows installers (minus extension,
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
# which goes on later).
Name the 64-bit MSI distinctively. The 32- and 64-bit installers may be distinguishable by their pathname in the build output directory, but it's better to have their actual filenames be different as well, so they don't collide in people's download directories.
2017-01-21 14:55:52 +00:00
ifneq "$(RELEASE)" "" set Isuffix $(RELEASE)-installer
ifneq "$(PRERELEASE)" "" set Isuffix $(PRERELEASE)-pre$(Ndate)-installer
ifneq "$(SNAPSHOT)" "" set Isuffix $(Date)-installer
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" set Isuffix custom-$(Date)-installer
set Ifilename32 putty-$(Isuffix)
set Ifilename64 putty-64bit-$(Isuffix)
Build MSI installers for Arm Windows. I expected this to be nightmarish because WiX 3 doesn't know about the Windows on Arm platform at all. Fortunately, it turns out that it doesn't have to: testing on a borrowed machine I find that Windows on Arm's msiexec.exe is quite happy to take MSIs whose platform field in the _SummaryInformation table says "Intel". In fact, that seemed to be _all_ that my test machine would accept: I tried taking the MSI apart with msidump, putting some other value in there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all I got was messages from msiexec saying "This installation package is not supported by this processor type." So in fact I just give WiX the same -arch x86 option that I give it for the real 32-bit x86 Windows installer, but then I point it at the Arm binaries, and that seems to produce a viable MSI. There is the unfortunate effect that msiexec forcibly sets the default install location to 'Program Files (x86)' no matter how I strive to make it set it any other way, but that's only cosmetic: the programs _run_ just fine no matter which Program Files directory they're installed into (and I know this won't be the first piece of software that installs itself into the wrong one). Perhaps some day we can find a way to do that part better. On general principles of caution (and of not really wanting to force Arm machines to emulate x86 code at all), the Arm versions of the installers have the new DllOk=no flag, so they're pure MSI with no embedded DLLs.
2018-05-31 18:31:20 +00:00
set Ifilenamea32 putty-arm32-$(Isuffix)
set Ifilenamea64 putty-arm64-$(Isuffix)
Rework versioning system to not depend on Subversion. 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]
2014-09-24 10:33:13 +00:00
Remove all trace of the Inno Setup installer. (Hopefully.) We haven't even built it for the past two releases.
2019-03-18 21:22:59 +00:00
# Set up the Windows version resource info, for both the installers and
Rework versioning system to not depend on Subversion. 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]
2014-09-24 10:33:13 +00:00
# the individual programs. This must be a sequence of four 16-bit
# integers compared lexicographically, and we define it as follows:
#
# For release X.YY: X.YY.0.0
# For a prerelease before the X.YY release: (X.YY-1).(DDDDD + 0x8000).0
# For a devel snapshot after the X.YY release: X.YY.DDDDD.0
# For a custom build: X.YY.DDDDD.1
#
# where DDDDD is a representation of the build date, in the form of a
# number of days since an epoch date. The epoch is reset at every
# release (which, with 15 bits, gives us a comfortable 80-odd years
# before it becomes vital to make another release to reset the count
# :-).
ifneq "$(RELEASE)" "" in . do echo $(RELEASE).0.0 > winver
ifneq "$(PRERELEASE)" "" in . do perl -e 'printf "%s.%d.0", $$ARGV[0], 0x8000+$$ARGV[1]' $(Lastver) $(Days) > winver
ifneq "$(SNAPSHOT)" "" in . do perl -e 'printf "%s.%d.0", $$ARGV[0], $$ARGV[1]' $(Lastver) $(Days) > winver
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" in . do perl -e 'printf "%s.%d.1", $$ARGV[0], $$ARGV[1]' $(Lastver) $(Days) > winver
in . do perl -pe 'y!.!,!' winver > winvercommas
read Winver winver
read Winvercommas winvercommas
# Write out a version.h that contains the real version number.
in putty do echo '/* Generated by automated build script */' > version.h
ifneq "$(RELEASE)" "" in putty do echo '$#define RELEASE $(RELEASE)' >> version.h
ifneq "$(PRERELEASE)" "" in putty do echo '$#define PRERELEASE $(PRERELEASE)' >> version.h
ifneq "$(SNAPSHOT)" "" in putty do echo '$#define SNAPSHOT' >> version.h
in putty do echo '$#define TEXTVER "$(Textver)"' >> version.h
in putty do echo '$#define SSHVER "$(Sshver)"' >> version.h
in putty do echo '$#define BINARY_VERSION $(Winvercommas)' >> version.h
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.
2021-04-10 14:21:11 +00:00
# In cmake/gitcommit.cmake, replace the default output "unavailable"
# with the commit string generated by bob, so that people rebuilding
# the source archive will still get a useful value.
in putty do sed -i '/set(DEFAULT_COMMIT/s/unavailable/$(vcsfullid)/' cmake/gitcommit.cmake
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 11:17:45 +00:00
Integrate the 'doc' subdir into the CMake system. 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.)
2021-05-02 14:34:57 +00:00
in . do mkdir docbuild
Allow standalone cmake in the doc subdirectory. It's silly to require all the time-consuming cmake configuration for the source code, if all you want to do is to build the documentation. My own website update script will like this optimisation, and so will Buildscr. In order to make doc/CMakeLists.txt work standalone, I had to add a 'project' header (citing no languages, so that cmake won't even bother looking for a C compiler); include FindGit, which cmake/setup.cmake now won't be doing for it; change all references to CMAKE_SOURCE_DIR to CMAKE_CURRENT_SOURCE_DIR/.. (since now the former will be defined differently in a nested or standalone doc build); and spot whether we're nested or not in order to conditionalise things designed to interoperate with the parent CMakeLists.
2021-05-08 09:11:56 +00:00
in docbuild do cmake ../putty/doc
in docbuild do make -j$(nproc) VERBOSE=1
in putty/doc do cp ../../docbuild/*.1 .
Put all the docs formats into the tarball. Colin points out that in the migration to cmake, I accidentally stopped putting some of the pre-built docs in the tarball - only the man pages are still there.
2021-12-21 09:49:58 +00:00
in putty/doc do cp ../../docbuild/puttydoc.txt .
in putty/doc do cp ../../docbuild/putty.chm .
in putty/doc do cp -r ../../docbuild/html .
Integrate the 'doc' subdir into the CMake system. 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.)
2021-05-02 14:34:57 +00:00
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 11:17:45 +00:00
in putty do ./mksrcarc.sh
Integrate the 'doc' subdir into the CMake system. 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.)
2021-05-02 14:34:57 +00:00
in putty do ./mkunxarc.sh '$(Uxarcsuffix)'
Version management updates for the new bob build script. There's now 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]
2007-02-04 12:30:39 +00:00
Test suite for mpint.c and ecc.c. This is a reasonably comprehensive test that exercises basically all the functions I rewrote at the end of last year, and it's how I found a lot of the bugs in them that I fixed earlier today. It's written in Python, using the unittest framework, which is convenient because that way I can cross-check Python's own large integers against PuTTY's. While I'm here, I've also added a few tests of higher-level crypto primitives such as Ed25519, AES and HMAC, when I could find official test vectors for them. I hope to add to that collection at some point, and also add unit tests of some of the other primitives like ECDH and RSA KEX. The test suite is run automatically by my top-level build script, so that I won't be able to accidentally ship anything which regresses it. When it's run at build time, the testcrypt binary is built using both Address and Leak Sanitiser, so anything they don't like will also cause a test failure.
2019-01-03 16:04:58 +00:00
delegate -
# Run the test suite, under self-delegation so that we don't leave any
# cruft lying around. This involves doing a build of the Unix tools
# (which is a useful double-check anyway to pick up any build failures)
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.
2021-04-10 14:21:11 +00:00
in putty do cmake . -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="-fsanitize=address -fsanitize=leak" -DSTRICT=ON
in putty do make -j$(nproc) VERBOSE=1
Switch to running cryptsuite.py under Python 3. I'm getting tired of maintaining it as 2/3 compatible; 2 is on the way out anyway and I'm losing patience. In future, if it breaks in 2, I think I'm going to stop caring.
2020-02-28 20:39:08 +00:00
in putty do python3 test/cryptsuite.py
Run test_lineedit and test_terminal in the main build. These seem likely to carry on being useful, so let's make sure they pass before allowing any build to complete successfully. I've added code to both test programs to return a sensible exit status indicating pass/fail, and added runs of both to Buildscr.
2023-03-05 10:21:16 +00:00
in putty do ./test_lineedit
in putty do ./test_terminal
New test program 'test_conf', mostly transitional. This aims to be a reasonably exhaustive test of what happens if you set Conf values to various things, and then save your session, and find out what ends up in the storage. Or vice versa. Currently, the test program is written to match the existing behaviour. The idea is that I can refactor the code that does the loading and saving, and if this test still passes, I've probably done it right. However, in the long term, this test will be a liability: it's yet another place you have to add every new config option. So my plan is to get rid of it again once the refactorings I'm planning are finished. Or rather, I'll get rid of _that_ part of its functionality. I also suspect I'll have added new kinds of consistency check by then, which won't be a liability in the same way, and which I'll want to keep.
2023-09-22 12:57:50 +00:00
in putty do ./test_conf
Test suite for mpint.c and ecc.c. This is a reasonably comprehensive test that exercises basically all the functions I rewrote at the end of last year, and it's how I found a lot of the bugs in them that I fixed earlier today. It's written in Python, using the unittest framework, which is convenient because that way I can cross-check Python's own large integers against PuTTY's. While I'm here, I've also added a few tests of higher-level crypto primitives such as Ed25519, AES and HMAC, when I could find official test vectors for them. I hope to add to that collection at some point, and also add unit tests of some of the other primitives like ECDH and RSA KEX. The test suite is run automatically by my top-level build script, so that I won't be able to accidentally ship anything which regresses it. When it's run at build time, the testcrypt binary is built using both Address and Leak Sanitiser, so anything they don't like will also cause a test failure.
2019-01-03 16:04:58 +00:00
enddelegate
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.
2021-04-10 14:21:11 +00:00
delegate -
# Also, test-build the Windows tools using MinGW. This is important if
# we want the MinGW build to carry on working, partly because of the
# chance of compiler compatibility issues, but mostly because MinGW's
# linker uses Unix-style library search semantics (once down the
# library list), and no other Windows toolchain we build with is that
# picky. So this ensures the Windows library structure continues to
# work in the most difficult circumstance we expect it to encounter.
Turn on -DSTRICT in the bob Windows builds. Now we should get warned if we do anything that breaks the new stricter MinGW warning level, not to mention anything generating warnings in the clang-cl builds.
2022-09-03 10:33:38 +00:00
in putty do cmake . -DCMAKE_TOOLCHAIN_FILE=cmake/toolchain-mingw.cmake -DSTRICT=ON
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.
2021-04-10 14:21:11 +00:00
in putty do make -j$(nproc) VERBOSE=1
enddelegate
Remove all trace of the Inno Setup installer. (Hopefully.) We haven't even built it for the past two releases.
2019-03-18 21:22:59 +00:00
# Windowsify LICENCE, since it's going in the Windows installers.
LICENCE in the installer should have CP/M line endings. [originally from svn r7290]
2007-02-15 23:27:29 +00:00
in putty do perl -i~ -pe 'y/\015//d;s/$$/\015/' LICENCE
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
# Some gratuitous theming for the MSI installer UI.
Buildscr: add one more make -j flag. Somehow yesterday I managed to miss the one in the icons build command. It's not the most critical one to speed up, but every little helps.
2018-06-01 05:54:13 +00:00
in putty/icons do make -j$(nproc)
Remove white dialog background in MSI user interface. We received a report that if you enable Windows 10's high-contrast mode, the text in PuTTY's installer UI becomes invisible, because it's displayed in the system default foreground colour against a background of the white right-hand side of our 'msidialog.bmp' image. That's fine when the system default fg is black, but high-contrast mode flips it to white, and now you have white on white text, oops. Some research in the WiX bug tracker suggests that in Windows 10 you don't actually have to use BMP files for your installer images any more: you can use PNG, and PNGs can be transparent. However, someone else reported that that only works in up-to-date versions of Windows. And in fact there's no need to go that far. A more elegant answer is to simply not cover the whole dialog box with our background image in the first place. I've reduced the size of the background image so that it _only_ contains the pretty picture on the left-hand side, and omits the big white rectangle that used to sit under the text. So now the RHS of the dialog is not covered by any image at all, which has the same effect as it being covered with a transparent image, except that it doesn't require transparency support from msiexec. Either way, the background for the text ends up being the system's default dialog-box background, in the absence of any images or controls placed on top of it - so when the high-contrast mode is enabled, it flips to black at the same time as the text flips to white, and everything works as it should. The slight snag is that the pre-cooked WiX UI dialog specifications let you override the background image itself, but not the Width and Height fields in the control specifications that refer to them. So if you just try to drop in a narrow image in the most obvious way, it gets stretched across the whole window. But that's not a show-stopper, because we're not 100% dependent on getting WiX to produce exactly the right output. We already have the technology to postprocess the MSI _after_ it comes out of WiX: we're using it to fiddle the target-platform field for the Windows on Arm installers. So all I had to do was to turn msiplatform.py into a more general msifixup.py, add a second option to change the width of the dialog background image, and run it on the x86 installers as well as the Arm ones.
2020-02-11 19:11:02 +00:00
in putty do ./windows/make_install_images.sh
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
mkdir putty/windows/build32
mkdir putty/windows/build64
mkdir putty/windows/buildold
mkdir putty/windows/abuild32
mkdir putty/windows/abuild64
Remove all trace of the Inno Setup installer. (Hopefully.) We haven't even built it for the past two releases.
2019-03-18 21:22:59 +00:00
# Build the binaries to go in the installers, in both 32- and 64-bit
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
# flavours.
Build using clang-cl instead of Visual Studio. This permits me to do the binary builds via cross-compilation on Linux, which is nice from a perspective of not having my build environment subject to the same potential pool of Windows malware that might be interested in infecting the resulting binaries. Also, it's quicker to build and the code generation is noticeably better.
2017-05-27 19:06:11 +00:00
#
# For the 32-bit ones, we set a subsystem version of 5.01, which
# allows the resulting files to still run on Windows XP.
32-bit Windows x86: reinstate subsystem version of 5.01. This went missing in the migration to CMake, and broke compatibility of the standard 32-bit builds with Windows XP. (Of course, the 'buildold' versions should still have run.) There doesn't seem to be a convenient CMake option to configure it cleanly, so I had to do a bodgy string-replace on the variable containing the linker flags, which I found by source-diving in CMake. That's fragile enough that I've also put in a check after the fact, so that we'll find out if it ever stops working.
2022-09-11 13:49:16 +00:00
in putty/windows/build32 with cmake_at_least_3.20 do cmake ../.. -DCMAKE_TOOLCHAIN_FILE=$(cmake_toolchain_clangcl32) -DCMAKE_BUILD_TYPE=Release -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPUTTY_LINK_MAPS=ON -DCMAKE_C_FLAGS_RELEASE="/MT /O2" -DPUTTY_SUBSYSTEM_VERSION=5.01 -DSTRICT=ON
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.
2021-04-10 14:21:11 +00:00
in putty/windows/build32 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
Turn on -DSTRICT in the bob Windows builds. Now we should get warned if we do anything that breaks the new stricter MinGW warning level, not to mention anything generating warnings in the clang-cl builds.
2022-09-03 10:33:38 +00:00
in putty/windows/build64 with cmake_at_least_3.20 do cmake ../.. -DCMAKE_TOOLCHAIN_FILE=$(cmake_toolchain_clangcl64) -DCMAKE_BUILD_TYPE=Release -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPUTTY_LINK_MAPS=ON -DCMAKE_C_FLAGS_RELEASE="/MT /O2" -DSTRICT=ON
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.
2021-04-10 14:21:11 +00:00
in putty/windows/build64 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
Build using clang-cl instead of Visual Studio. This permits me to do the binary builds via cross-compilation on Linux, which is nice from a perspective of not having my build environment subject to the same potential pool of Windows malware that might be interested in infecting the resulting binaries. Also, it's quicker to build and the code generation is noticeably better.
2017-05-27 19:06:11 +00:00
32-bit Windows x86: reinstate subsystem version of 5.01. This went missing in the migration to CMake, and broke compatibility of the standard 32-bit builds with Windows XP. (Of course, the 'buildold' versions should still have run.) There doesn't seem to be a convenient CMake option to configure it cleanly, so I had to do a bodgy string-replace on the variable containing the linker flags, which I found by source-diving in CMake. That's fragile enough that I've also put in a check after the fact, so that we'll find out if it ever stops working.
2022-09-11 13:49:16 +00:00
# The cmake mechanism used to set the subsystem version is a bit of a
# bodge (it depends on knowing how cmake set up all its build command
# variables), so just in case it breaks in future, double-check we
# really did get the subsystem version we wanted.
in putty/windows/build32 do objdump -x putty.exe > exe-headers.txt
in putty/windows/build32 do grep -Ex 'MajorOSystemVersion[[:space:]]+5' exe-headers.txt
in putty/windows/build32 do grep -Ex 'MinorOSystemVersion[[:space:]]+1' exe-headers.txt
in putty/windows/build32 do grep -Ex 'MajorSubsystemVersion[[:space:]]+5' exe-headers.txt
in putty/windows/build32 do grep -Ex 'MinorSubsystemVersion[[:space:]]+1' exe-headers.txt
Add Arm Windows builds to the main build script. I build both 32- and 64-bit versions of the .exe files, code-sign them, and create the same .zip file as I do for x86 Windows. I don't yet have a method of building Arm MSI installers, though.
2018-05-31 17:19:23 +00:00
# Build experimental Arm Windows binaries.
Turn on -DSTRICT in the bob Windows builds. Now we should get warned if we do anything that breaks the new stricter MinGW warning level, not to mention anything generating warnings in the clang-cl builds.
2022-09-03 10:33:38 +00:00
in putty/windows/abuild32 with cmake_at_least_3.20 do cmake ../.. -DCMAKE_TOOLCHAIN_FILE=$(cmake_toolchain_clangcl_a32) -DCMAKE_BUILD_TYPE=Release -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPUTTY_LINK_MAPS=ON -DCMAKE_C_FLAGS_RELEASE="/MT /O2" -DSTRICT=ON
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.
2021-04-10 14:21:11 +00:00
in putty/windows/abuild32 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
Turn on -DSTRICT in the bob Windows builds. Now we should get warned if we do anything that breaks the new stricter MinGW warning level, not to mention anything generating warnings in the clang-cl builds.
2022-09-03 10:33:38 +00:00
in putty/windows/abuild64 with cmake_at_least_3.20 do cmake ../.. -DCMAKE_TOOLCHAIN_FILE=$(cmake_toolchain_clangcl_a64) -DCMAKE_BUILD_TYPE=Release -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPUTTY_LINK_MAPS=ON -DCMAKE_C_FLAGS_RELEASE="/MT /O2" -DSTRICT=ON
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.
2021-04-10 14:21:11 +00:00
in putty/windows/abuild64 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
Buildscr: separate 'make all' from 'make cleantestprogs'. When our Windows make commands were serial, 'make all cleantestprogs' was a nice shorthand for 'first build all the binaries, then delete the ones we don't want to ship'. Now they're using -j, that doesn't work so well - last night's snapshot build log shows that the command 'rm -f testbn.exe' from the cleantestprogs target happened _before_ the lld-link command that created testbn.exe in the first place, so that file got shipped into the download directory by mistake. Easily fixed, of course - just run two separate make commands per build directory.
2018-06-01 18:35:15 +00:00
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.
2021-04-10 14:21:11 +00:00
# Make a list of the Windows binaries we're going to ship, so that we
# can sign them.
in putty/windows do for subdir in build32 abuild32 build64 abuild64; do sed "s!^!$$subdir/!" $$subdir/shipped.txt; done > to-sign.txt
Build using clang-cl instead of Visual Studio. This permits me to do the binary builds via cross-compilation on Linux, which is nice from a perspective of not having my build environment subject to the same potential pool of Windows malware that might be interested in infecting the resulting binaries. Also, it's quicker to build and the code generation is noticeably better.
2017-05-27 19:06:11 +00:00
# Code-sign the Windows binaries, if the local bob config provides a
# script to do so in a cross-compiling way. We assume here that the
# script accepts an -i option to provide a 'more info' URL, an
# optional -n option to provide a program name, and an -N option to
# take the program name from an .exe's version resource, and that it
# can accept multiple .exe or .msi filename arguments and sign them
# all in place.
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.
2021-04-10 14:21:11 +00:00
ifneq "$(cross_winsigncode)" "" in putty/windows do $(cross_winsigncode) -N -i https://www.chiark.greenend.org.uk/~sgtatham/putty/ $$(cat to-sign.txt)
New Windows installer system, using WiX to build an MSI. Mostly this is a reaction to the reports of Inno Setup having a DLL hijacking vulnerability. But also, the new installer has several other nice features that our Inno Setup one didn't provide: it can put the PuTTY install directory on PATH automatically, and it supports completely automatic and silent install/uninstall via 'msiexec /q' which should make it easier for sysadmins to roll out installation in large organisations. Also, it just seems like good sense to be using Windows's own native packaging system (or closest equivalent) rather than going it alone. (And on the developer side, I have to say I like the fact that WiX lets me pass in the version number as a set of command-line #define- equivalents, whereas for Inno Setup I had to have Buildscr apply Perl rewriting to the source file.) For the moment, I'm still building the old Inno Setup installer alongside this one, but I expect to retire it once the WiX one has survived in the wild for a while and proven itself more or less stable. I've found both MSI and WiX to be confusing and difficult technologies, so this installer has some noticeable pieces missing (e.g. retrospective reconfiguration of the installed feature set, and per-user vs systemwide installation) simply because I couldn't get them to work. I've commented the new installer source code heavily, in the hope that a passing WiX expert can give me a hand!
2016-03-09 20:44:19 +00:00
Include the installer versions of binaries in checksum files. Those hashes aren't directly needed for authenticating downloaded files (the installer itself is checksummed, which covers all the files it will unpack from itself). But they'll surely come in useful for other purposes sooner or later, so we should arrange to keep them somewhere easy to find.
2019-03-16 12:13:49 +00:00
# Make a preliminary set of cryptographic checksums giving the hashes
# of these versions of the binaries. We'll make the rest below.
in putty do for hash in md5 sha1 sha256 sha512; do for dir_plat in "build32 w32" "build64 w64" "abuild32 wa32" "abuild64 wa64"; do set -- $$dir_plat; (cd windows/$$1 && $${hash}sum *.exe | sed 's!\( \+\)!\1'$$2'/!;s!$$! (installer version)!') >> $${hash}sums.installer; done; done
Remove all trace of the Inno Setup installer. (Hopefully.) We haven't even built it for the past two releases.
2019-03-18 21:22:59 +00:00
# Build a WiX MSI installer, for each build flavour.
Allow standalone cmake in the doc subdirectory. It's silly to require all the time-consuming cmake configuration for the source code, if all you want to do is to build the documentation. My own website update script will like this optimisation, and so will Buildscr. In order to make doc/CMakeLists.txt work standalone, I had to add a 'project' header (citing no languages, so that cmake won't even bother looking for a C compiler); include FindGit, which cmake/setup.cmake now won't be doing for it; change all references to CMAKE_SOURCE_DIR to CMAKE_CURRENT_SOURCE_DIR/.. (since now the former will be defined differently in a nested or standalone doc build); and spot whether we're nested or not in order to conditionalise things designed to interoperate with the parent CMakeLists.
2021-05-08 09:11:56 +00:00
in putty/windows with wixonlinux do candle -arch x86 -dRealPlatform=x86 -dDllOk=yes -dBuilddir=build32/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" -dHelpFilePath="../../docbuild/putty.chm" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installer32.msi -spdb
in putty/windows with wixonlinux do candle -arch x64 -dRealPlatform=x64 -dDllOk=yes -dBuilddir=build64/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" -dHelpFilePath="../../docbuild/putty.chm" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installer64.msi -spdb
in putty/windows with wixonlinux do candle -arch x64 -dRealPlatform=Arm -dDllOk=no -dBuilddir=abuild32/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" -dHelpFilePath="../../docbuild/putty.chm" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installera32.msi -spdb
in putty/windows with wixonlinux do candle -arch x64 -dRealPlatform=Arm64 -dDllOk=no -dBuilddir=abuild64/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" -dHelpFilePath="../../docbuild/putty.chm" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installera64.msi -spdb
Fix platform field in Windows on Arm installers. I had previously left the platform field (in line 7 of the installer database's SummaryInformation table) set at "x86" instead of any value you might expect such as "Arm" or "Arm64", because I found that an MSI file with either of the latter values was rejected by WoA's msiexec as invalid. It turns out this is because I _also_ needed to upgrade the installer database schema version to a higher value than I even knew existed: apparently the problem is that those platform fields aren't present in the older schema. A test confirms that this works. Unfortunately, WiX 3 doesn't actually know _how_ to write MSIs with those platform values. But that's OK, because diffing the x86 and x64 MSIs against each other suggested that there were basically no other changes in the database tables - so I can just generate the installer as if for x64, and then rewrite that one field after installer construction using GNOME msitools to take apart the binary file structure and put it back together. (Those are the same tools I'm using as part of my system for running WiX on Linux in the first place.) This commit introduces a script to do that post-hoc bodging, and calls it from Buildscr. I've also changed over the choice of Program Files folder for the Arm installers so that it's ProgramFiles64Folder instead of ProgramFilesFolder - so now the Windows on Arm installer doesn't incongruously default to installing in C:\Program Files (x86)!
2018-08-16 18:01:36 +00:00
Remove white dialog background in MSI user interface. We received a report that if you enable Windows 10's high-contrast mode, the text in PuTTY's installer UI becomes invisible, because it's displayed in the system default foreground colour against a background of the white right-hand side of our 'msidialog.bmp' image. That's fine when the system default fg is black, but high-contrast mode flips it to white, and now you have white on white text, oops. Some research in the WiX bug tracker suggests that in Windows 10 you don't actually have to use BMP files for your installer images any more: you can use PNG, and PNGs can be transparent. However, someone else reported that that only works in up-to-date versions of Windows. And in fact there's no need to go that far. A more elegant answer is to simply not cover the whole dialog box with our background image in the first place. I've reduced the size of the background image so that it _only_ contains the pretty picture on the left-hand side, and omits the big white rectangle that used to sit under the text. So now the RHS of the dialog is not covered by any image at all, which has the same effect as it being covered with a transparent image, except that it doesn't require transparency support from msiexec. Either way, the background for the text ends up being the system's default dialog-box background, in the absence of any images or controls placed on top of it - so when the high-contrast mode is enabled, it flips to black at the same time as the text flips to white, and everything works as it should. The slight snag is that the pre-cooked WiX UI dialog specifications let you override the background image itself, but not the Width and Height fields in the control specifications that refer to them. So if you just try to drop in a narrow image in the most obvious way, it gets stretched across the whole window. But that's not a show-stopper, because we're not 100% dependent on getting WiX to produce exactly the right output. We already have the technology to postprocess the MSI _after_ it comes out of WiX: we're using it to fiddle the target-platform field for the Windows on Arm installers. So all I had to do was to turn msiplatform.py into a more general msifixup.py, add a second option to change the width of the dialog background image, and run it on the x86 installers as well as the Arm ones.
2020-02-11 19:11:02 +00:00
# Change the width field for our dialog background image so that it
# doesn't stretch across the whole dialog. (WiX's default one does; we
# replace it with a narrow one so that the text to the right of it
# shows up on system default background colour, meaning that
# high-contrast mode doesn't make the text white on white. But that
# means we also have to modify the width field, and there's nothing in
# WiX's source syntax to make that happen.)
#
# Also bodge the platform fields for the Windows on Arm installers,
# since WiX 3 doesn't understand Arm platform names itself.
in putty/windows do ./msifixup.py installer32.msi --dialog-bmp-width=123
in putty/windows do ./msifixup.py installer64.msi --dialog-bmp-width=123
in putty/windows do ./msifixup.py installera32.msi --dialog-bmp-width=123 --platform=Arm
in putty/windows do ./msifixup.py installera64.msi --dialog-bmp-width=123 --platform=Arm64
Build the MSI using Wix run on Linux via Mono. I have a grubby method of getting this to work without Wine, which I intend to get round to publishing just as soon as I finish deciding what its best shape is. But I don't want to wait for that before starting to actually use it, because this eliminates the last trace of Windows in the PuTTY Windows builds.
2017-05-27 19:07:00 +00:00
# Sign the Windows installers.
Build MSI installers for Arm Windows. I expected this to be nightmarish because WiX 3 doesn't know about the Windows on Arm platform at all. Fortunately, it turns out that it doesn't have to: testing on a borrowed machine I find that Windows on Arm's msiexec.exe is quite happy to take MSIs whose platform field in the _SummaryInformation table says "Intel". In fact, that seemed to be _all_ that my test machine would accept: I tried taking the MSI apart with msidump, putting some other value in there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all I got was messages from msiexec saying "This installation package is not supported by this processor type." So in fact I just give WiX the same -arch x86 option that I give it for the real 32-bit x86 Windows installer, but then I point it at the Arm binaries, and that seems to produce a viable MSI. There is the unfortunate effect that msiexec forcibly sets the default install location to 'Program Files (x86)' no matter how I strive to make it set it any other way, but that's only cosmetic: the programs _run_ just fine no matter which Program Files directory they're installed into (and I know this won't be the first piece of software that installs itself into the wrong one). Perhaps some day we can find a way to do that part better. On general principles of caution (and of not really wanting to force Arm machines to emulate x86 code at all), the Arm versions of the installers have the new DllOk=no flag, so they're pure MSI with no embedded DLLs.
2018-05-31 18:31:20 +00:00
ifneq "$(cross_winsigncode)" "" in putty/windows do $(cross_winsigncode) -i https://www.chiark.greenend.org.uk/~sgtatham/putty/ -n "PuTTY Installer" installer32.msi installer64.msi installera32.msi installera64.msi
Build the MSI using Wix run on Linux via Mono. I have a grubby method of getting this to work without Wine, which I intend to get round to publishing just as soon as I finish deciding what its best shape is. But I don't want to wait for that before starting to actually use it, because this eliminates the last trace of Windows in the PuTTY Windows builds.
2017-05-27 19:07:00 +00:00
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
# Build the standalone binaries, in both 32- and 64-bit flavours.
# These differ from the previous set in that they embed the help file.
Allow standalone cmake in the doc subdirectory. It's silly to require all the time-consuming cmake configuration for the source code, if all you want to do is to build the documentation. My own website update script will like this optimisation, and so will Buildscr. In order to make doc/CMakeLists.txt work standalone, I had to add a 'project' header (citing no languages, so that cmake won't even bother looking for a C compiler); include FindGit, which cmake/setup.cmake now won't be doing for it; change all references to CMAKE_SOURCE_DIR to CMAKE_CURRENT_SOURCE_DIR/.. (since now the former will be defined differently in a nested or standalone doc build); and spot whether we're nested or not in order to conditionalise things designed to interoperate with the parent CMakeLists.
2021-05-08 09:11:56 +00:00
in putty/windows/build32 with cmake_at_least_3.20 do cmake . -DPUTTY_EMBEDDED_CHM_FILE=$$(realpath ../../../docbuild/putty.chm)
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.
2021-04-10 14:21:11 +00:00
in putty/windows/build32 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
Allow standalone cmake in the doc subdirectory. It's silly to require all the time-consuming cmake configuration for the source code, if all you want to do is to build the documentation. My own website update script will like this optimisation, and so will Buildscr. In order to make doc/CMakeLists.txt work standalone, I had to add a 'project' header (citing no languages, so that cmake won't even bother looking for a C compiler); include FindGit, which cmake/setup.cmake now won't be doing for it; change all references to CMAKE_SOURCE_DIR to CMAKE_CURRENT_SOURCE_DIR/.. (since now the former will be defined differently in a nested or standalone doc build); and spot whether we're nested or not in order to conditionalise things designed to interoperate with the parent CMakeLists.
2021-05-08 09:11:56 +00:00
in putty/windows/build64 with cmake_at_least_3.20 do cmake . -DPUTTY_EMBEDDED_CHM_FILE=$$(realpath ../../../docbuild/putty.chm)
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.
2021-04-10 14:21:11 +00:00
in putty/windows/build64 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
Allow standalone cmake in the doc subdirectory. It's silly to require all the time-consuming cmake configuration for the source code, if all you want to do is to build the documentation. My own website update script will like this optimisation, and so will Buildscr. In order to make doc/CMakeLists.txt work standalone, I had to add a 'project' header (citing no languages, so that cmake won't even bother looking for a C compiler); include FindGit, which cmake/setup.cmake now won't be doing for it; change all references to CMAKE_SOURCE_DIR to CMAKE_CURRENT_SOURCE_DIR/.. (since now the former will be defined differently in a nested or standalone doc build); and spot whether we're nested or not in order to conditionalise things designed to interoperate with the parent CMakeLists.
2021-05-08 09:11:56 +00:00
in putty/windows/abuild32 with cmake_at_least_3.20 do cmake . -DPUTTY_EMBEDDED_CHM_FILE=$$(realpath ../../../docbuild/putty.chm)
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.
2021-04-10 14:21:11 +00:00
in putty/windows/abuild32 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
Allow standalone cmake in the doc subdirectory. It's silly to require all the time-consuming cmake configuration for the source code, if all you want to do is to build the documentation. My own website update script will like this optimisation, and so will Buildscr. In order to make doc/CMakeLists.txt work standalone, I had to add a 'project' header (citing no languages, so that cmake won't even bother looking for a C compiler); include FindGit, which cmake/setup.cmake now won't be doing for it; change all references to CMAKE_SOURCE_DIR to CMAKE_CURRENT_SOURCE_DIR/.. (since now the former will be defined differently in a nested or standalone doc build); and spot whether we're nested or not in order to conditionalise things designed to interoperate with the parent CMakeLists.
2021-05-08 09:11:56 +00:00
in putty/windows/abuild64 with cmake_at_least_3.20 do cmake . -DPUTTY_EMBEDDED_CHM_FILE=$$(realpath ../../../docbuild/putty.chm)
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.
2021-04-10 14:21:11 +00:00
in putty/windows/abuild64 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
# Build the 'old' binaries, which should still run on all 32-bit
# versions of Windows back to Win95 (but not Win32s). These link
# against Visual Studio 2003 libraries (the more modern versions
# assume excessively modern Win32 API calls to be available), specify
# a subsystem version of 4.0, and compile with /arch:IA32 to prevent
# the use of modern CPU features like MMX which older machines also
# might not have.
#
# There's no installer to go with these, so they must also embed the
# help file.
Turn on -DSTRICT in the bob Windows builds. Now we should get warned if we do anything that breaks the new stricter MinGW warning level, not to mention anything generating warnings in the clang-cl builds.
2022-09-03 10:33:38 +00:00
in putty/windows/buildold with cmake_at_least_3.20 do cmake ../.. -DCMAKE_TOOLCHAIN_FILE=$(cmake_toolchain_clangcl32_2003) -DCMAKE_BUILD_TYPE=Release -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPUTTY_LINK_MAPS=ON -DSTRICT=ON
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.
2021-04-10 14:21:11 +00:00
in putty/windows/buildold with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
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.
2021-04-10 14:21:11 +00:00
# Regenerate to-sign.txt with the 'old' binaries included.
in putty/windows do for subdir in build32 abuild32 build64 abuild64 buildold; do sed "s!^!$$subdir/!" $$subdir/shipped.txt; done > to-sign.txt
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
# Code-sign the standalone versions of the binaries.
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.
2021-04-10 14:21:11 +00:00
ifneq "$(cross_winsigncode)" "" in putty/windows do $(cross_winsigncode) -N -i https://www.chiark.greenend.org.uk/~sgtatham/putty/ $$(cat to-sign.txt)
# Move the shipped (and signed) binaries into another directory to
# deliver them from, so that we omit testcrypt and its ilk.
in putty/windows do mkdir deliver
in putty/windows do for subdir in build32 abuild32 build64 abuild64 buildold; do mkdir deliver/$$subdir; done
in putty/windows do while read x; do mv $$x deliver/$$x; mv $$x.map deliver/$$x.map; done < to-sign.txt
Stop looking for putty.chm alongside the binary. With this change, we stop expecting to find putty.chm alongside the executable file. That was a security hazard comparable to DLL hijacking, because of the risk that a malicious CHM file could be dropped into the same directory as putty.exe (e.g. if someone ran PuTTY from their browser's download dir).. Instead, the standalone putty.exe (and other binaries needing help) embed the proper CHM file within themselves, as a Windows resource, and if called on to display the help then they write the file out to a temporary location. This has the advantage that if you download and run the standalone putty.exe then you actually _get_ help, which previously didn't happen! The versions of the binaries in the installer don't each contain a copy of the help file; that would be extravagant. Instead, the installer itself writes a registry entry pointing at the proper help file, and the executables will look there. Another effect of this commit is that I've withdrawn support for the older .HLP format completely. It's now entirely outdated, and supporting it through this security fix would have been a huge pain.
2019-01-26 20:26:09 +00:00
Reinstate putty.chm in Windows binary zipfiles. A user just reported that it hasn't been there since 0.76. This turns out to be because I put the wrong pathname on the 'zip' commands in Buildscr (miscounted the number of ../ segments). I would have noticed immediately, if Info-Zip had failed with an error when it found I'd given it a nonexistent filename to add to the zip file. But in fact it just prints a warning and proceeds to add all the other files I specified. It looks as if it will only return a nonzero exit status if _all_ the filenames you specified were nonexistent. Therefore, I've rewritten the zip-creation commands so that they run zip once per file. That way if any file is unreadable we _will_ get a build error. (Also, while I'm here, I took the opportunity to get rid of that ugly ls|grep.)
2023-02-04 15:06:21 +00:00
# Make putty.zip in each Windows directory. We add the files one by
# one, because 'zip' exits with a success status if it managed to add
# _at least one_ of the input files, even if another didn't exist. So
# doing them one at a time gets us proper error reporting.
in putty/windows/deliver/buildold do for file in *.exe ../../../../docbuild/putty.chm; do case "$$file" in puttytel.exe | pterm.exe) ;; *) zip -k -j putty.zip "$$file";; esac; done
in putty/windows/deliver/build32 do for file in *.exe ../../../../docbuild/putty.chm; do case "$$file" in puttytel.exe | pterm.exe) ;; *) zip -k -j putty.zip "$$file";; esac; done
in putty/windows/deliver/build64 do for file in *.exe ../../../../docbuild/putty.chm; do case "$$file" in puttytel.exe | pterm.exe) ;; *) zip -k -j putty.zip "$$file";; esac; done
in putty/windows/deliver/abuild32 do for file in *.exe ../../../../docbuild/putty.chm; do case "$$file" in puttytel.exe | pterm.exe) ;; *) zip -k -j putty.zip "$$file";; esac; done
in putty/windows/deliver/abuild64 do for file in *.exe ../../../../docbuild/putty.chm; do case "$$file" in puttytel.exe | pterm.exe) ;; *) zip -k -j putty.zip "$$file";; esac; done
in docbuild/html do for file in *.html; do case "$$file" in puttytel.exe | pterm.exe) ;; *) zip puttydoc.zip "$$file";; esac; done
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 11:17:45 +00:00
I've changed my mind about the PuTTY build script. It now delivers the release directory into a _subdirectory_ of the main build.out, and delivers the link maps and sign.sh alongside it. That simplifies both the nightly snapshot cron job (which now doesn't have to carefully move the maps out of the release directory or go looking in strange places for sign.sh) and my release procedure (for much the same reasons). [originally from svn r7258]
2007-02-08 18:53:11 +00:00
# Deliver the actual PuTTY release directory into a subdir `putty'.
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.
2021-04-10 14:21:11 +00:00
deliver putty/windows/deliver/buildold/*.exe putty/w32old/$@
deliver putty/windows/deliver/buildold/putty.zip putty/w32old/$@
deliver putty/windows/deliver/build32/*.exe putty/w32/$@
deliver putty/windows/deliver/build32/putty.zip putty/w32/$@
deliver putty/windows/deliver/build64/*.exe putty/w64/$@
deliver putty/windows/deliver/build64/putty.zip putty/w64/$@
Name the 64-bit MSI distinctively. The 32- and 64-bit installers may be distinguishable by their pathname in the build output directory, but it's better to have their actual filenames be different as well, so they don't collide in people's download directories.
2017-01-21 14:55:52 +00:00
deliver putty/windows/installer32.msi putty/w32/$(Ifilename32).msi
deliver putty/windows/installer64.msi putty/w64/$(Ifilename64).msi
Build MSI installers for Arm Windows. I expected this to be nightmarish because WiX 3 doesn't know about the Windows on Arm platform at all. Fortunately, it turns out that it doesn't have to: testing on a borrowed machine I find that Windows on Arm's msiexec.exe is quite happy to take MSIs whose platform field in the _SummaryInformation table says "Intel". In fact, that seemed to be _all_ that my test machine would accept: I tried taking the MSI apart with msidump, putting some other value in there (e.g. "Arm64" or "Arm") and rebuilding it with msibuild, and all I got was messages from msiexec saying "This installation package is not supported by this processor type." So in fact I just give WiX the same -arch x86 option that I give it for the real 32-bit x86 Windows installer, but then I point it at the Arm binaries, and that seems to produce a viable MSI. There is the unfortunate effect that msiexec forcibly sets the default install location to 'Program Files (x86)' no matter how I strive to make it set it any other way, but that's only cosmetic: the programs _run_ just fine no matter which Program Files directory they're installed into (and I know this won't be the first piece of software that installs itself into the wrong one). Perhaps some day we can find a way to do that part better. On general principles of caution (and of not really wanting to force Arm machines to emulate x86 code at all), the Arm versions of the installers have the new DllOk=no flag, so they're pure MSI with no embedded DLLs.
2018-05-31 18:31:20 +00:00
deliver putty/windows/installera32.msi putty/wa32/$(Ifilenamea32).msi
deliver putty/windows/installera64.msi putty/wa64/$(Ifilenamea64).msi
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.
2021-04-10 14:21:11 +00:00
deliver putty/windows/deliver/abuild32/*.exe putty/wa32/$@
deliver putty/windows/deliver/abuild32/putty.zip putty/wa32/$@
deliver putty/windows/deliver/abuild64/*.exe putty/wa64/$@
deliver putty/windows/deliver/abuild64/putty.zip putty/wa64/$@
Allow standalone cmake in the doc subdirectory. It's silly to require all the time-consuming cmake configuration for the source code, if all you want to do is to build the documentation. My own website update script will like this optimisation, and so will Buildscr. In order to make doc/CMakeLists.txt work standalone, I had to add a 'project' header (citing no languages, so that cmake won't even bother looking for a C compiler); include FindGit, which cmake/setup.cmake now won't be doing for it; change all references to CMAKE_SOURCE_DIR to CMAKE_CURRENT_SOURCE_DIR/.. (since now the former will be defined differently in a nested or standalone doc build); and spot whether we're nested or not in order to conditionalise things designed to interoperate with the parent CMakeLists.
2021-05-08 09:11:56 +00:00
deliver docbuild/html/puttydoc.zip putty/$@
deliver docbuild/putty.chm putty/$@
deliver docbuild/puttydoc.txt putty/$@
deliver docbuild/html/*.html putty/htmldoc/$@
I've changed my mind about the PuTTY build script. It now delivers the release directory into a _subdirectory_ of the main build.out, and delivers the link maps and sign.sh alongside it. That simplifies both the nightly snapshot cron job (which now doesn't have to carefully move the maps out of the release directory or go looking in strange places for sign.sh) and my release procedure (for much the same reasons). [originally from svn r7258]
2007-02-08 18:53:11 +00:00
deliver putty/putty-src.zip putty/$@
deliver putty/*.tar.gz putty/$@
# Deliver the map files alongside the `proper' release deliverables.
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.
2021-04-10 14:21:11 +00:00
deliver putty/windows/deliver/buildold/*.map maps/w32old/$@
deliver putty/windows/deliver/build32/*.map maps/w32/$@
deliver putty/windows/deliver/build64/*.map maps/w64/$@
deliver putty/windows/deliver/abuild32/*.map maps/wa32/$@
deliver putty/windows/deliver/abuild64/*.map maps/wa64/$@
I've changed my mind about the PuTTY build script. It now delivers the release directory into a _subdirectory_ of the main build.out, and delivers the link maps and sign.sh alongside it. That simplifies both the nightly snapshot cron job (which now doesn't have to carefully move the maps out of the release directory or go looking in strange places for sign.sh) and my release procedure (for much the same reasons). [originally from svn r7258]
2007-02-08 18:53:11 +00:00
# Deliver sign.sh, so that whoever has just built PuTTY (the
# snapshot scripts or me, depending) can conveniently sign it with
# whatever key they want.
deliver putty/sign.sh $@
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 11:17:45 +00:00
Generate some checksum files with more up-to-date hash functions than MD5. Shipped (and signed) alongside the existing 'md5sums' file. [originally from svn r9189]
2011-07-10 11:45:52 +00:00
# Create files of cryptographic checksums, which will be signed along
# with the files they verify. We've provided MD5 checksums for a
# while, but now MD5 is looking iffy, we're expanding our selection.
#
# Creating these files is most easily done in the destination
# directory, where all the files we're delivering are already in their
# final relative layout.
Include the installer versions of binaries in checksum files. Those hashes aren't directly needed for authenticating downloaded files (the installer itself is checksummed, which covers all the files it will unpack from itself). But they'll surely come in useful for other purposes sooner or later, so we should arrange to keep them somewhere easy to find.
2019-03-16 12:13:49 +00:00
in . do pwd > builddir
read Builddir builddir
in-dest putty do a=`\find * -type f -print`; for hash in md5 sha1 sha256 sha512; do ($${hash}sum $$a; echo; cat $(Builddir)/putty/$${hash}sums.installer) > $${hash}sums; done
Fixes for snapshot building using bob. All of releases, snapshots 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]
2007-02-05 12:49:24 +00:00
# And construct .htaccess files. One in the top-level directory,
# setting the MIME types for Windows help files and providing an
# appropriate link to the source archive:
I've changed my mind about the PuTTY build script. It now delivers the release directory into a _subdirectory_ of the main build.out, and delivers the link maps and sign.sh alongside it. That simplifies both the nightly snapshot cron job (which now doesn't have to carefully move the maps out of the release directory or go looking in strange places for sign.sh) and my release procedure (for much the same reasons). [originally from svn r7258]
2007-02-08 18:53:11 +00:00
in-dest putty do echo "AddType application/octet-stream .chm" >> .htaccess
Key rollover: fix the .htaccess files built by Buildscr. The build script generates the .htaccess files that go in each individual build and redirect generic names like 'putty.tar.gz' to the real filenames including that build's version number. Those .htaccess files redirect the corresponding signatures as well, so they need updating now that we're generating signature files with a different extension. (cherry picked from commit 6744387924835792147f73644e1eed10e146b5c8)
2015-09-03 18:04:54 +00:00
in-dest putty do set -- putty*.tar.gz; for k in '' .gpg; do echo RedirectMatch temp '(.*/)'putty.tar.gz$$k\$$ '$$1'"$$1$$k" >> .htaccess; done
Build an MSI installer for the new Win64 binaries. The MSI format has a fixed field for target architecture, so there's no way to build a single MSI that can decide at install time whether to install 32-bit or 64-bit (or both). The best you can do along those lines, apparently, is to have two MSI files plus a bootstrap .EXE that decides which of them to run, and as far as I'm concerned that would just reintroduce all the same risks and annoyances that made us want to migrate away from .EXE installers anyway.
2017-01-21 14:55:52 +00:00
# And one in each binary directory, providing links for the installers.
Add HTTP redirects for the Windows on Arm installers. There's always one - I did everything else in the build script, but forgot to arrange for the wa32 and wa64 output subdirs to have a .htaccess redirect from a fixed name like 'putty-arm64-installer.msi' to whatever the real file name is in that particular build.
2018-06-04 18:13:13 +00:00
in-dest putty do for params in "w32 putty-installer" "w64 putty-64bit-installer" "wa32 putty-arm32-installer" "wa64 putty-arm64-installer"; do (set -- $$params; subdir=$$1; installername=$$2; cd $$subdir && for ext in msi exe; do set -- putty*installer.$$ext; if test -f $$1; then for k in '' .gpg; do echo RedirectMatch temp '(.*/)'$${installername}.$$ext$$k\$$ '$$1'"$$1$$k" >> .htaccess; done; fi; done); done
Reference in New Issue Copy Permalink