The selection is somewhat arbitrary. In the case of the Zsh completion
file, it will not conflict with the builtin Zsh completions: they
are in a file named `_mercurial', not `_hg'.
Remove the `install_package_data' subclass of `install_data' and use
the `package_data' functionality provided by distutils instead. As
package data must be located within the package directory, the data
files are now generated in the build directory.
To simplify the functionality of this change, the top-level `doc' and
`templates' directories have been moved into the `mercurial' package
directory.
Previously, setup.py was enhanced to identify the Mercurial version
from either .hg/ or mercurial/__version__.py. When archives are
created using 'hg archive' or via hgweb, neither of those options are
available. However, there is a .hg_archival.txt file in the root of
the archive that has the information. This patch enhances setup.py to
identify the Mercurial version from the .hg_archival.txt file when
there is no .hg/ or mercurial/__version__.py available.
There is a problem with setup.py where it will not identify the Mercurial
version properly when not being ran in within a repository even if
mercurial/__version__.py exists.
To fix, use mercurial.__version__.version when available before defaulting
to "unknown". (Using mercurial.util.version() is not an option due to a
dependency issue where osutil can be referenced before it is built.)
- don't do version detection if there's no .hg directory
- shrink try: clause
- don't write __version__.py if version is unknown
(we might overwrite the real version)
This flag will make the build_py step install the pure Python modules
in mercurial/pure/ into mercurial/ and furthermore prevent building
the C extensions.
The target update-pot extracts strings using pygettext and updates the
i18n/hg.pot file. The translators can then use msgmerge to merge the
new strings in hg.pot with their xx.po file when they want to.
The setup.py file now includes files under both templates/ and i18n/
as data files.
- simplify version detection code
- move detection code into setup.py
- move version reading function into util.py
- drop version.py code
This makes hg more closely follow its own recommendation of how to deal with
versioning your builds: use hg id in your build script.
Use information provided by FindFile... Win32 calls
to generate stat information without lstat call per file.
rwx bits in st_mode are ignored as they are not stored in Win32 fs
and Mercurial does not use them
Unicode path / path names over _MAX_PATH are intentionally not supported.
With Python 2.5, the email package is not fully loaded by py2exe, due to
dynamic imports which are not found by modulefinder. This breaks the patchbomb
extension. This patch forces the whole email package to be included so that
the dynamic imports work as expected.
Debian Etch doesn't include a sys/inotify.h header, which makes it
impossible to compile _inotify.c, making hg uninstallable.
The cc.has_function() method is implemented by trying to compile a
simple C program. Since there's no redirection involved all error
messages are sent to the terminal. This is not particularly pretty
but at least it allows the installation to complete.
Further the installation of packagescan over demandload is moved to the
packagescan module.
I added as well few more comments in the packagescan module to avoid
the wrong use of package scan in the future.
Reason:
mercurial.packagescan acts as fake mercurial.demandload during a py2exe
run. Unfortunatly the import of mercurial.version in setup.py is done
before mercurial.packagescan is installed. This results in few imports
without mercurial.packagescan in charge and therefore not all dependend
modules are detected when running mercurial.packagescan.getmodules
later e.g. winerror is missed.
Description:
- If the py2exe distutils extention is installed this patch allows
building standalone exe for windows - example:
> python setup.py build --compiler=mingw32 py2exe
- The 'out of the box' py2exe is not able to resolve
the dependencies due to 'demandload'. A new helper module
of scanning the mercurial package has been added.
Changed:
- setup.py: importing py2exe and sub classing its command class
to fetch the build directory and insert the needed includes
- packagescan.py: new helper module added, that scans the distutil
build directory for modules to be included.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Make it possible to specify a version number in setup.py.
manifest hash: 905feb305205801eb3833e5a84161fb57b83c86e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCtc/QW7P1GVgWeRoRAlCaAJ9G2GRf0wIEVEbYNoV4PjV4b024bQCfcUFf
WVYQlTXqninDXyKas2yQYdo=
=ofg/
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Replace tkmerge with hgmerge
hgmerge attempts to find and use merge, kdiff3, tkmerge, and diff+patch.
hg will use hgmerge unless overridden with HGMERGE
manifest hash: 9137a620df4b235e66343b0fd0dba87fe631546e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCoRGrywK+sNU5EO8RAi2VAJ9bh97ChGJymP/p8rvCuyNAMnk1bQCgrIGP
vYI6qlyWKQZ01ObUTAIg92o=
=+mRH
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bump the version number to 0.5b for the protocol change
manifest hash: a7930fa15b716eb90613bd761b47c27331ea4b8b
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCmz7pywK+sNU5EO8RAt7dAJ4qmUpDRS7/JP/JpLm8uXZ0c+5W/ACfVb0Q
99rjYslSjJfOWYLCKiAzVyU=
=WVVg
-----END PGP SIGNATURE-----
This ought to use package_data but that doesn't exist in Python 2.3.
So we do a hack of install_data and use glob.
This also adds templatepath() to hgweb.py which finds the templates
relative to hgweb.py's location.
