Page MenuHomePhabricator

inno: script to automate building Inno installer

Authored by indygreg on Mar 3 2019, 6:52 PM.



The official Inno installer build process is poorly documented.
And attempting to reproduce behavior of the installer uploaded
to has revealed a number of unexpected

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

Diff Detail

rHG Mercurial
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

indygreg created this revision.Mar 3 2019, 6:52 PM
indygreg updated this revision to Diff 14338.Mar 3 2019, 9:22 PM
This revision was automatically updated to reflect the committed changes.