Mercurial > hg
comparison tests/test-check-code.t @ 41853:d7dc4ac1ff84
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
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Sun, 03 Mar 2019 18:19:07 -0800 |
parents | f16c03c7a3d7 |
children | 9da97f49d4f4 |
comparison
equal
deleted
inserted
replaced
41852:db3098d02a6d | 41853:d7dc4ac1ff84 |
---|---|
10 $ testrepohg locate \ | 10 $ testrepohg locate \ |
11 > -X contrib/python-zstandard \ | 11 > -X contrib/python-zstandard \ |
12 > -X hgext/fsmonitor/pywatchman \ | 12 > -X hgext/fsmonitor/pywatchman \ |
13 > -X mercurial/thirdparty \ | 13 > -X mercurial/thirdparty \ |
14 > | sed 's-\\-/-g' | "$check_code" --warnings --per-file=0 - || false | 14 > | sed 's-\\-/-g' | "$check_code" --warnings --per-file=0 - || false |
15 Skipping contrib/packaging/inno/build.py it has no-che?k-code (glob) | |
16 Skipping contrib/packaging/packagingutil.py it has no-che?k-code (glob) | |
15 Skipping i18n/polib.py it has no-che?k-code (glob) | 17 Skipping i18n/polib.py it has no-che?k-code (glob) |
16 Skipping mercurial/statprof.py it has no-che?k-code (glob) | 18 Skipping mercurial/statprof.py it has no-che?k-code (glob) |
17 Skipping tests/badserverext.py it has no-che?k-code (glob) | 19 Skipping tests/badserverext.py it has no-che?k-code (glob) |
18 | 20 |
19 @commands in debugcommands.py should be in alphabetical order. | 21 @commands in debugcommands.py should be in alphabetical order. |