Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:43:54 -0800] rev 41915
packaging: extract py2exe functionality to own module
py2exe builds are shared between Inno Setup and WIX. We'll
want the logic for performing py2exe builds to be reusable
across the code for both installers.
This commit extracts the py2exe-specific functionality into
its own module.
There's definitely room to customize things further. This will
be done in future commits, as necessary. (I'm not even sure what
customizations WIX will require yet. Presumably a lot.)
Differential Revision: https://phab.mercurial-scm.org/D6091
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:49:59 -0800] rev 41914
packaging: extract python exe info to own function
This is generic functionality. We'll need it for WIX.
As part of the port, we expose the full version and return
the data as a dict.
Differential Revision: https://phab.mercurial-scm.org/D6090
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:36:20 -0800] rev 41913
packaging: don't use temporary directory
We were no longer doing anything with it after extracting
virtualenv and py2exe to the build directory.
Differential Revision: https://phab.mercurial-scm.org/D6089
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:35:20 -0800] rev 41912
packaging: extract virtualenv and py2exe to build directory
The build directory is essentially a cache. We can extract
the virtualenv and py2exe package sources to this directory.
Differential Revision: https://phab.mercurial-scm.org/D6088
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:43:14 -0800] rev 41911
packaging: move Inno Setup core logic into a module
Aspects of building the Inno Setup and WIX installers are shared.
It will make sense for them to share code.
Plus, having code in a reusable library (as opposed to a standalone
script) is just a better approach.
This commit moves the core logic to build the Inno Setup installer
into the hgpackaging package. inno/build.py is now a simple frontend
script that calls into a module to do the bulk of the work.
As part of this change, I also found a typo in build() where it was
referencing "iscc" instead of "iscc_exe." Because "iscc" was in
the global scope via the only caller, things just happened to work
before. Another benefit of always using functions and not putting
global code for __main__ in the same file as library code.
Differential Revision: https://phab.mercurial-scm.org/D6087
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:22:09 -0800] rev 41910
packaging: move find_vc_runtime_files() into hgpackaging.util
In preparation for moving the bulk of the Inno Setup code into
hgpackaging.
Differential Revision: https://phab.mercurial-scm.org/D6086
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 10:20:37 -0800] rev 41909
packaging: move DOWNLOADS dict to hgpackaging.downloads
We'll want to keep state in sync between multiple packaging tools.
It makes sense to share a central data structure defining downloads.
We also change the function to return the downloads entry so
callers don't have to access the global DOWNLOADS in the new
location.
Differential Revision: https://phab.mercurial-scm.org/D6085
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 07 Mar 2019 15:42:32 -0800] rev 41908
packaging: split downloading code into own module
As we will introduce more code to support packaging, it will be
useful to have download code in its own module.
Differential Revision: https://phab.mercurial-scm.org/D6084