github
/
putty
зеркало из https://github.com/github/putty.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
putty/Buildscr

276 строки
17 KiB
Plaintext
Исходник Обычный вид История

Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 14:17:45 +03: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 15:49:24 +03: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 14:33:13 +04: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 14:17:45 +03: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 14:33:13 +04: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.70 release.
2017-07-04 22:29:54 +03:00
set Epoch 16351 # 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 14:33:13 +04: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
# Set up the textual version strings for the docs build and installer.
# 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 11:29:17 +03: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 14:33:13 +04: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)
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 17:55:52 +03:00
# Set up the filenames for the Windows installer (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 23:44:19 +03: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 17:55:52 +03: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 21:31:20 +03: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 14:33:13 +04:00
# Set up the version string for the Windows installer.
ifneq "$(RELEASE)" "" set Iversion $(RELEASE)
ifneq "$(PRERELEASE)" "" set Iversion $(PRERELEASE)-pre$(Ndate).$(vcsid)
ifneq "$(SNAPSHOT)" "" set Iversion $(Date).$(vcsid)
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" set Iversion Custom-$(Date).$(vcsid)
# Set up the Windows version resource info, for both the installer and
# 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 17:55:53 +03: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 14:33:13 +04: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 14:17:45 +03: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 14:33:13 +04:00
in putty do ./mkunxarc.sh '$(Autoconfver)' '$(Uxarcsuffix)' $(Docmakever)
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 14:17:45 +03:00
in putty do perl mkfiles.pl
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 20:11:16 +03:00
in putty/doc do make $(Docmakever) putty.hlp 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 15:30:39 +03:00
# Munge the installer script locally so that it reports the version
# we're really building.
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 14:33:13 +04:00
in putty/windows do perl -i~ -pe 'BEGIN{$$a=shift@ARGV;}s/^(AppVerName=).*$$/$$1$$a/' '$(Puttytextver)' putty.iss
in putty/windows do perl -i~ -pe 'BEGIN{$$a=shift@ARGV;}s/^(VersionInfoTextVersion=).*$$/$$1$$a/' '$(Textver)' putty.iss
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 15:30:39 +03:00
in putty/windows do perl -i~ -pe 'BEGIN{$$a=shift@ARGV;}s/^(AppVersion=).*$$/$$1$$a/' '$(Iversion)' putty.iss
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 14:33:13 +04:00
in putty/windows do perl -i~ -pe 'BEGIN{$$a=shift@ARGV;}s/^(VersionInfoVersion=)\d+\.\d+\.\d+\.\d+\r?$$/$$1$$a/' '$(Winver)' putty.iss
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 15:30:39 +03:00
LICENCE in the installer should have CP/M line endings. [originally from svn r7290]
2007-02-16 02:27:29 +03:00
# Windowsify LICENCE, since it's going in the Windows installer.
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 23:44:19 +03: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 08:54:13 +03:00
in putty/icons do make -j$(nproc)
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 23:44:19 +03:00
in putty do convert -size 164x312 'gradient:blue-white' -distort SRT -90 -swirl 180 \( -size 329x312 canvas:white \) +append \( icons/putty-48.png -geometry +28+24 \) -composite \( icons/pscp-48.png -geometry +88+96 \) -composite \( icons/puttygen-48.png -geometry +28+168 \) -composite \( icons/pageant-48.png -geometry +88+240 \) -composite windows/msidialog.bmp
in putty do convert -size 493x58 canvas:white \( icons/putty-48.png -geometry +440+5 \) -composite windows/msibanner.bmp
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 22:06:11 +03:00
# Build the standard binaries, in both 32- and 64-bit flavours.
#
# For the 32-bit ones, we set a subsystem version of 5.01, which
# allows the resulting files to still run on Windows XP.
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 21:35:15 +03:00
in putty/windows with clangcl32 do mkdir build32 && Platform=x86 make -f Makefile.clangcl BUILDDIR=build32/ SUBSYSVER=,5.01 $(Makeargs) all -j$(nproc)
in putty/windows with clangcl64 do mkdir build64 && 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 22:06:11 +03: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 20:19:23 +03:00
# Build experimental Arm Windows binaries.
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 21:35:15 +03:00
in putty/windows with clangcl_a32 do mkdir abuild32 && Platform=arm make -f Makefile.clangcl BUILDDIR=abuild32/ SUBSYSVER=,5.01 $(Makeargs) all -j$(nproc)
in putty/windows with clangcl_a64 do mkdir abuild64 && Platform=arm64 make -f Makefile.clangcl BUILDDIR=abuild64/ $(Makeargs) all -j$(nproc)
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 20:19:23 +03:00
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 22:06:11 +03: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.
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 21:35:15 +03:00
in putty/windows with clangcl32_2003 do mkdir buildold && Platform=x86 make -f Makefile.clangcl BUILDDIR=buildold/ $(Makeargs) CCTARGET=i386-pc-windows-msvc13.0.0 SUBSYSVER=,4.0 EXTRA_windows=wincrt0.obj EXTRA_console=crt0.obj XFLAGS=/arch:IA32 all -j$(nproc)
# Remove Windows binaries for the test programs we don't want to ship,
# like testbn.exe. (But we still _built_ them, to ensure the build
# 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
in putty/windows do make -f Makefile.clangcl BUILDDIR=buildold/ 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 22:06:11 +03: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 20:19:23 +03: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 23:44:19 +03:00
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 22:07:00 +03:00
# Build a WiX MSI installer, for each of build32 and build64.
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 21:31:20 +03: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 21:01:36 +03: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
# Bodge the platform fields for the Windows on Arm installers, since
# WiX 3 doesn't understand Arm platform names itself.
in putty/windows do ./msiplatform.py installera32.msi Arm
in putty/windows do ./msiplatform.py installera64.msi 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 22:07:00 +03: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 21:31:20 +03: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 22:07:00 +03:00
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 14:17:45 +03: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 20:11:16 +03:00
in putty/doc do make $(Docmakever) -j$(nproc)
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 17:55:52 +03:00
in putty/windows/buildold do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm ../../doc/putty.hlp ../../doc/putty.cnt
Do the Windows build in a subdirectory windows/build32. Uses the BUILDDIR mechanism I added to Makefile.vc in commit d3db17f3e. This change is purely internal to Buildscr, and shouldn't affect the output of a build. It paves the way to have Buildscr run multiple Windows builds using different compilers, by putting each one in a different subdirectory so that their outputs don't collide.
2017-01-21 17:55:47 +03:00
in putty/windows/build32 do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm ../../doc/putty.hlp ../../doc/putty.cnt
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 17:55:52 +03:00
in putty/windows/build64 do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm ../../doc/putty.hlp ../../doc/putty.cnt
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 20:19:23 +03:00
in putty/windows/abuild32 do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm ../../doc/putty.hlp ../../doc/putty.cnt
in putty/windows/abuild64 do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../../doc/putty.chm ../../doc/putty.hlp ../../doc/putty.cnt
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 14:17:45 +03: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 21:53:11 +03: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 17:55:52 +03: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 17:55:48 +03: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 17:55:52 +03: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 17:55:52 +03: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 21:31:20 +03: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 20:19:23 +03: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 21:53:11 +03:00
deliver putty/doc/puttydoc.zip putty/$@
deliver putty/doc/putty.chm putty/$@
deliver putty/doc/putty.hlp putty/$@
deliver putty/doc/putty.cnt 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 17:55:52 +03: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 17:55:48 +03: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 17:55:52 +03: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 20:19:23 +03: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 21:53:11 +03: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 14:17:45 +03: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 15:45:52 +04: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.
in-dest putty do a=`\find * -type f -print`; md5sum $$a > md5sums && sha1sum $$a > sha1sums && sha256sum $$a > sha256sums && sha512sum $$a > sha512sums
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 15:49:24 +03: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 21:53:11 +03:00
in-dest putty do echo "AddType application/octet-stream .chm" >> .htaccess
in-dest putty do echo "AddType application/octet-stream .hlp" >> .htaccess
in-dest putty do echo "AddType application/octet-stream .cnt" >> .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 21:04:54 +03: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 17:55:52 +03: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 21:13:13 +03: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