classification
Title: build out-of-line asm on Windows
Type: enhancement Stage: resolved
Components: Distutils2 Versions:
process
Status: closed Resolution: duplicate
Dependencies: Superseder: msvc9compiler.py: add .asm extension
View: 7546
Assigned To: tarek Nosy List: brian.curtin, eric.araujo, josip, skrah, sneves, tarek, zooko
Priority: normal Keywords: patch

Created on 2010-05-02 05:45 by zooko, last changed 2010-09-04 08:03 by skrah. This issue is now closed.

Files
File name Uploaded Description Edit
patch.diff zooko, 2010-05-02 05:45 patch to msvc9compiler.py to build assembly files
Messages (6)
msg104770 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2010-05-02 05:45
I maintain a Python package which comes with assembly optimizations -- http://tahoe-lafs.org/trac/pycryptopp . Someone was porting this package to Win64 today and discovered that distutils couldn't build it because the Microsoft compiler on Win64 doesn't allow in-line assembly and distutils doesn't know how to build out-of-line assembly (see also http://stackoverflow.com/questions/1664812/can-pythons-distutils-compile-s-assembly which says that there isn't a known way to do this).

So the fellow who is porting pycryptopp to Win64 for me, Samuel Neves, found this hack in someone else's setup.py file: http://bitbucket.org/ambroff/greenlet/src/3ad4830aa109/setup.py

We're probably going to adapt that hack to the pycryptopp setup.py file in order to work around this problem.

But then another fellow named Josip Djolonga who is a GSoC student working on Distutils2 suggested that we could patch the compiler class to use assembly files and pass them to cl.exe. Samuel worked up a patch that does that and then he was able to build pycryptopp on Win64. Here is his patch attached as a file.

Note that we will still need to do some work-around in the pycryptopp setup.py file in order to make pycryptopp buildable on Win64 with older versions of Python that do not have this fix. Any suggestions on the best way to do that would be welcome.

Oops, I see that Samuel gave me the patch in traditional diff form instead of unified diff form. I hope you can accept it anyway since he has gone to bed.
msg104790 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-05-02 16:22
I think this is a duplicate of issue 7546.
msg104792 - (view) Author: Tarek Ziadé (tarek) * (Python committer) Date: 2010-05-02 17:06
Distutils is frozen, switching to distutils2
msg115549 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-09-04 00:32
I have a hard time reading old-style diffs, so a unified diff would be a win. Alternatively, a Mercurial clone URI would do.

Can someone confirm this is a duplicate of #7546 as hinted by Stefan or explain the difference? I’m a bit too sleepy to do that and anyway know nearly nothing about assembler.
msg115557 - (view) Author: Samuel Neves (sneves) Date: 2010-09-04 04:06
I was unaware of patch #7456 when this was submitted. As far as I can tell, there is no difference and no reason to maintain both.
msg115560 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2010-09-04 08:03
The patches are very similar. This one always chooses ml64 on a 64 bit
platform, even when a user has executed `vcvarsall x86`.

The patch in #7546 attempts to honor the environment and has unit tests,
so I'm making #7546 the superseder.
History
Date User Action Args
2010-09-04 08:03:39skrahsetstatus: open -> closed
resolution: duplicate
messages: + msg115560

superseder: msvc9compiler.py: add .asm extension
stage: resolved
2010-09-04 04:06:28snevessetnosy: + sneves
messages: + msg115557
2010-09-04 00:32:35eric.araujosetnosy: + josip
messages: + msg115549
2010-09-04 00:09:40pitrousetnosy: + eric.araujo
2010-05-02 17:06:16tareksetnosy: zooko, tarek, brian.curtin, skrah
messages: + msg104792
components: + Distutils2, - Distutils
2010-05-02 16:22:40skrahsettype: behavior -> enhancement

messages: + msg104790
nosy: + skrah
2010-05-02 14:02:04brian.curtinsetnosy: + brian.curtin
2010-05-02 05:45:29zookocreate