Page MenuHomePhabricator

inno: script to automate building Inno installer
ClosedPublic

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

Details

Summary

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.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
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.