[PATCH STABLE] setup: fix build_hgexe for mingw32 compiler

[Adrian Buehlmann]

On 2012-07-30 15:09, Mads Kiilerich wrote:
> On 28/07/12 22:12, Adrian Buehlmann wrote:
>> On 2012-07-28 17:46, Patrick Mézard wrote:
>>> Le 25/07/12 16:50, Adrian Buehlmann a écrit :
>>>> # HG changeset patch
>>>> # User Adrian Buehlmann <adrian at cadifra.com>
>>>> # Date 1343227822 -7200
>>>> # Branch stable
>>>> # Node ID 450330d3276f34576b98fd2d940c257f4bdef73b
>>>> # Parent  ffc49100151b68c0bcd061b900d9993e9e1a0d7d
>>>> setup: fix build_hgexe for mingw32 compiler
>>>>
>>>> Fixes
>>>>
>>>>    python setup.py build_hgexe -i --compiler=mingw32
>>> This is not exactly related to this patch but to exewrapper, but I would like to mention we had to tweak the existing Windows buildbot setup to have it run with exewrapper. The errors were:
>>>
>>>    http://hgbuildbot.kublai.com/builders/Windows%202008%20R2%20hg%20tests%20(stable)/builds/94/steps/run-tests.py%20(python2.6)/logs/stdio
>>>
>>> and the fix was to explicitely set $PYTHONHOME to the python interpreter used to build and run the tests. I do not know why PYTHONHOME helped here as the referenced python interpreter was already the first in $PATH (there is at least another global one installed on the box), but it helped.
>>>
>>> Is it the symptom of possible problems with exewrapper or the test suite, I do not know.
>> I found the following works:
>>
>> Assuming an x64 Python 2.7 is used, which is installed in C:\Python27_x64.
>>
>> In the repo root of a local clone of Mercurial do:
>>
>>    $ C:\Python27_x64\python.exe setup.py build_ext -i
>>    $ C:\Python27_x64\python.exe setup.py build_hgexe -i
>>
>> This should build the hg.exe and the mercurial/*.pyd files using the MS
>> toolchain (alternatively, this should work with --compiler=mingw32 too).
>>
>> Now, copy the folder C:\Python27_x64\Lib into the repo root. Or zip its
>> contents to python27.zip (make sure there is no "Lib" top directory
>> inside the zip) and put that zip file into the repo root.
>>
>> Then copy the contents of C:\Python27_x64\DLLs into the repo root
>> (specifically the files _ctypes.pyd, _socket.pyd, etc.).
>>
>> Copy python27.dll (I found it in C:\Windows\System32 here) into the repo
>> root.
>>
>> If you do that, setting $PYTHONHOME should no longer be needed. hg.exe
>> will find the things it needs right next to it.
> 
> I object to this (and 
> http://mercurial.selenic.com/wiki/HackableMercurial?action=diff&rev1=42&rev2=43 
> and 
> http://mercurial.selenic.com/wiki/HackableMercurial?action=diff&rev1=43&rev2=44 
> ). It might work as a very temporary workaround but is too ugly to be 
> considered a solution.

It works perfectly well.

What is ugly about it? Can you be more specific?

> exemaker handled this situation better (even though it perhaps was a bit 
> buggy for some use cases).

Indeed it was very broken. It couldn't even find a perfectly well
installed python27.dll without hacking the absolute path into the
hashbang of the respective python script.

The hg.exe we now build is built in the very same way as python.exe is
built too (using the pythonXX.lib provided by the CPython installer).

> If exewrapper isn't feature complete yet then
> we shouldn't make a regression by changing to it.

Can you please explain what regression you are talking about?

> I suggest:
> 1. exewrapper hg.exe should look for hgexe.py before hg.py
> 2. exewrapper should look for a #! in the .py and use that to find 
> PYTHONHOME - either with an absolute path or relative to the .py (or 
> $PATH as fall back)
> 3. setup.py should have some support for creating hgexe.py with the 
> right #! for the 'make local' and 'make install' use cases.
> 
> 'Hackable' could then ship with a hgexe.py with a relative path to a 
> contained python, and the pair of hgexe.py with an absolute #! path and 
> hg.exe could be copied anywhere (for example a shared 'bin' folder or 
> 'system32' so the user didn't have to explicitly put Mercurial in $PATH 
> to use it).
> 
> (It is also possible that 'hackable' could benefit from shipping with 
> something like a cx_frozen python subset. That could probably make the 
> size of hackable a fraction of what it is now.)