##// END OF EJS Templates
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

File last commit:

r41102:72d4a176 default
r42019:d7dc4ac1 default
Show More
__init__.py
194 lines | 7.1 KiB | text/x-python | PythonLexer
# Copyright 2009-2010 Gregory P. Ward
# Copyright 2009-2010 Intelerad Medical Systems Incorporated
# Copyright 2010-2011 Fog Creek Software
# Copyright 2010-2011 Unity Technologies
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
'''track large binary files
Large binary files tend to be not very compressible, not very
diffable, and not at all mergeable. Such files are not handled
efficiently by Mercurial's storage format (revlog), which is based on
compressed binary deltas; storing large binary files as regular
Mercurial files wastes bandwidth and disk space and increases
Mercurial's memory usage. The largefiles extension addresses these
problems by adding a centralized client-server layer on top of
Mercurial: largefiles live in a *central store* out on the network
somewhere, and you only fetch the revisions that you need when you
need them.
largefiles works by maintaining a "standin file" in .hglf/ for each
largefile. The standins are small (41 bytes: an SHA-1 hash plus
newline) and are tracked by Mercurial. Largefile revisions are
identified by the SHA-1 hash of their contents, which is written to
the standin. largefiles uses that revision ID to get/put largefile
revisions from/to the central store. This saves both disk space and
bandwidth, since you don't need to retrieve all historical revisions
of large files when you clone or pull.
To start a new repository or add new large binary files, just add
--large to your :hg:`add` command. For example::
$ dd if=/dev/urandom of=randomdata count=2000
$ hg add --large randomdata
$ hg commit -m "add randomdata as a largefile"
When you push a changeset that adds/modifies largefiles to a remote
repository, its largefile revisions will be uploaded along with it.
Note that the remote Mercurial must also have the largefiles extension
enabled for this to work.
When you pull a changeset that affects largefiles from a remote
repository, the largefiles for the changeset will by default not be
pulled down. However, when you update to such a revision, any
largefiles needed by that revision are downloaded and cached (if
they have never been downloaded before). One way to pull largefiles
when pulling is thus to use --update, which will update your working
copy to the latest pulled revision (and thereby downloading any new
largefiles).
If you want to pull largefiles you don't need for update yet, then
you can use pull with the `--lfrev` option or the :hg:`lfpull` command.
If you know you are pulling from a non-default location and want to
download all the largefiles that correspond to the new changesets at
the same time, then you can pull with `--lfrev "pulled()"`.
If you just want to ensure that you will have the largefiles needed to
merge or rebase with new heads that you are pulling, then you can pull
with `--lfrev "head(pulled())"` flag to pre-emptively download any largefiles
that are new in the heads you are pulling.
Keep in mind that network access may now be required to update to
changesets that you have not previously updated to. The nature of the
largefiles extension means that updating is no longer guaranteed to
be a local-only operation.
If you already have large files tracked by Mercurial without the
largefiles extension, you will need to convert your repository in
order to benefit from largefiles. This is done with the
:hg:`lfconvert` command::
$ hg lfconvert --size 10 oldrepo newrepo
In repositories that already have largefiles in them, any new file
over 10MB will automatically be added as a largefile. To change this
threshold, set ``largefiles.minsize`` in your Mercurial config file
to the minimum size in megabytes to track as a largefile, or use the
--lfsize option to the add command (also in megabytes)::
[largefiles]
minsize = 2
$ hg add --lfsize 2
The ``largefiles.patterns`` config option allows you to specify a list
of filename patterns (see :hg:`help patterns`) that should always be
tracked as largefiles::
[largefiles]
patterns =
*.jpg
re:.*\\.(png|bmp)$
library.zip
content/audio/*
Files that match one of these patterns will be added as largefiles
regardless of their size.
The ``largefiles.minsize`` and ``largefiles.patterns`` config options
will be ignored for any repositories not already containing a
largefile. To add the first largefile to a repository, you must
explicitly do so with the --large flag passed to the :hg:`add`
command.
'''
from __future__ import absolute_import
from mercurial import (
cmdutil,
extensions,
exthelper,
hg,
httppeer,
localrepo,
sshpeer,
wireprotov1server,
)
from . import (
lfcommands,
overrides,
proto,
reposetup,
)
# Note for extension authors: ONLY specify testedwith = 'ships-with-hg-core' for
# extensions which SHIP WITH MERCURIAL. Non-mainline extensions should
# be specifying the version(s) of Mercurial they are tested with, or
# leave the attribute unspecified.
testedwith = 'ships-with-hg-core'
eh = exthelper.exthelper()
eh.merge(lfcommands.eh)
eh.merge(overrides.eh)
eh.merge(proto.eh)
eh.configitem('largefiles', 'minsize',
default=eh.configitem.dynamicdefault,
)
eh.configitem('largefiles', 'patterns',
default=list,
)
eh.configitem('largefiles', 'usercache',
default=None,
)
cmdtable = eh.cmdtable
configtable = eh.configtable
extsetup = eh.finalextsetup
reposetup = reposetup.reposetup
uisetup = eh.finaluisetup
def featuresetup(ui, supported):
# don't die on seeing a repo with the largefiles requirement
supported |= {'largefiles'}
@eh.uisetup
def _uisetup(ui):
localrepo.featuresetupfuncs.add(featuresetup)
hg.wirepeersetupfuncs.append(proto.wirereposetup)
cmdutil.outgoinghooks.add('largefiles', overrides.outgoinghook)
cmdutil.summaryremotehooks.add('largefiles', overrides.summaryremotehook)
# create the new wireproto commands ...
wireprotov1server.wireprotocommand('putlfile', 'sha', permission='push')(
proto.putlfile)
wireprotov1server.wireprotocommand('getlfile', 'sha', permission='pull')(
proto.getlfile)
wireprotov1server.wireprotocommand('statlfile', 'sha', permission='pull')(
proto.statlfile)
wireprotov1server.wireprotocommand('lheads', '', permission='pull')(
wireprotov1server.heads)
extensions.wrapfunction(wireprotov1server.commands['heads'], 'func',
proto.heads)
# TODO also wrap wireproto.commandsv2 once heads is implemented there.
# can't do this in reposetup because it needs to have happened before
# wirerepo.__init__ is called
proto.ssholdcallstream = sshpeer.sshv1peer._callstream
proto.httpoldcallstream = httppeer.httppeer._callstream
sshpeer.sshv1peer._callstream = proto.sshrepocallstream
httppeer.httppeer._callstream = proto.httprepocallstream
# override some extensions' stuff as well
for name, module in extensions.extensions():
if name == 'rebase':
# TODO: teach exthelper to handle this
extensions.wrapfunction(module, 'rebase',
overrides.overriderebase)
revsetpredicate = eh.revsetpredicate