We give up using CPython's PythonXX.lib import libraries (and Python.h), and
now "manually" call the LoadLibrary() / GetProcAddress() Windows API's instead.
If there is a "hg-python" subdirectory (the canonical directory name for
HackableMercurial's private Python copy) next to the hg.exe, we load the
pythonXX.dll from there (feeding an absolute path to LoadLibrary) and we set
Py_SetPythonHome() to that directory, so that the Python libraries are used
from there as well.
If there is no "hg-python" subdir found next to the hg.exe, we do not feed an
absolute path to LoadLibrary. This continues to allow to find a globally
installed Python DLL, as before this change - that is, without having to edit,
delete, rename, or configure anything.
Note that the hg.exe built is still bound to a *specific* major version of the
pythonXX.dll (e.g. python27.dll). What version it is, is inferred from the
version of the python interpreter that was used when calling setup.py. For
example
C:\python27_x86\python.exe setup.py build_hgexe -i --compiler=mingw32
builds a hg.exe (using the mingw32 tool chain) bound to (x86) Python 2.7. And
C:\python27_x86\python.exe setup.py build_hgexe -i
builds the same using the Microsoft C compiler/linker. (Note that the Microsoft
toolchain combined with x64 CPython can be used to build an x64 hg.exe.)
setup.py is changed to write the name of the pythonlib into the generated header
file "mercurial/hgpythonlib.h", which is #included by exewrapper.c. For a Python
2.7 build, it for example contains:
#define HGPYTHONLIB "python27"
exewrapper.c then uses HGPYTHONLIB for the name of the Python dll to load.
We don't want to track mercurial/hgpythonlib.h, so we add it to .hgignore.
The old calculation code failed to properly identify revs that
weren't tagged, leaving us with a version of "unknown" most of the
time during development.
Not yet used (will be enabled in a later patch).
This patch is a stripped down version of patches originally created by
Bryan O'Sullivan <bryano@fb.com>
This gcc option has been deprecated since at least 2009 (gcc 4.4),
and it causes compilations to fail entirely with gcc 4.6.x.
Upstream distutils bug: http://bugs.python.org/issue12641
This patch contains support for Plan 9 from Bell Labs. A README is
provided in contrib/plan9 which describes the port in greater detail.
A new extension is also provided named factotum which permits the
factotum(4) authentication agent to provide credentials for HTTP
repositories. This extension is also applicable to other POSIX
platforms which make use of Plan 9 from User Space (aka plan9ports).
Apparently, it prints nothing at all if the user installed only the
command-line tools. In that case, don't try to parse the empty output
-- just assume they have Xcode >= 4.
Merge the code from contrib/setup3.py in setup.
The argument for executing is marked as experimental.
Reason: The file in contrib was outdated (packages, cmdclass, ...)
If Python interpreter was built under Linux 3.x kernel, it reports
sys.platform to be 'linux3' (it is fixed for Python 3, but not for 2.x).
This cancels building inotify extension, which was built only for 'linux2'
platform. Improved test checks if sys.platform begins with 'linux', and together
with test for kernel version to be greater than 2.6 it seems to cover all known
cases.
It generates prebuilt index of all extensions, which will be used by
frozen exe when running 'hg help extensions'.
Now py2exe invokes this command automatically.
Fink's python is either i386 or amd64, but not universal. Setting ARCHFLAGS to the
empty string produces a successful build against both OS X python and fink python.
The modules will no longer be universal -- if that is an issue, we can change the
test to extract ARCHFLAGS from distutils.sysconfig and remove ppc if necessary.
This is revision a4229f13c374 of
http://py-nonblocking-http.googlecode.com/ with a no-check-code
comment added to the end of each file using `for fi in $(hg manifest |
grep mercurial/httpclient/) ; echo '# no-check-code' >> $fi`.
The previous test assumed that 'os.name' was "mac" on Mac OS X. This
is not the case; 'mac' was classic Mac OS, whereas Mac OS X has 'os.name'
be 'posix'.
Please note that this change will break Mercurial on hypothetical
non-Mac OS X deployments of Darwin.
Credit to Brodie Rao for thinking of CGSessionCopyCurrentDictionary()
and Kevin Bullock for testing.
Sometimes xcodebuild prints warnings to stderr, but runcmd() assumes anything
printed to stderr implies failure. Since runcmd() was originally only
intended to run hg, this was fine until it was pressed into service for
running xcodebuild. Thus: split runcmd() into two parts: runcmd(), which does
the minimal amount of work to run a subprocess, and runhg(), which calls
runcmd().
Add missing calls to close() to many places where files are
opened. Relying on reference counting to catch them soon-ish is not
portable and fails in environments with a proper GC, such as PyPy.
This provides two new features:
- Mercurial may be installed into a non-standard location without
having to set PYTHONPATH.
- Multiple installations can use Mercurial from different locations.
This patch adds access to util.h for the inotify C module by adding the
"mercurial" directory as an include dir, enabling access to the macros defined
in util.h.
In py3k, subprocess.Popen.communicate's output are bytes objects. String
literals are Unicode objects. Thus, when a bytes object startswith method is
called, with string literals, it fails. What this patch does is:
* Convert the string (unicode in py3k) literals to bytes objects;
* As "bytes" is not a builtin in python < 2.6, it defines a "b" helper
function that merely returns its argument, as suggested by Antoine Pitrou.
