- Jun 17, 2017
-
-
Matt Harbison authored
-
- Jun 16, 2017
-
-
Matt Harbison authored
-
- Jun 10, 2017
-
-
Matt Harbison authored
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
-
- Jun 06, 2017
-
-
Augie Fackler authored
Since we're filtering out some egg gunk, we need to emulate these flags which disable eggs so that pip still works.
-
- Jun 03, 2017
-
-
Yuya Nishihara authored
Since the default policy is selected depending on setup options, "make install" shouldn't overwrite in-source __modulepolicy__.py generated by "make local".
-
- May 08, 2017
-
-
Matt Harbison authored
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
-
- May 02, 2017
-
-
Yuya Nishihara authored
Don't pollute the top-level namespace.
-
Yuya Nishihara authored
This frees up cffi package for modules to be split from pure.
-
- May 21, 2017
-
-
Siddharth Agarwal authored
In Python 3, demand loading is per-package. Keeping demandimport in the mercurial package would disable demand loading for any modules in mercurial.
-
Yuya Nishihara authored
Since util.h isn't useful in plain C module, it should be placed in CPython extension directory.
-
- May 20, 2017
-
-
Gregory Szorc authored
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
-
- Aug 13, 2016
-
-
Yuya Nishihara authored
# no-check-commit
-
Yuya Nishihara authored
-
Yuya Nishihara authored
# no-check-commit
-
Yuya Nishihara authored
# no-check-commit
-
Yuya Nishihara authored
-
- Aug 12, 2016
-
-
Yuya Nishihara authored
"make clean" is recommended to test this change, though C API compatibility should be preserved.
-
- Apr 26, 2017
-
-
Yuya Nishihara authored
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.
-
- May 02, 2017
-
-
Gregory Szorc authored
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.
-
- Aug 12, 2016
-
-
Yuya Nishihara authored
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.
-
- May 03, 2017
-
-
Alex Gaynor authored
It is documented as existing since Python 2.0, and empirically from other OSS projects I maintain, there is no problem relying on its existance.
-
- Mar 24, 2017
-
-
Jun Wu authored
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).
-
Jun Wu authored
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.
-
- Mar 20, 2017
-
-
Jun Wu authored
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.
-
Jun Wu authored
statfs is not defined by POSIX but is available in various systems to help decide filesystem type. Let's detect it and set the macro HAVE_STATFS.
-
Jun Wu authored
-
Jun Wu authored
The next patch wants to test include files.
-
- Mar 12, 2017
-
-
Gregory Szorc authored
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.
-
- Mar 08, 2017
-
-
durin42 authored
debuginstall now runs cleanly in Python 3.
-
- Mar 10, 2017
-
-
Gregory Szorc authored
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.
-
- Feb 11, 2017
-
-
Katsunori FUJIWARA authored
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
-
- Feb 10, 2017
-
-
Katsunori FUJIWARA authored
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?
-
- Jan 05, 2017
-
-
Gregory Szorc authored
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.
-
- Oct 28, 2016
-
-
Gábor Stefanik authored
This is required for building with pypiwin32, the pip-installable replacement for pywin32.
-
- Nov 18, 2016
-
-
Gregory Szorc authored
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
-
- Nov 11, 2016
-
-
Gregory Szorc authored
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.
-
Jun Wu authored
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.
-
- Nov 09, 2016
-
-
Jun Wu authored
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
-
- Jul 28, 2016
-
-
Maciej Fijalkowski authored
-
- Jul 25, 2016
-
-
Maciej Fijalkowski authored
-