[PATCH 0 of 1 V3] exewrapper: adapt for legacy HackableMercurial

[Adrian Buehlmann]

A minor update to V2 of this patch.

Notable change to V2: Now writes the comment

  /* this file is autogenerated by setup.py */

to the mercurial/hgpythonlib.h file, analogously to what is done for __version__.py.



As a side note, I've digged a bit further to find out why the PythonXX.dll
finds a globally installed Python install dir (when there is no hg-python).

For finding the Python libs, it looks like the registry is important. For example, for an
x86 Python 2.7 which is globally installed on a x64 Windows 7, the installer sets (among others)
the following registry bits (*.reg file syntax):

  [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\InstallPath]
  @="C:\\Python27_x86\\"

  [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\PythonPath]
  @="C:\\Python27_x86\\Lib;C:\\Python27_x86\\DLLs;C:\\Python27_x86\\Lib\\lib-tk"

For a x64 Python 2.7 on x64 Windows 7, the relevant parts are:

  [HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath]
  @="C:\\Python27_x64\\"

  [HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath]
  @="C:\\Python27_x64\\Lib;C:\\Python27_x64\\DLLs;C:\\Python27_x64\\Lib\\lib-tk"

Testing demonstrates that the registry keys seem not be used if Py_SetPythonHome
is used (in the hg-python case).

The call (line 107)

		pydll = LoadLibrary(HGPYTHONLIB);

in exewrapper.c is really the important point to still be able to find the
pythonXX.dll by using the normal dll-finding rules of Windows. It's
important to give only the name of the dll file to LoadLibrary(), not a full
path. That way, a globally installed pythonXX.dll can be found (if there
is no hg-python subdir).

This combines parts of the exemaker logic with the "static" import lib / Python.h
behavior we implicitly used before.