view contrib/packaging/inno/readme.rst @ 51721:ed28085827ec

typing: explicitly type some `mercurial.util` eol code to avoid @overload

Unlike the previous commit, this makes a material difference in the generated
stub file- the `pycompat.identity()` aliases generated an @overload like this:

    @overload
    def fromnativeeol(a: _T0) -> _T0: ...

... which might fail to detect a bad argument, like str.  This drops the
@overload for the 3 related methods, so there's a single definition for each.

The `typelib.BinaryIO_Proxy` is used for subclassing (the same as was done in
8147abc05794), so that it is a `BinaryIO` type during type checking, but still
inherits `object` at runtime.  That way, we don't need to implement unused
abstract methods.

Requirements
============

Building the Inno installer requires a Windows machine.

The following system dependencies must be installed:

* Inno Setup (http://jrsoftware.org/isdl.php) version 5.4 or newer.
  Be sure to install the optional Inno Setup Preprocessor feature,
  which is required.
* Python 3.6+ (to run the ``packaging.py`` script)

Building
========

The ``packaging.py`` script automates the process of producing an Inno
installer. It manages fetching and configuring non-system dependencies
(such as gettext, and various Python packages).  It can be run from a
basic cmd.exe Window (i.e. activating the MSBuildTools environment is
not required).

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

Next, invoke ``packaging.py`` to produce an Inno installer.::

   $ py -3 contrib\packaging\packaging.py \
       inno --pyoxidizer-target x86_64-pc-windows-msvc

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 ``packaging.py inno --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 ``packaging.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.