[PATCH STABLE] exewrapper: adapt for legazy HackableMercurial

Patrick Mézard patrick at mezard.eu
Fri Aug 3 09:26:49 CDT 2012


Le 03/08/12 16:19, Adrian Buehlmann a écrit :
> On 2012-08-03 15:50, Patrick Mézard wrote:
>> 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.
> 
> Mads is against it anyway and Matt wants a drop-in replacement for
> exemaker, so I rest my case. Perhaps this exewrapper thing can now be
> removed from the tree. It doesn't look like we will get anywhere, given
> all the requirements.
> 
> Back to square one with having the bugs of exemaker.
> 
> It would probably have been interesting to invest in having the suite
> run on x64 finally, which is the norm in the userbase. That will however
> not work with the mingw32 gcc setup we currently have documented in the
> wiki.

Mads managed to build exewrapper with python 2.6.6, and the setup on the buildbot has a more recent version of distutils, so I would blame my oldish python 2.6.1 about what I described above.

--
Patrick Mézard



More information about the Mercurial-devel mailing list