[tahoe-dev] [pycryptopp] #37: Win64 and MSVC9 compilation fixes
pycryptopp
trac at allmydata.org
Mon Jul 5 22:10:27 PDT 2010
#37: Win64 and MSVC9 compilation fixes
------------------------+---------------------------------------------------
Reporter: sneves | Owner: sneves
Type: defect | Status: new
Priority: major | Version: 0.5.17
Resolution: | Keywords:
Launchpad Bug: |
------------------------+---------------------------------------------------
Comment (by zooko):
sneves:
As I think I mentioned to you on IRC, there is an idiom that is used in
some setup.py files which is to attempt a build and then if it fails to
fall back to a method of building which is more likely to work even if it
produces less efficient results. This idiom is normally used for
attempting to compile a C extension module and then falling back to a
pure-Python implementation if the compilation fails, e.g.:
http://code.google.com/p/simplejson/source/browse/trunk/setup.py?spec=svn231&r=230#sl_svn230_63
However, I guess the same approach would work to attempt to build
{{{.asm}}} files and then fall back to excluding them if the attempt to
compile fails. What do you think? It smells a bit too clever/magical to
me, but on the other hand I do prefer testing whether we can ''do'' the
thing we want to do over testing whether we have a certain version of a
certain tool which can do that thing (i.e. whether we have a sufficiently
new version of MSVC).
My discomfort about the magicalness of it could be eased if we inspected
the exception that resulted from trying to build the {{{.asm}}} files and
then proceeded to try to build without the {{{.asm}}} files only if the
exception indicated that it was the .asm files that were the problem for
the compiler.
What do you think?
--
Ticket URL: <http://allmydata.org/trac/pycryptopp/ticket/37#comment:8>
pycryptopp <http://allmydata.org/trac/pycryptopp>
Python bindings for the Crypto++ library
More information about the tahoe-dev
mailing list