2007-02-04 14:17:45 +03:00
# -*- sh -*-
# Build script to construct a full distribution directory of PuTTY.
2007-02-05 15:49:24 +03:00
module putty
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.
2007-02-04 14:17:45 +03:00
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
2016-02-29 22:59:59 +03:00
set Epoch 15860 # update this at every release
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).
ifneq "$(RELEASE)" "" set Sshver PuTTY-Release-$(RELEASE)
ifneq "$(PRERELEASE)" "" set Sshver PuTTY-Prerelease-$(PRERELEASE):$(Ndate).$(vcsid)
ifneq "$(SNAPSHOT)" "" set Sshver PuTTY-Snapshot-$(Date).$(vcsid)
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" set Sshver PuTTY-Custom-$(Date).$(vcsid)
# 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)
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
# Set up the filename for the Windows installer (minus extension,
# which goes on later).
ifneq "$(RELEASE)" "" set Ifilename putty-$(RELEASE)-installer
ifneq "$(PRERELEASE)" "" set Ifilename putty-$(PRERELEASE)-pre$(Ndate)-installer
ifneq "$(SNAPSHOT)" "" set Ifilename putty-$(Date)-installer
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" set Ifilename putty-custom-$(Date)-installer
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
# 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)
2007-02-04 14:17:45 +03:00
in putty do ./mksrcarc.sh
2014-09-24 14:33:13 +04:00
in putty do ./mkunxarc.sh '$(Autoconfver)' '$(Uxarcsuffix)' $(Docmakever)
2007-02-04 14:17:45 +03:00
in putty do perl mkfiles.pl
2014-09-24 14:33:13 +04:00
in putty/doc do make $(Docmakever) putty.hlp
in putty/doc do make $(Docmakever) chm
2007-02-04 15:30:39 +03:00
# Munge the installer script locally so that it reports the version
# we're really building.
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
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
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
2007-02-04 15:30:39 +03:00
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.
in putty/icons do make
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
2007-02-04 14:17:45 +03:00
delegate windows
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 main binaries.
2017-01-21 17:55:47 +03:00
in putty/windows with visualstudio do/win mkdir build32 && nmake -f Makefile.vc BUILDDIR=build32\ $(Makeargs) all cleantestprogs
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
2015-12-11 09:47:20 +03:00
# Code-sign the binaries, if the local bob config provides a script
# to do so. We assume here that the script accepts an -i option to
# provide a 'more info' URL, and an optional -n option to provide a
# program name, and that it can take multiple .exe filename
# arguments and sign them all in place.
2017-01-21 17:55:47 +03:00
ifneq "$(winsigncode)" "" in putty/windows do $(winsigncode) -i http://www.chiark.greenend.org.uk/~sgtatham/putty/ build*/*.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
2007-02-04 14:17:45 +03:00
# Ignore exit code from hhc, in favour of seeing whether the .chm
# file was created. (Yuck; but hhc appears to return non-zero
# exit codes on whim.)
2016-03-06 01:23:34 +03:00
in putty/doc with htmlhelp do/win hhc putty.hhp & type putty.chm >nul
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 WiX MSI installer.
2017-01-21 17:55:47 +03:00
in putty/windows with wix do/win candle -dBuilddir=build32\ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj
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 old Inno Setup installer.
2016-03-06 01:23:34 +03:00
in putty/windows with innosetup do/win iscc putty.iss
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
# Sign the installers.
2016-04-08 13:00:08 +03:00
ifneq "$(winsigncode)" "" in putty/windows do $(winsigncode) -i http://www.chiark.greenend.org.uk/~sgtatham/putty/ -n "PuTTY Installer" installer.msi Output/installer.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
# Finished Windows builds.
2017-01-21 17:55:47 +03:00
return putty/windows/build32/*.exe
return putty/windows/build32/*.map
2007-02-04 14:17:45 +03:00
return putty/doc/putty.chm
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
return putty/windows/installer.msi
2016-04-08 13:00:08 +03:00
return putty/windows/Output/installer.exe
2007-02-04 14:17:45 +03:00
enddelegate
in putty/doc do make mostlyclean
2014-09-24 14:33:13 +04:00
in putty/doc do make $(Docmakever)
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
2007-02-04 14:17:45 +03:00
in putty/doc do zip puttydoc.zip *.html
2007-02-08 21:53:11 +03:00
# Deliver the actual PuTTY release directory into a subdir `putty'.
2017-01-21 17:55:47 +03:00
deliver putty/windows/build32/*.exe putty/x86/$@
deliver putty/windows/build32/putty.zip putty/x86/$@
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
deliver putty/windows/installer.msi putty/x86/$(Ifilename).msi
2016-04-08 13:00:08 +03:00
deliver putty/windows/Output/installer.exe putty/x86/$(Ifilename).exe
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.
2017-01-21 17:55:47 +03:00
deliver putty/windows/build32/*.map maps-x86/$@
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 $@
2007-02-04 14:17:45 +03:00
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
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:
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
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
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
# And one in the x86 directory, providing links for the installers.
in-dest putty/x86 do for ext in msi exe; do set -- putty*installer.$$ext; for k in '' .gpg; do echo RedirectMatch temp '(.*/)'putty-installer.$$ext$$k\$$ '$$1'"$$1$$k" >> .htaccess; done; done
