##// END OF EJS Templates
upstream » mercurial-mirror
RSS

Clone from https://www.mercurial-scm.org/repo/hg-all

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
Gregory Szorc -
r42019:d7dc4ac1 default
Show More
Name Size Modified Last Commit Author
/ contrib / packaging / inno
build.py Loading ...
mercurial.iss Loading ...
modpath.iss Loading ...
readme.rst Loading ...
requirements.txt Loading ...
requirements.txt.in Loading ...

Requirements

Building the Inno installer requires a Windows machine.

The following system dependencies must be installed:

Building

The build.py script automates the process of producing an Inno installer. It manages fetching and configuring the non-system dependencies (such as py2exe, gettext, and various Python packages).

The script requires an activated Visual C++ 2008 command prompt. A shortcut to such a prompt was installed with Microsoft Visual C++ Compiler for Python 2.7. From your Start Menu, look for Microsoft Visual C++ Compiler Package for Python 2.7 then launch either Visual C++ 2008 32-bit Command Prompt or Visual C++ 2008 64-bit Command Prompt.

From the prompt, change to the Mercurial source directory. e.g. cd c:\src\hg.

Next, invoke build.py to produce an Inno installer. You will need to supply the path to the Python interpreter to use.:

$ python3.exe contribpackaginginnobuild.py
--python c:python27python.exe

Note

The script validates that the Visual C++ environment is active and that the architecture of the specified Python interpreter matches the Visual C++ environment and errors if not.

If everything runs as intended, dependencies will be fetched and configured into the build sub-directory, Mercurial will be built, and an installer placed in the dist sub-directory. The final line of output should print the name of the generated installer.

Additional options may be configured. Run build.py --help to see a list of program flags.

MinGW

It is theoretically possible to generate an installer that uses MinGW. This isn't well tested and build.py and may properly support it. See old versions of this file in version control for potentially useful hints as to how to achieve this.