mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 09:27:59 +00:00
a55aac71e4
This fulfills our long-standing Mayhem-difficulty wishlist item 'win-command-prompt': this is a Windows pterm in the sense that when you run it you get a local cmd.exe running inside a PuTTY-style window. Advantages of this: you get the same free choice of fonts as PuTTY has (no restriction to a strange subset of the system's available fonts); you get the same copy-paste gestures as PuTTY (no mental gear-shifting when you have command prompts and SSH sessions open on the same desktop); you get scrollback with the PuTTY semantics (scrolling to the bottom gets you to where the action is, as opposed to the way you could accidentally find yourself 500 lines past the end of the action in a real console). 'win-command-prompt' was at Mayhem difficulty ('Probably impossible') basically on the grounds that with Windows's old APIs for accessing the contents of consoles, there was no way I could find to get this to work sensibly. What was needed to make it feasible was a major piece of re-engineering work inside Windows itself. But, of course, that's exactly what happened! In 2019, the new ConPTY API arrived, which lets you create an object that behaves like a Windows console at one end, and round the back, emits a stream of VT-style escape sequences as the screen contents evolve, and accepts a VT-style input stream in return which it will parse function and arrow keys out of in the usual way. So now it's actually _easy_ to get this to basically work. The new backend, in conpty.c, has to do a handful of magic Windows API calls to set up the pseudo-console and its feeder pipes and start a subprocess running in it, a further magic call every time the PuTTY window is resized, and detect the end of the session by watching for the subprocess terminating. But apart from that, all it has to do is pass data back and forth unmodified between those pipes and the backend's associated Seat! That said, this is new and experimental, and there will undoubtedly be issues. One that I already know about is that you can't copy and paste a word that has wrapped between lines without getting an annoying newline in the middle of it. As far as I can see this is a fundamental limitation: the ConPTY system sends the _same_ escape sequence stream for a line that wrapped as it would send for a line that had a logical \n at what would have been the wrap point. Probably the best we can do to mitigate this is to adopt a different heuristic for newline elision that's right more often than it's wrong. For the moment, that experimental-ness is indicated by the fact that Buildscr will build, sign and deliver a copy of pterm.exe for each flavour of Windows, but won't include it in the .zip file or in the installer. (In fact, that puts it in exactly the same ad-hoc category as PuTTYtel, although for completely different reasons.)
319 lines
19 KiB
Bash
319 lines
19 KiB
Bash
# -*- sh -*-
|
|
# Build script to construct a full distribution directory of PuTTY.
|
|
|
|
module putty
|
|
|
|
# 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.
|
|
|
|
# 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
|
|
set Epoch 17749 # update this at every release
|
|
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 installers.
|
|
# 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)
|
|
in putty/doc do echo "\\versionid $(Puttytextver)" > version.but
|
|
|
|
# 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 -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)
|
|
|
|
# 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 filenames for the Windows installers (minus extension,
|
|
# which goes on later).
|
|
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)
|
|
set Ifilenamea32 putty-arm32-$(Isuffix)
|
|
set Ifilenamea64 putty-arm64-$(Isuffix)
|
|
|
|
# Set up the Windows version resource info, for both the installers 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
|
|
|
|
# In cmake/gitcommit.cmake, replace the default output "unavailable"
|
|
# with the commit string generated by bob, so that people rebuilding
|
|
# the source archive will still get a useful value.
|
|
in putty do sed -i '/set(DEFAULT_COMMIT/s/unavailable/$(vcsfullid)/' cmake/gitcommit.cmake
|
|
|
|
in . do mkdir docbuild
|
|
in docbuild do cmake ../putty/doc
|
|
in docbuild do make -j$(nproc) VERBOSE=1
|
|
in putty/doc do cp ../../docbuild/*.1 .
|
|
|
|
in putty do ./mksrcarc.sh
|
|
in putty do ./mkunxarc.sh '$(Uxarcsuffix)'
|
|
|
|
delegate -
|
|
# Run the test suite, under self-delegation so that we don't leave any
|
|
# cruft lying around. This involves doing a build of the Unix tools
|
|
# (which is a useful double-check anyway to pick up any build failures)
|
|
in putty do cmake . -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="-fsanitize=address -fsanitize=leak" -DSTRICT=ON
|
|
in putty do make -j$(nproc) VERBOSE=1
|
|
in putty do python3 test/cryptsuite.py
|
|
enddelegate
|
|
|
|
delegate -
|
|
# Also, test-build the Windows tools using MinGW. This is important if
|
|
# we want the MinGW build to carry on working, partly because of the
|
|
# chance of compiler compatibility issues, but mostly because MinGW's
|
|
# linker uses Unix-style library search semantics (once down the
|
|
# library list), and no other Windows toolchain we build with is that
|
|
# picky. So this ensures the Windows library structure continues to
|
|
# work in the most difficult circumstance we expect it to encounter.
|
|
in putty do cmake . -DCMAKE_TOOLCHAIN_FILE=cmake/toolchain-mingw.cmake
|
|
in putty do make -j$(nproc) VERBOSE=1
|
|
enddelegate
|
|
|
|
# Windowsify LICENCE, since it's going in the Windows installers.
|
|
in putty do perl -i~ -pe 'y/\015//d;s/$$/\015/' LICENCE
|
|
|
|
# Some gratuitous theming for the MSI installer UI.
|
|
in putty/icons do make -j$(nproc)
|
|
in putty do ./windows/make_install_images.sh
|
|
|
|
mkdir putty/windows/build32
|
|
mkdir putty/windows/build64
|
|
mkdir putty/windows/buildold
|
|
mkdir putty/windows/abuild32
|
|
mkdir putty/windows/abuild64
|
|
|
|
# Build the binaries to go in the installers, 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.
|
|
in putty/windows/build32 with cmake_at_least_3.20 do cmake ../.. -DCMAKE_TOOLCHAIN_FILE=$(cmake_toolchain_clangcl32) -DCMAKE_BUILD_TYPE=Release -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPUTTY_LINK_MAPS=ON -DCMAKE_C_FLAGS_RELEASE="/MT /O2"
|
|
in putty/windows/build32 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
|
|
in putty/windows/build64 with cmake_at_least_3.20 do cmake ../.. -DCMAKE_TOOLCHAIN_FILE=$(cmake_toolchain_clangcl64) -DCMAKE_BUILD_TYPE=Release -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPUTTY_LINK_MAPS=ON -DCMAKE_C_FLAGS_RELEASE="/MT /O2"
|
|
in putty/windows/build64 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
|
|
|
|
# Build experimental Arm Windows binaries.
|
|
in putty/windows/abuild32 with cmake_at_least_3.20 do cmake ../.. -DCMAKE_TOOLCHAIN_FILE=$(cmake_toolchain_clangcl_a32) -DCMAKE_BUILD_TYPE=Release -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPUTTY_LINK_MAPS=ON -DCMAKE_C_FLAGS_RELEASE="/MT /O2"
|
|
in putty/windows/abuild32 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
|
|
in putty/windows/abuild64 with cmake_at_least_3.20 do cmake ../.. -DCMAKE_TOOLCHAIN_FILE=$(cmake_toolchain_clangcl_a64) -DCMAKE_BUILD_TYPE=Release -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPUTTY_LINK_MAPS=ON -DCMAKE_C_FLAGS_RELEASE="/MT /O2"
|
|
in putty/windows/abuild64 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
|
|
|
|
# Make a list of the Windows binaries we're going to ship, so that we
|
|
# can sign them.
|
|
in putty/windows do for subdir in build32 abuild32 build64 abuild64; do sed "s!^!$$subdir/!" $$subdir/shipped.txt; done > to-sign.txt
|
|
|
|
# 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.
|
|
ifneq "$(cross_winsigncode)" "" in putty/windows do $(cross_winsigncode) -N -i https://www.chiark.greenend.org.uk/~sgtatham/putty/ $$(cat to-sign.txt)
|
|
|
|
# Make a preliminary set of cryptographic checksums giving the hashes
|
|
# of these versions of the binaries. We'll make the rest below.
|
|
in putty do for hash in md5 sha1 sha256 sha512; do for dir_plat in "build32 w32" "build64 w64" "abuild32 wa32" "abuild64 wa64"; do set -- $$dir_plat; (cd windows/$$1 && $${hash}sum *.exe | sed 's!\( \+\)!\1'$$2'/!;s!$$! (installer version)!') >> $${hash}sums.installer; done; done
|
|
|
|
# Build a WiX MSI installer, for each build flavour.
|
|
in putty/windows with wixonlinux do candle -arch x86 -dRealPlatform=x86 -dDllOk=yes -dBuilddir=build32/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" -dHelpFilePath="../../docbuild/putty.chm" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installer32.msi -spdb
|
|
in putty/windows with wixonlinux do candle -arch x64 -dRealPlatform=x64 -dDllOk=yes -dBuilddir=build64/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" -dHelpFilePath="../../docbuild/putty.chm" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installer64.msi -spdb
|
|
in putty/windows with wixonlinux do candle -arch x64 -dRealPlatform=Arm -dDllOk=no -dBuilddir=abuild32/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" -dHelpFilePath="../../docbuild/putty.chm" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installera32.msi -spdb
|
|
in putty/windows with wixonlinux do candle -arch x64 -dRealPlatform=Arm64 -dDllOk=no -dBuilddir=abuild64/ -dWinver="$(Winver)" -dPuttytextver="$(Puttytextver)" -dHelpFilePath="../../docbuild/putty.chm" installer.wxs && light -ext WixUIExtension -ext WixUtilExtension -sval installer.wixobj -o installera64.msi -spdb
|
|
|
|
# Change the width field for our dialog background image so that it
|
|
# doesn't stretch across the whole dialog. (WiX's default one does; we
|
|
# replace it with a narrow one so that the text to the right of it
|
|
# shows up on system default background colour, meaning that
|
|
# high-contrast mode doesn't make the text white on white. But that
|
|
# means we also have to modify the width field, and there's nothing in
|
|
# WiX's source syntax to make that happen.)
|
|
#
|
|
# Also bodge the platform fields for the Windows on Arm installers,
|
|
# since WiX 3 doesn't understand Arm platform names itself.
|
|
in putty/windows do ./msifixup.py installer32.msi --dialog-bmp-width=123
|
|
in putty/windows do ./msifixup.py installer64.msi --dialog-bmp-width=123
|
|
in putty/windows do ./msifixup.py installera32.msi --dialog-bmp-width=123 --platform=Arm
|
|
in putty/windows do ./msifixup.py installera64.msi --dialog-bmp-width=123 --platform=Arm64
|
|
|
|
# Sign the Windows installers.
|
|
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 standalone binaries, in both 32- and 64-bit flavours.
|
|
# These differ from the previous set in that they embed the help file.
|
|
in putty/windows/build32 with cmake_at_least_3.20 do cmake . -DPUTTY_EMBEDDED_CHM_FILE=$$(realpath ../../../docbuild/putty.chm)
|
|
in putty/windows/build32 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
|
|
in putty/windows/build64 with cmake_at_least_3.20 do cmake . -DPUTTY_EMBEDDED_CHM_FILE=$$(realpath ../../../docbuild/putty.chm)
|
|
in putty/windows/build64 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
|
|
in putty/windows/abuild32 with cmake_at_least_3.20 do cmake . -DPUTTY_EMBEDDED_CHM_FILE=$$(realpath ../../../docbuild/putty.chm)
|
|
in putty/windows/abuild32 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
|
|
in putty/windows/abuild64 with cmake_at_least_3.20 do cmake . -DPUTTY_EMBEDDED_CHM_FILE=$$(realpath ../../../docbuild/putty.chm)
|
|
in putty/windows/abuild64 with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
|
|
|
|
# Build the 'old' binaries, which should still run on all 32-bit
|
|
# versions of Windows back to Win95 (but not Win32s). These link
|
|
# against Visual Studio 2003 libraries (the more modern versions
|
|
# assume excessively modern Win32 API calls to be available), specify
|
|
# a subsystem version of 4.0, and compile with /arch:IA32 to prevent
|
|
# the use of modern CPU features like MMX which older machines also
|
|
# might not have.
|
|
#
|
|
# There's no installer to go with these, so they must also embed the
|
|
# help file.
|
|
in putty/windows/buildold with cmake_at_least_3.20 do cmake ../.. -DCMAKE_TOOLCHAIN_FILE=$(cmake_toolchain_clangcl32_2003) -DCMAKE_BUILD_TYPE=Release -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DPUTTY_LINK_MAPS=ON
|
|
in putty/windows/buildold with cmake_at_least_3.20 do make -j$(nproc) VERBOSE=1
|
|
|
|
# Regenerate to-sign.txt with the 'old' binaries included.
|
|
in putty/windows do for subdir in build32 abuild32 build64 abuild64 buildold; do sed "s!^!$$subdir/!" $$subdir/shipped.txt; done > to-sign.txt
|
|
|
|
# Code-sign the standalone versions of the binaries.
|
|
ifneq "$(cross_winsigncode)" "" in putty/windows do $(cross_winsigncode) -N -i https://www.chiark.greenend.org.uk/~sgtatham/putty/ $$(cat to-sign.txt)
|
|
|
|
# Move the shipped (and signed) binaries into another directory to
|
|
# deliver them from, so that we omit testcrypt and its ilk.
|
|
in putty/windows do mkdir deliver
|
|
in putty/windows do for subdir in build32 abuild32 build64 abuild64 buildold; do mkdir deliver/$$subdir; done
|
|
in putty/windows do while read x; do mv $$x deliver/$$x; mv $$x.map deliver/$$x.map; done < to-sign.txt
|
|
|
|
in putty/windows/deliver/buildold do zip -k -j putty.zip `ls *.exe | grep -vxE '^(puttytel|pterm).exe'` ../../../docbuild/putty.chm
|
|
in putty/windows/deliver/build32 do zip -k -j putty.zip `ls *.exe | grep -vxE '^(puttytel|pterm).exe'` ../../../docbuild/putty.chm
|
|
in putty/windows/deliver/build64 do zip -k -j putty.zip `ls *.exe | grep -vxE '^(puttytel|pterm).exe'` ../../../docbuild/putty.chm
|
|
in putty/windows/deliver/abuild32 do zip -k -j putty.zip `ls *.exe | grep -vxE '^(puttytel|pterm).exe'` ../../../docbuild/putty.chm
|
|
in putty/windows/deliver/abuild64 do zip -k -j putty.zip `ls *.exe | grep -vxE '^(puttytel|pterm).exe'` ../../../docbuild/putty.chm
|
|
in docbuild/html do zip puttydoc.zip *.html
|
|
|
|
# Deliver the actual PuTTY release directory into a subdir `putty'.
|
|
deliver putty/windows/deliver/buildold/*.exe putty/w32old/$@
|
|
deliver putty/windows/deliver/buildold/putty.zip putty/w32old/$@
|
|
deliver putty/windows/deliver/build32/*.exe putty/w32/$@
|
|
deliver putty/windows/deliver/build32/putty.zip putty/w32/$@
|
|
deliver putty/windows/deliver/build64/*.exe putty/w64/$@
|
|
deliver putty/windows/deliver/build64/putty.zip putty/w64/$@
|
|
deliver putty/windows/installer32.msi putty/w32/$(Ifilename32).msi
|
|
deliver putty/windows/installer64.msi putty/w64/$(Ifilename64).msi
|
|
deliver putty/windows/installera32.msi putty/wa32/$(Ifilenamea32).msi
|
|
deliver putty/windows/installera64.msi putty/wa64/$(Ifilenamea64).msi
|
|
deliver putty/windows/deliver/abuild32/*.exe putty/wa32/$@
|
|
deliver putty/windows/deliver/abuild32/putty.zip putty/wa32/$@
|
|
deliver putty/windows/deliver/abuild64/*.exe putty/wa64/$@
|
|
deliver putty/windows/deliver/abuild64/putty.zip putty/wa64/$@
|
|
deliver docbuild/html/puttydoc.zip putty/$@
|
|
deliver docbuild/putty.chm putty/$@
|
|
deliver docbuild/puttydoc.txt putty/$@
|
|
deliver docbuild/html/*.html putty/htmldoc/$@
|
|
deliver putty/putty-src.zip putty/$@
|
|
deliver putty/*.tar.gz putty/$@
|
|
|
|
# Deliver the map files alongside the `proper' release deliverables.
|
|
deliver putty/windows/deliver/buildold/*.map maps/w32old/$@
|
|
deliver putty/windows/deliver/build32/*.map maps/w32/$@
|
|
deliver putty/windows/deliver/build64/*.map maps/w64/$@
|
|
deliver putty/windows/deliver/abuild32/*.map maps/wa32/$@
|
|
deliver putty/windows/deliver/abuild64/*.map maps/wa64/$@
|
|
|
|
# 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 $@
|
|
|
|
# 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 . do pwd > builddir
|
|
read Builddir builddir
|
|
in-dest putty do a=`\find * -type f -print`; for hash in md5 sha1 sha256 sha512; do ($${hash}sum $$a; echo; cat $(Builddir)/putty/$${hash}sums.installer) > $${hash}sums; done
|
|
|
|
# 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:
|
|
in-dest putty do echo "AddType application/octet-stream .chm" >> .htaccess
|
|
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
|
|
# And one in each binary directory, providing links for the installers.
|
|
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
|