##// END OF EJS Templates
inno: script to automate building Inno installer...
inno: script to automate building Inno installer The official Inno installer build process is poorly documented. And attempting to reproduce behavior of the installer uploaded to www.mercurial-scm.org has revealed a number of unexpected behaviors. This commit attempts to improve the state of reproducibility of the Inno installer by introducing a Python script to largely automate the building of the installer. The new script (which must be run from an environment with the Visual C++ environment configured) takes care of producing an Inno installer. When run from a fresh Mercurial source checkout with all the proper system dependencies (the VC++ toolchain, Windows 10 SDK, and Inno tools) installed, it "just works." The script takes care of downloading all the Python dependencies in a secure manner and manages the build environment for you. You don't need any additional config files: just launch the script, pointing it at an existing Python and ISCC binary and it takes care of the rest. The produced installer creates a Mercurial installation with a handful of differences from the existing 4.9 installers (produced by someone else): * add_path.exe is missing (this was removed a few changesets ago) * The set of api-ms-win-core-* DLLs is different (I suspect this is due to me using a different UCRT / Windows version). * kernelbase.dll and msasn1.dll are missing. * There are a different set of .pyc files for dulwich, keyring, and pygments due to us using the latest versions of each. * We include Tcl/Tk DLLs and .pyc files (I'm not sure why these are missing from the existing installers). * We include the urllib3 and win32ctypes packages (which are dependencies of dulwich and pywin32, respectively). I'm not sure why these aren't present in the existing installers. * We include a different set of files for the distutils package. I'm not sure why. But it should be harmless. * We include the docutils package (it is getting picked up as a dependency somehow). I think this is fine. * We include a copy of argparse.pyc. I'm not sure why this was missing from existing installers. * We don't have a copy of sqlite3/dump.pyc. I'm not sure why. The SQLite C extension code only imports this module when conn.iterdump() is called. It should be safe to omit. * We include files in the email.test and test packages. The set of files is small and their presence should be harmless. The new script and support code is written in Python 3 because it is brand new and independent code and I don't believe new Python projects should be using Python 2 in 2019 if they have a choice about it. The readme.txt file has been renamed to readme.rst and overhauled to reflect the existence of build.py. Differential Revision: https://phab.mercurial-scm.org/D6066

File last commit:

r40841:01c335af default
r42019:d7dc4ac1 default
Show More
discovery-helper.sh
64 lines | 1.9 KiB | application/x-sh | BashLexer
#!/bin/bash
#
# produces two repositories with different common and missing subsets
#
# $ discovery-helper.sh REPO NBHEADS DEPT
#
# The Goal is to produce two repositories with some common part and some
# exclusive part on each side. Provide a source repository REPO, it will
# produce two repositories REPO-left and REPO-right.
#
# Each repository will be missing some revisions exclusive to NBHEADS of the
# repo topological heads. These heads and revisions exclusive to them (up to
# DEPTH depth) are stripped.
#
# The "left" repository will use the NBHEADS first heads (sorted by
# description). The "right" use the last NBHEADS one.
#
# To find out how many topological heads a repo has, use:
#
# $ hg heads -t -T '{rev}\n' | wc -l
#
# Example:
#
# The `pypy-2018-09-01` repository has 192 heads. To produce two repositories
# with 92 common heads and ~50 exclusive heads on each side.
#
# $ ./discovery-helper.sh pypy-2018-08-01 50 10
set -euo pipefail
if [ $# -lt 3 ]; then
echo "usage: `basename $0` REPO NBHEADS DEPTH"
exit 64
fi
repo="$1"
shift
nbheads="$1"
shift
depth="$1"
shift
leftrepo="${repo}-left"
rightrepo="${repo}-right"
left="first(sort(heads(all()), 'desc'), $nbheads)"
right="last(sort(heads(all()), 'desc'), $nbheads)"
leftsubset="ancestors($left, $depth) and only($left, heads(all() - $left))"
rightsubset="ancestors($right, $depth) and only($right, heads(all() - $right))"
echo '### building left repository:' $left-repo
echo '# cloning'
hg clone --noupdate "${repo}" "${leftrepo}"
echo '# stripping' '"'${leftsubset}'"'
hg -R "${leftrepo}" --config extensions.strip= strip --rev "$leftsubset" --no-backup
echo '### building right repository:' $right-repo
echo '# cloning'
hg clone --noupdate "${repo}" "${rightrepo}"
echo '# stripping:' '"'${rightsubset}'"'
hg -R "${rightrepo}" --config extensions.strip= strip --rev "$rightsubset" --no-backup