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

317 lines
18 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.73 release.
2019-09-22 09:12:29 +00:00
set Epoch 17161 # 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)
set Docmakever VERSION="$(Puttytextver)"
# 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)
# Set up the version number for the autoconf system.
ifneq "$(RELEASE)" "" set Autoconfver $(RELEASE)
ifneq "$(PRERELEASE)" "" set Autoconfver $(PRERELEASE)~pre$(Ndate).$(vcsid)
ifneq "$(SNAPSHOT)" "" set Autoconfver $(Lastver)-$(Date).$(vcsid)
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" set Autoconfver 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
Make bob builds show the full source git commit hash in buildinfo. The Windows binaries, and both Windows and Unix source archives, output from a bob build will now include the full SHA-1 of the source git commit in their buildinfo (hence in all the About boxes and command-line version output). This will be occasionally useful to me at release time (there was that one embarrassing incident where I managed not to notice that I'd made a release build from entirely the wrong commit), but mostly, it just seems like an obviously useful thing to put in a general buildinfo section now that there is one.
2017-01-21 14:55:53 +00:00
in putty do echo '$#define SOURCE_COMMIT "$(vcsfullid)"' >> version.h
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 extra arguments for the main Windows nmake command. The
# user can define XFLAGS and MAKEARGS on the bob command line, to pass
# in extra compile and make options respectively (e.g. to do a
# debugging or Minefield build).
set Makeargs
ifneq "$(XFLAGS)" "" set Makeargs $(Makeargs) XFLAGS="$(XFLAGS)"
ifneq "$(MAKEARGS)" "" set Makeargs $(Makeargs) $(MAKEARGS)
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 11:17:45 +00:00
in putty do ./mksrcarc.sh
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
in putty do ./mkunxarc.sh '$(Autoconfver)' '$(Uxarcsuffix)' $(Docmakever)
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 11:17:45 +00:00
in putty do perl mkfiles.pl
Stop shipping old WinHelp (.HLP) file. The executables were already ignoring it. This is a minimal change; PUTTY.HLP can still be built, and there's still all the context IDs lying around. Buildscr changes are untested.
2019-03-15 22:56:37 +00:00
in putty/doc do make $(Docmakever) putty.chm -j$(nproc)
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)
in putty do ./mkauto.sh
in putty do ./configure CC=clang CFLAGS="-fsanitize=address -fsanitize=leak"
in putty do make -j$(nproc)
in putty do python test/cryptsuite.py
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.
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
in putty/windows with clangcl32 do Platform=x86 make -f Makefile.clangcl BUILDDIR=build32/ SUBSYSVER=,5.01 $(Makeargs) all -j$(nproc)
in putty/windows with clangcl64 do Platform=x64 make -f Makefile.clangcl BUILDDIR=build64/ $(Makeargs) all -j$(nproc)
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
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.
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
in putty/windows with clangcl_a32 do Platform=arm make -f Makefile.clangcl BUILDDIR=abuild32/ SUBSYSVER=,5.01 $(Makeargs) all -j$(nproc)
in putty/windows with clangcl_a64 do Platform=arm64 make -f Makefile.clangcl BUILDDIR=abuild64/ $(Makeargs) all -j$(nproc)
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
# Remove Windows binaries for the test programs we don't want to ship,
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
# like testcrypt.exe. (But we still _built_ them, to ensure the build
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
# worked.)
in putty/windows do make -f Makefile.clangcl BUILDDIR=build32/ cleantestprogs
in putty/windows do make -f Makefile.clangcl BUILDDIR=build64/ cleantestprogs
in putty/windows do make -f Makefile.clangcl BUILDDIR=abuild32/ cleantestprogs
in putty/windows do make -f Makefile.clangcl BUILDDIR=abuild64/ cleantestprogs
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.
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
ifneq "$(cross_winsigncode)" "" in putty/windows do $(cross_winsigncode) -N -i https://www.chiark.greenend.org.uk/~sgtatham/putty/ build*/*.exe abuild*/*.exe
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.
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
in putty/windows with wixonlinux do candle -arch x86 -dRealPlatform=x86 -dDllOk=yes -dBuilddir=build32/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" 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)" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installer64.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
in putty/windows with wixonlinux do candle -arch x64 -dRealPlatform=Arm -dDllOk=no -dBuilddir=abuild32/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" 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)" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installera64.msi -spdb
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
# Delete the binaries and resource files from the build directories,
# so that we can rebuild them differently.
in putty/windows/build32 do rm -f *.exe *.res *.rcpp
in putty/windows/build64 do rm -f *.exe *.res *.rcpp
in putty/windows/abuild32 do rm -f *.exe *.res *.rcpp
in putty/windows/abuild64 do rm -f *.exe *.res *.rcpp
# Build the standalone binaries, in both 32- and 64-bit flavours.
# These differ from the previous set in that they embed the help file.
in putty/windows with clangcl32 do Platform=x86 make -f Makefile.clangcl BUILDDIR=build32/ RCFL=-DEMBED_CHM SUBSYSVER=,5.01 $(Makeargs) all -j$(nproc)
in putty/windows with clangcl64 do Platform=x64 make -f Makefile.clangcl BUILDDIR=build64/ RCFL=-DEMBED_CHM $(Makeargs) all -j$(nproc)
in putty/windows with clangcl_a32 do Platform=arm make -f Makefile.clangcl BUILDDIR=abuild32/ RCFL=-DEMBED_CHM SUBSYSVER=,5.01 $(Makeargs) all -j$(nproc)
in putty/windows with clangcl_a64 do Platform=arm64 make -f Makefile.clangcl BUILDDIR=abuild64/ RCFL=-DEMBED_CHM $(Makeargs) all -j$(nproc)
# 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.
in putty/windows with clangcl32_2003 do Platform=x86 make -f Makefile.clangcl BUILDDIR=buildold/ RCFL=-DEMBED_CHM $(Makeargs) CCTARGET=i386-pc-windows-msvc13.0.0 SUBSYSVER=,4.0 EXTRA_windows=wincrt0.obj EXTRA_console=crt0.obj EXTRA_libs=libcpmt.lib XFLAGS=/arch:IA32 all -j$(nproc)
# Remove test programs again.
in putty/windows do make -f Makefile.clangcl BUILDDIR=build32/ cleantestprogs
in putty/windows do make -f Makefile.clangcl BUILDDIR=build64/ cleantestprogs
in putty/windows do make -f Makefile.clangcl BUILDDIR=abuild32/ cleantestprogs
in putty/windows do make -f Makefile.clangcl BUILDDIR=abuild64/ cleantestprogs
in putty/windows do make -f Makefile.clangcl BUILDDIR=buildold/ cleantestprogs
# Code-sign the standalone versions of the binaries.
ifneq "$(cross_winsigncode)" "" in putty/windows do $(cross_winsigncode) -N -i https://www.chiark.greenend.org.uk/~sgtatham/putty/ build*/*.exe abuild*/*.exe
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 11:17:45 +00:00
in putty/doc do make mostlyclean
Buildscr: parallelise all the 'make' commands. Now we're building four rather than two sets of Windows binaries, the build time has gone up rather painfully. I've just added a feature to bob where it will invent a sensible value to use in 'make -j' and the like, so let's start using it.
2018-05-31 17:11:16 +00:00
in putty/doc do make $(Docmakever) -j$(nproc)
Stop shipping old WinHelp (.HLP) file. The executables were already ignoring it. This is a minimal change; PUTTY.HLP can still be built, and there's still all the context IDs lying around. Buildscr changes are untested.
2019-03-15 22:56:37 +00:00
in putty/windows/buildold do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm
in putty/windows/build32 do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm
in putty/windows/build64 do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm
in putty/windows/abuild32 do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm
in putty/windows/abuild64 do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 11:17:45 +00:00
in putty/doc do zip puttydoc.zip *.html
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'.
Build a set of Windows 32-bit 'legacy' binaries with VS2003. The downside of moving to VS2015 is that its output won't run on very old versions of Windows. It's not yet clear whether anyone still cares about things before, say, Win2000 or WinXP, but since my build environment still _has_ VS2003 available, it's easy enough to build the extra set of binaries anyway just in case. (At least for now.) The new binaries live in a build output directory 'w32old'. As with w64, there is no installer for them; but unlike w64, I don't intend to add one.
2017-01-21 14:55:52 +00:00
deliver putty/windows/buildold/*.exe putty/w32old/$@
deliver putty/windows/buildold/putty.zip putty/w32old/$@
Rename the 'x86' build output directory to 'w32'. This change does affect the layout of the output build directory, and will need corresponding website changes to avoid breaking links. 'x86' was a misnomer anyway, because it was really Windows-specific rather than just x86-specific. Calling it 'w32' will make it look less strange to add 'w64' alongside it.
2017-01-21 14:55:48 +00:00
deliver putty/windows/build32/*.exe putty/w32/$@
deliver putty/windows/build32/putty.zip putty/w32/$@
Build 64-bit Windows binaries, alongside the 32-bit ones. Now we've got VS2015 available (and thanks to a lot of 64-bit cleanness fixing, in particular Tim Kosse's large patch series from August 2015) we can do this fairly easily. The new binaries are shipped in a 'w64' directory, alongside the just-renamed 'w32'. There is no 64-bit installer (yet).
2017-01-21 14:55:52 +00:00
deliver putty/windows/build64/*.exe putty/w64/$@
deliver putty/windows/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
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
deliver putty/windows/abuild32/*.exe putty/wa32/$@
deliver putty/windows/abuild32/putty.zip putty/wa32/$@
deliver putty/windows/abuild64/*.exe putty/wa64/$@
deliver putty/windows/abuild64/putty.zip putty/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 putty/doc/puttydoc.zip putty/$@
deliver putty/doc/putty.chm putty/$@
deliver putty/doc/puttydoc.txt putty/$@
deliver putty/doc/*.html putty/htmldoc/$@
deliver putty/putty-src.zip putty/$@
deliver putty/*.tar.gz putty/$@
# Deliver the map files alongside the `proper' release deliverables.
Build a set of Windows 32-bit 'legacy' binaries with VS2003. The downside of moving to VS2015 is that its output won't run on very old versions of Windows. It's not yet clear whether anyone still cares about things before, say, Win2000 or WinXP, but since my build environment still _has_ VS2003 available, it's easy enough to build the extra set of binaries anyway just in case. (At least for now.) The new binaries live in a build output directory 'w32old'. As with w64, there is no installer for them; but unlike w64, I don't intend to add one.
2017-01-21 14:55:52 +00:00
deliver putty/windows/buildold/*.map maps/w32old/$@
Rename the 'x86' build output directory to 'w32'. This change does affect the layout of the output build directory, and will need corresponding website changes to avoid breaking links. 'x86' was a misnomer anyway, because it was really Windows-specific rather than just x86-specific. Calling it 'w32' will make it look less strange to add 'w64' alongside it.
2017-01-21 14:55:48 +00:00
deliver putty/windows/build32/*.map maps/w32/$@
Build 64-bit Windows binaries, alongside the 32-bit ones. Now we've got VS2015 available (and thanks to a lot of 64-bit cleanness fixing, in particular Tim Kosse's large patch series from August 2015) we can do this fairly easily. The new binaries are shipped in a 'w64' directory, alongside the just-renamed 'w32'. There is no 64-bit installer (yet).
2017-01-21 14:55:52 +00:00
deliver putty/windows/build64/*.map maps/w64/$@
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
deliver putty/windows/abuild32/*.map maps/wa32/$@
deliver putty/windows/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