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

208 строки
11 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
Bump version number for 0.64 release.
2015-02-28 01:42:03 +03:00
set Epoch 15493 # 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).
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)
# Set up the filename for the Windows installer.
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
ifneq "$(RELEASE)" "" set Ifilename putty-$(RELEASE)-installer.exe
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 "$(PRERELEASE)" "" set Ifilename putty-$(PRERELEASE)-pre$(Ndate)-installer.exe
ifneq "$(SNAPSHOT)" "" set Ifilename putty-$(Date)-installer.exe
ifeq "$(RELEASE)$(PRERELEASE)$(SNAPSHOT)" "" set Ifilename putty-custom-$(Date)-installer.exe
# 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)
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
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/doc do make $(Docmakever) putty.hlp
in putty/doc do make $(Docmakever) chm
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
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 14:17:45 +03:00
delegate windows
# FIXME: Cygwin alternative?
Fix errors in $(Makeargs) which only occur when building development snapshots. [originally from svn r7220]
2007-02-05 11:02:01 +03:00
in putty/windows do cmd /c vcvars32 \& nmake -f Makefile.vc $(Makeargs)
Build script for PuTTY using bob. [originally from svn r7205]
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.)
in putty/doc do hhc putty.hhp; test -f putty.chm
in putty/windows do iscc putty.iss
return putty/windows/*.exe
PuTTY builds should save the map files. [originally from svn r7212]
2007-02-04 15:37:20 +03:00
return putty/windows/*.map
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 14:17:45 +03:00
return putty/doc/putty.chm
return putty/windows/Output/setup.exe
enddelegate
in putty/doc do make mostlyclean
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/doc do make $(Docmakever)
Build script for PuTTY using bob. [originally from svn r7205]
2007-02-04 14:17:45 +03:00
in putty/windows do zip -k -j putty.zip `ls *.exe | grep -v puttytel` ../doc/putty.chm ../doc/putty.hlp ../doc/putty.cnt
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'.
deliver putty/windows/*.exe putty/x86/$@
deliver putty/windows/putty.zip putty/x86/$@
deliver putty/windows/Output/setup.exe putty/x86/$(Ifilename)
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.
deliver putty/windows/*.map maps-x86/$@
# 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
in-dest putty do set -- putty*.tar.gz; for k in '' .DSA .RSA; do echo RedirectMatch temp '(.*/)'putty.tar.gz$$k\$$ '$$1'"$$1$$k" >> .htaccess; done
Fixes for snapshot building using bob. All of releases, snapshots and custom svn builds should now have appropriately named Unix source archives and installer binaries, plus .htaccess files providing redirects to them from totally standard filenames. I _think_ this now makes it feasible to switch the nightly builds to using bob. [originally from svn r7226]
2007-02-05 15:49:24 +03:00
# And one in the x86 directory, providing a link for the installer.
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/x86 do set -- putty*installer.exe; for k in '' .DSA .RSA; do echo RedirectMatch temp '(.*/)'putty-installer.exe$$k\$$ '$$1'"$$1$$k" >> .htaccess; done