Summary:
Previously, the main script is hard-coded as `hg`. We use a wrapper named
`hg` for logging. Therefore make the name more flexible by reading `HGNAME`.
The name is enforced starting with `hg` and cannot have strange characters.
Test Plan:
`HGNAME=hg-foobar python setup.py install --user`. Make sure the `hg-foobar`
script gets installed in `~/.local/bin`, has the correct `libdir` set, is
working, and the working copy does not have `hg-foobar`.
Also make sure `make local` does not write `$HGNAME` in the working copy.
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: durham, phillco
Differential Revision: https://phabricator.intern.facebook.com/D6695942
Signature: 6695942:1515633395:dec1d46590a1210f2012de964f4b4ad830af9292
Summary:
Newer gcc might add new warnings without notice. Having `-Werror` might break
build with newer gcc. For example, I got the following error with gcc 7.2:
```
In file included from /usr/include/python2.7/Python.h:80:0,
from hgext/extlib/cstore/py-cstore.cpp:14:
./hgext/extlib/cstore/py-treemanifest.h: In function ‘PyObject* treemanifest_hasdir(py_treemanifest*, PyObject*)’:
/usr/include/python2.7/object.h:769:22: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
((PyObject*)(op))->ob_refcnt++)
^
/usr/include/python2.7/boolobject.h:27:31: note: in expansion of macro ‘Py_INCREF’
#define Py_RETURN_TRUE return Py_INCREF(Py_True), Py_True
^~~~~~~~~
./hgext/extlib/cstore/py-treemanifest.h:536:5: note: in expansion of macro ‘Py_RETURN_TRUE’
Py_RETURN_TRUE;
^~~~~~~~~~~~~~
/usr/include/python2.7/object.h:769:22: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
((PyObject*)(op))->ob_refcnt++)
^
/usr/include/python2.7/boolobject.h:28:32: note: in expansion of macro ‘Py_INCREF’
#define Py_RETURN_FALSE return Py_INCREF(Py_False), Py_False
^~~~~~~~~
./hgext/extlib/cstore/py-treemanifest.h:538:5: note: in expansion of macro ‘Py_RETURN_FALSE’
Py_RETURN_FALSE;
^~~~~~~~~~~~~~~
./hgext/extlib/cstore/py-treemanifest.h: In function ‘PyObject* treemanifest_text(py_treemanifest*, PyObject*, PyObject*)’:
/usr/include/python2.7/object.h:769:22: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
((PyObject*)(op))->ob_refcnt++)
^
./hgext/extlib/cstore/py-treemanifest.h:1309:5: note: in expansion of macro ‘Py_INCREF’
Py_INCREF(Py_False);
^~~~~~~~~
hgext/extlib/cstore/py-cstore.cpp: In function ‘void initcstore()’:
/usr/include/python2.7/object.h:769:22: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
((PyObject*)(op))->ob_refcnt++)
^
hgext/extlib/cstore/py-cstore.cpp:37:3: note: in expansion of macro ‘Py_INCREF’
Py_INCREF(&cdatapack_type);
^~~~~~~~~
/usr/include/python2.7/object.h:769:22: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
((PyObject*)(op))->ob_refcnt++)
^
hgext/extlib/cstore/py-cstore.cpp:45:3: note: in expansion of macro ‘Py_INCREF’
Py_INCREF(&treemanifestType);
^~~~~~~~~
/usr/include/python2.7/object.h:769:22: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
((PyObject*)(op))->ob_refcnt++)
^
hgext/extlib/cstore/py-cstore.cpp:53:3: note: in expansion of macro ‘Py_INCREF’
Py_INCREF(&datapackstoreType);
^~~~~~~~~
/usr/include/python2.7/object.h:769:22: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
((PyObject*)(op))->ob_refcnt++)
^
hgext/extlib/cstore/py-cstore.cpp:61:3: note: in expansion of macro ‘Py_INCREF’
Py_INCREF(&uniondatapackstoreType);
^~~~~~~~~
```
Explicitly suppressing warnings might break older gcc that does not support
those flags. Ideally the fix would be changing the source code. But in this
case it's in a library that cannot be easily fixed here in this repo.
Therefore just remove `-Werror`.
Test Plan: Confirm `make build` works after the change.
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: durham
Differential Revision: https://phabricator.intern.facebook.com/D6695948
Signature: 6695948:1515633376:67f40f0489b69a70700e181313d8ad837a76a2c9
Summary:
This test discovers what python files are available and ensures help
text is available. Since hgsubversion is now in the repo, we need to enable it
so `hg help subversion` works.
Test Plan: Ran the tests
Reviewers: singhsrb, #mercurial
Reviewed By: singhsrb
Differential Revision: https://phabricator.intern.facebook.com/D6698628
Signature: 6698628:1515629061:5cc01e14e6884010e76608f51dbc675d79374568
Summary: Adds to setup.py so it gets copied in the build.
Test Plan: make local
Reviewers: quark, singhsrb, #mercurial
Reviewed By: quark, singhsrb
Differential Revision: https://phabricator.intern.facebook.com/D6698615
Signature: 6698615:1515628425:85db99ed0dca711fb22b37216d7fbb3aa972ee8f
Summary:
Moves the moreversion extension to hgext/ and updates the core setup.py
to process it. Eventually we should get rid of this and store the version number
as the normal Mercurial number, but that can happen later.
Test Plan:
make local && ./hg version
Mercurial Distributed SCM (version 4.4.2+8922-aa235b4cbeac+20180110)
Facebook Mercurial release: UNKNOWN-RELEASE
Reviewers: phillco, #mercurial
Reviewed By: phillco
Differential Revision: https://phabricator.intern.facebook.com/D6696199
Signature: 6696199:1515621476:7835f9110ec143737c488faf49cf547eee8f918e
Summary:
This is part of the overall plan to move extensions from fb-hgext to
hgext. Follow up commits will address some of the test issues and move the
infinitepush related tests out of fb-hgext to hgext.
Test Plan: Ran all the tests.
Reviewers: rmcelroy, #mercurial, #sourcecontrol
Reviewed By: rmcelroy
Differential Revision: https://phabricator.intern.facebook.com/D6691670
Signature: 6691670:1515578586:8d7836aebb474856559c6dbe6fe2f572c8bdf7f1
Summary: This makes fb_build_nupkg.py work again on Windows.
Test Plan:
- run `python fb_build_nupkg.py clean build --release test`
- run `.\build\hg\hg.exe sl` and some similar commands, see things pass
Reviewers: rmcelroy, #sourcecontrol
Reviewed By: rmcelroy
Differential Revision: https://phabricator.intern.facebook.com/D6692551
Signature: 6692551:1515591647:b23106a6a4bbd7b6443512cc6f4514c8092b78d8
Summary:
Rust dependencies are vendored in by downloading a package containing all Rust
dependencies.
The package can be updated using the new `vendorcrates.py` script.
Test Plan: Build using the vendored packages.
Reviewers: quark, #mercurial
Reviewed By: quark
Differential Revision: https://phabricator.intern.facebook.com/D6689642
Tasks: T24908724
Signature: 6689642:1515548647:8051ec3dadd98873f0312bb67978846ba029b558
Summary:
This reduces the number of situations we have to think about, like whether to
enable clindex, treedirstate or not.
Test Plan: `make local`
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: durham, mbthomas
Differential Revision: https://phabricator.intern.facebook.com/D6687198
Signature: 6687198:1515543062:c4202564bce0f602ad4f898c23c9eeadd635aa3d
Summary: This was being reported by the test-check-pyflakes.t
Test Plan: Ran test-check-pyflakes.t.
Reviewers: phillco, #mercurial, #sourcecontrol
Reviewed By: phillco
Differential Revision: https://phabricator.intern.facebook.com/D6687882
Signature: 6687882:1515537725:e00da283e422ea363d11abd20cc63277bbe5cd9b
Summary: Also make it compatible with Windows by making it a no-op on Windows.
Test Plan:
`make local` and try from IPython:
```
In [1]: from hgext import patchrmdir
In [2]: os.rmdir
Out[2]: <function posix.rmdir>
In [3]: patchrmdir.uisetup(None)
In [4]: os.rmdir
Out[4]: <functools.partial at 0x375f580>
```
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: durham, fried
Differential Revision: https://phabricator.intern.facebook.com/D6681125
Signature: 6681125:1515523144:e186b45978d4a82ec8a0d18a02b0a524fca1c3b3
Summary:
Get rid of `gettimeofday` and switch to C++11 `std::chrono` for Windows/rare
platform compatibility.
Also format the code using clang-format.
Test Plan:
Make sure it build on both x64 and Power8 platform.
`make local` and try it in IPython:
```
In [1]: from hgext import traceprof
In [2]: def f():
...: g(1)
...:
In [3]: def g(x):
...: print(x+1)
...:
In [4]: from mercurial import ui
In [7]: with traceprof.profile(ui.ui(), sys.stderr):
...: f()
...:
2
| <module> ipython2:3
| start_ipython IPython/__init__.py:93
| launch_instance application.py:650
| start ipapp.py:342
| mainloop interactiveshell.py:479
| interact interactiveshell.py:459
| run_cell interactiveshell.py:2591
| run_ast_nodes interactiveshell.py:2770
| run_code interactiveshell.py:2851
| <module> <ipython-input-7-2e5a012739d1>:1
| __exit__ contextlib.py:21
Total time: 0 ms
```
Note: it crashes on Windows, which will be workarounded in a later patch.
Reviewers: rmcelroy, #mercurial
Reviewed By: rmcelroy
Subscribers: fried
Differential Revision: https://phabricator.intern.facebook.com/D6681062
Tags: aarch64
Signature: 6681062:1515488414:6b7a51eda9e9764560d415350630590e4817fae2
Summary:
clindex is an hg extension, so moved to `hgext`.
linelog is not an hg extension, but is only used by hg extensions, not
`mercurial/`, so moved to `hgext/extlib`.
Test Plan: `make local` and `run-tests.py` without `-l` and with an empty `PYTHONPATH`.
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: fried
Differential Revision: https://phabricator.intern.facebook.com/D6685080
Signature: 6685080:1515525106:88ebb275d0cac041911f243a3e82b82482b6cd34
Summary: clindex does not use any POSIX APIs so it can work on Windows.
Test Plan: `make local` on both Windows and Linux.
Reviewers: durham, #mercurial
Reviewed By: durham
Differential Revision: https://phabricator.intern.facebook.com/D6684821
Signature: 6684821:1515523520:aa48d4669fe658563f9457fc1a6194ec7fadd937
The rust directory should be removed. fastmanifest should've had a module added
to setup.py. I accidentally moved a fastmanifest test in my earlier commit, so I
need to update it.
setup.py needs an explicit list of all the directory modules, otherwise it
doesn't build them. This caused test-help to fail when run without -l because
they weren't copied to the target directory. I'm not sure how the tests have
been passing actually. My guess is they were importing the extensions from the
system python.
Summary:
Moves ctreemanifest into hgext/extlib/. D6679698 was committed to scratch branch
by mistake.
Test Plan: make local && cd tests && ./run-tests.py
Reviewers: durham, #mercurial, #sourcecontrol
Reviewed By: durham
Differential Revision: https://phabricator.intern.facebook.com/D6684623
Signature: 6684623:1515522634:9bec363d00990d9ff7d5f655e30ab8cae636155c
Summary:
Moves the remotefilelog extension into hgext/ and it's tests into
tests/.
I did not fix up all the check-module errors, since it's a ton of work for
very little impact at this point.
Test Plan: make local && ./run-tests.py
Reviewers: #mercurial
Differential Revision: https://phabricator.intern.facebook.com/D6680030
Summary:
This moves the cdatapack code to the new lib/ directory and adds it to the main
setup.py.
Test Plan: hg purge --all && make local && cd tests && ./run-tests.py -S -j 48
Reviewers: #mercurial
Differential Revision: https://phabricator.intern.facebook.com/D6677491
Summary:
The `lib/linelog` directory contains pure C code that is unrelated from
either Mercurial or Python. The `mercurial/cyext` contains Cython extension
code (although for linelog's case, the Cython extension is unrelated from
Mercurial).
Cython is now a hard dependence to simplify the code.
Test Plan: `make local` and check `from mercurial.cyext import linelog` works.
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: durham, fried
Differential Revision: https://phabricator.intern.facebook.com/D6678541
Signature: 6678541:1515455512:967266dc69c702dbff95fdea05671e11c32ebf28
Summary:
Move the rust libraries and extensions to their new locations, and integrate
them with the hg-crew setup.py.
Test Plan: Run `python setup.py build` and verify rust extensions are built.
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: fried, jsgf, mitrandir
Differential Revision: https://phabricator.intern.facebook.com/D6677251
Tasks: T24908724
Signature: 6677251:1515450235:920faf40babbce9b09e3283ff9ca328d1c5c51e6
Summary:
cdatapack depends on sha1detectcoll, so let's add the library to setup.py before
we add cdatapack.
Test Plan:
hg purge --all && make local && cd tests/ && ./run-tests.py -S -j 48
Verified sha1dc was in the build output and the tests passed.
Reviewers: quark, #mercurial
Reviewed By: quark
Differential Revision: https://phabricator.intern.facebook.com/D6676405
Signature: 6676405:1515444508:2da65c6c3a18267a1d3c151c8e9acf60b674ffc2
(grafted from 67f37c3d0b13b68d2ec67c60ad4a49887a802dd1)
(grafted from 61cf4ec0aa662a3507aeaad5cec44037ac6956f2)
(grafted from 28de205abf73aba41723bc38e408d2939cefe2fb)
(grafted from 4498771b2622cf1aa3f1278f8e33b9e30c260f39)
(grafted from 2a32eb250049968c2d22c53c59be0973990543cb)
(grafted from ed1bf875a7d869508ec98c033fcb2f425d0bc521)
(grafted from 78e9a3e2a3667ac33251a769f9924a0352c84829)
(grafted from f608e564b0698a7704bbc041576a2472a8f15ccb)
(grafted from 2cab324128a009ad4d2e889ed25d283b1ed8d2ae)
Without this change, setup.py always writes some files on every
invocation. This prevents some builds from being a no-op when they
should. And, since times can sneak into generated .pyc files,
this prevents file content from being deterministic between
builds.
As part of the refactor, we treat file content as bytes.
The only potential regression from this would be if some tool
is looking at mtimes of the changed files to determine if
further action should be taken. But I don't think anything
critically important is keyed off the mtimes of these specific files.
Differential Revision: https://phab.mercurial-scm.org/D1580
If we're going to use the user's installed and configured hg command
(which we do since a4a6cb293e63), we should prevent devel-warn messages
from interfering with locating it.
This commit adds an experimental --long-paths-support flag to build_hgexe
on Windows. It is off by default, but when supplied, causes setup.py to
embed some XML into the generated hg.exe, which in turn tells Windows to
allow this exe to use long paths (given that the appropriate registry setting
is enabled as well).
This was tested on Windows 10 14393 and 15063.
This commit introduces a badly-named initialize_options function, but its name
is dictated by distutils, rather than chosen.
# no-check-commit
The attrs package allows defining namedtuple-like classes with no weird
behavior and no runtime performance cost.
This patch vendors in attrs 17.2.0.
# no-check-commit
Differential Revision: https://phab.mercurial-scm.org/D867
The addition, in 851d08ff7a58, of a hack for the MSVC compiler class was
overwriting the original class for the Mingw32CCompiler class, leading to an
error when the HackedMingw32CCompiler is instantiated.
Differential Revision: https://phab.mercurial-scm.org/D329
Since these modules are implicitly imported by policy.importmod(), py2exe
can't track them statically. cffi modules are excluded for now because they
wouldn't be useful in frozen (i.e. CPython) environment.
My intent was to only allow Python 3 if the right environment variable
is set (for when people want to use `pip install .` on hg
locally). This fixes the bug in my previous change. I verified that
`python3.6 run-tests.py` still passes the tests that passed before,
and that all tests pass on 2.7 (including our virtualenv-using
installation test).
Differential Revision: https://phab.mercurial-scm.org/D185
Modern pip can detect supported Python versions (which we now
declare), and pull down a reasonable release. This trick was suggested
in http://bit.ly/pycon2017-build-bridges, and seems like a good
defensive maneuver so that when we want to move to Python 3 it's
less risky for existing users.
This moves the version-check logic after defining our printf function
so we can print more informative messages.
I think we should probably backport this to 4.2 as well, and do one
more release there that explicitly declares 2.6 support. That way
anyone stuck on Python 2.6 will end up getting the right hg if they
use a modern pip to install. Users can still use `python setup.py`
incantations to attempt installing Mercurial on unsupported Pythons,
including 3.5 and 3.6.
A followup change will switch to only doing our own
Python-version-check logic if we're not being installed by a
reasonable pip.
This extracts charencode.c from parsers.c, which seems big enough for me
to hesitate to add new JSON functions. Still charencode.o is linked to
parsers.so to avoid duplication of binary codes.
Add a findhg() function that tries to be smarter about figuring out how to run
hg for examining the local repository. It first tries running "hg" from the
user's PATH, with the default HGRCPATH settings intact, but with HGPLAIN
enabled. This will generally use the same version of mercurial and the same
settings used to originally clone the repository, and should have a higher
chance of working successfully than trying to run the hg script from the local
repository. If that fails findhg() falls back to the existing behavior of
running the local hg script.
Replace the runhg() function with an hgcommand helper class. hgcommand has as
run() function similar to runhg(), but no longer requires the caller to pass in
the exact path to python and the hg script, and the environment settings for
invoking hg.
For now this diff contains no behavior changes, but in the future this will
make it easier for the hgcommand helper class to more intelligently figure out
the proper way to invoke hg.
Add a helper function to compute the environment used for invoking mercurial,
rather than doing this computation entirely at global scope. This will make it
easier to do some subsequent refactoring.
Update the runcmd() helper function so it also returns the process exit status.
This allows callers to more definitively determine if a command failed, rather
than testing only for the presence of data on stderr.
I don't expect this to have any behavioral changes for now: the commands
invoked by setup generally should print data on stderr if and only if they
failed.
If running hg fails, exit the setup script unsuccessfully, rather than
proceeding to use a bogus version of "+0-". Using an invalid version number
causes various tests to fail later. Failing early makes it easier to identify
the source of the problem.
It is currently easy for setup.py to fail this way since it sets HGRCPTH to the
empty string before running "hg", which may often disable extensions necessary
to interact with the local repository.
The PyMODINIT_FUNC macro contains __declspec(dllexport), and then the build
process adds an "/EXPORT func" to the command line. The 64-bit linker flags
this [1].
Everything except zstd.c and bser.c are covered by redefining the macro in
util.h [2]. These modules aren't built with util.h in the #include path, so the
redefining hack would have to be open coded two more times.
After seeing that extra_linker_flags didn't work, I couldn't find anything
authoritative indicating why, though I did see an offhand comment on SO that
CFLAGS is also ignored on Windows. I also don't fully understand the
interaction between msvccompiler and msvc9compiler- I first subclassed the
latter, but it isn't used when building with VS2008.
I know the camelcase naming isn't the standard, but the HackedMingw32CCompiler
class above it was introduced 5 years ago (and I think the current style was
in place by then), so I assume that there's some reason for it.
[1] https://support.microsoft.com/en-us/help/835326/you-receive-an-lnk4197-error-in-the-64-bit-version-of-the-visual-c-compiler
[2] https://bugs.python.org/issue9709#msg120859
Since the default policy is selected depending on setup options, "make install"
shouldn't overwrite in-source __modulepolicy__.py generated by "make local".
Previously, test-hghave.t was failing on Windows (and on Linux if
$FORCE_SETUPTOOLS was set) with the following:
--- c:/Users/Matt/Projects/hg/tests/test-hghave.t
+++ c:/Users/Matt/Projects/hg/tests/test-hghave.t.err
@@ -19,7 +19,11 @@
> foo
> EOF
$ run-tests.py $HGTEST_RUN_TESTS_PURE test-hghaveaddon.t
+ warning: Testing with unexpected mercurial lib: c:\Users\Matt\Projects\hg\mercurial
+ (expected ...\hgtests.mu9rou\install\lib\python\mercurial)
.
+ warning: Tested with unexpected mercurial lib: c:\Users\Matt\Projects\hg\mercurial
+ (expected ...\hgtests.mu9rou\install\lib\python\mercurial)
Augie relayed concerns[1] about the first attempt at this, which also excluded
'install_egg_info'. All that needs to be excluded to avoid the egg and make the
test work is to filter out 'bdist_egg'. (Actually, the body of this class could
simply be 'pass', and 'bdist_egg' still isn't run. But that seems to magical.)
Also note that prior to this (and still now), `make clean` doesn't delete the
'mercurial.egg-info' that is generated by `make install`.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-May/097668.html
# no-check-commit
parsers.c is ~3000 lines and ~2/3 of it is related to the revlog
index type.
We already have separate C source files for directory utilities
and manifest parsing. I think the quite unwieldy revlog/index
parsing code should be self-contained as well.
I performed the extraction as a file copy then removed content
from both sides in order to preserve file history and blame.
As part of this, I also had to move the hexdigit table and
function to a shared header since it is used by both parsers.c
and revlog.c
# no-check-commit
We're going to make the 'c' policy more strict, where no missing attribute
will be allowed. Since we want to run 'hg bisect' without rebuilding the C
extension modules, we'll need a looser policy for development environment.
The default for system installation isn't changed.
Note that the current 'c' policy is practically 'allow'-ish as we have lots
of adhoc fallbacks to pure functions.
Per discussion on the mailing list and elsewhere, we've decided that
Python 2.6 is too old to continue supporting. We keep accumulating
hacks/fixes/workarounds for 2.6 and this is taking time away from
more important work.
So with this patch, we officially drop support for Python 2.6 and
require Python 2.7 to run Mercurial.
I'm going to restructure cext/pure modules and get rid of our hgimporter
hack. C extension modules will be moved to cext/ directory so old and new
compiled modules can coexist in development tree. This is necessary to
run 'hg bisect' without recompiling.
New extension modules will be loaded by an importer function:
base85 = policy.importmod('base85') # select pure.base85 or cext.base85
This will also allow us to split cffi from pure modules, which is currently
difficult because pure modules can't be imported by name.
Previously we check three things: "statfs" function, "linux/magic.h" and
"sys/vfs.h" headers. But we didn't check "struct statfs" or the "f_type"
field. That means if a system has "statfs" but "struct statfs" is not
defined in the two header files we check, or defined without the "f_type"
field, the compilation will fail.
This patch combines the checks (2 headers + 1 function + 1 field) together
and sets "HAVE_LINUX_STATFS". It makes setup.py faster (less checks), and
more reliable (immutable to the issue above).
We want to use the `f_fstypename` field to get the filesystem type. Test it
directly. The new macro HAVE_BSD_STATFS implys the old HAVE_SYS_MOUNT_H and
HAVE_SYS_PARAM_H. So the latter ones are removed.
The next patch will use "statfs", which requires different header files on
different platforms.
Linux:
sys/vfs.h or sys/statfs.h
FreeBSD or OSX:
sys/param.h and sys/mount.h
Therefore test them so we can include the correct ones.
Something deep in the bowels of distutils expects "version" passed to
setup() to be a str/unicode. So, convert the type.
This still works on Python 2 because the string is ascii and an
implicit coercion back to str/bytes should work without issue. If
it does cause problems, we can always make the unicode conversion
dependent on running Python 3.
This change makes `python3.5 setup.py install` work.
We've had a long, complicated history with setuptools. We want to
make it the universal default. But when we do, it breaks things.
`python setup.py build` is broken on Windows today. Forcing
the use of setuptools via FORCE_SETUPTOOLS=1 unbreaks things.
Since the previous bustage with making setuptools the default
was on !Windows, it seems safe to move ahead with the setuptools
transition on Windows. So this patch does that.
This patch also makes some expected output lines in tests glob-ed for
persistence of them.
BTW, files below aren't yet changed in 2017, but this patch also
updates copyright of them, because:
- mercurial/help/hg.1.txt
almost all of "man hg" output comes from online help of hg
command, and is already changed in 2017
- mercurial/help/hgignore.5.txt
- mercurial/help/hgrc.5
"copyright 2005-201X Matt Mackall" in them mentions about
copyright of Mercurial itself
This patch also adds new check-code.py pattern to detect invalid usage
of "mercurial@selenic.com".
Change for test-convert-tla.t is tested, but similar change for almost
same test-convert-baz.t isn't yet tested actually, because I couldn't
find out the way to get "GNU Arch baz client".
AFAIK, buildbot skips test-convert-baz.t, too. Does anybody have
appropriate environment for testing?
The next release from upstream adds another named argument to this
function. Specify arguments by name so there is no ambiguity about
which argument is being passed.
Downstream packagers will inevitably want to disable building the
vendored python-zstandard Python package. Rather than force them
to patch setup.py, let's give them a knob to use.
distutils Command classes support defining custom options. It requires
setting certain class attributes (yes, class attributes: instance
attributes don't work because the class type is consulted before it
is instantiated).
We already have a custom child class of build_ext, so we set these
class attributes, implement some scaffolding, and override
build_extensions to filter the Extension instance for the zstd
extension if the `--no-zstd` argument is specified.
Example usage:
$ python setup.py build_ext --no-zstd
Now that zstd and python-zstandard are vendored, we can start compiling
them as part of the install.
python-zstandard provides a self-contained Python function that returns
a distutils.extension.Extension, so it is really easy to add zstd
to our setup.py without having to worry about defining source files,
include paths, etc. The function even allows specifying the module
name the extension should be compiled as. This conveniently allows us
to compile the module into the "mercurial" package so "our" version
won't collide with a version installed under the canonical "zstd"
module name.
We are going to use setproctitle (provided by FreeBSD) if it's available in
the next patch. Therefore provide a macro to give some clues to the C
pre-processor so it could choose code path wisely.
This patch moves all setup*cffi stuff to mercurial/cffi to make the root
directory cleaner. The idea was from mpm [1]:
> It seems like we could have a fair amount of cffi definitions, and
> cluttering the root directory (or mercurial/) with them is probably not
> a great long-term solution. We could probably add a cffi/ directory
> under mercurial/ to parallel pure/.
[1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-July/086442.html
