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
