[PATCH STABLE] exewrapper: adapt for legazy HackableMercurial

[Patrick Mézard]

Le 31/07/12 22:30, Adrian Buehlmann a écrit :
> On 2012-07-31 22:16, Adrian Buehlmann wrote:
>> Note that this *still* requires pythonXX.dll next to the hg.exe in the root
>> directory of HackableMercurial, or globally installed, for example, in
>> C:/Windows/system32. exewrapper makes no attempt whatsoever to locate
>> pythonXX.dll. It deliberately depends on standard Windows behavior for locating
>> that dll.
> 
> Playing with this demonstrates that this is what bloats
> HackableMercurial, as there needs to be a pythonXX.dll in both the root
> directory of HackableMercurial (so hg.exe can find it), and in the
> hg-python subdir (so the python.exe in hg-python can find it there).
> 
> Doing
> 
> http://mercurial.selenic.com/wiki/HackableMercurial?action=recall&rev=44#Build_hg-winhack
> 
> doesn't exhibit that duplication of the pythonXX.dll, as both hg.exe and
> python.exe can share it in the root directory of HackableMercurial.
> 
> Obviously, there is no duplication of pythonXX.dll, if it is installed
> globally (but that's not the domain of HackableMercurial).

FYI, the hgexe target cannot build with (my?) python 2.6 because build_ext.get_full_path() does not exist. I hacked it by replacing it with "os.path.dirname(os.path.abspath(__file__))" and it built but the resulting hg.exe would systematically fail trying to load some DLL, despite having a all the things you mentioned in the wiki copied in hg repository root.

At that point I gave up with 2.6 and managed to have a working setup with 2.7, including svn bindings which was unexpected.

I have no idea how important is all this stuff, my current targets are still the buildbot and windows tests.

--
Patrick Mézard