Skip to content
  • Adrian Buehlmann's avatar
    exewrapper: adapt for legacy HackableMercurial · 93d97a212559
    Adrian Buehlmann authored
    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.
    93d97a212559