[SciPy-dev] problems with numpy.setuptools("single_version_externally_managed")

Pearu Peterson pearu@cens.ioc...
Wed Sep 26 01:44:46 CDT 2007

David Cournapeau wrote:
> Pearu Peterson wrote:
>> O
>> I think distutils.*compiler modules are not designed to be
>> imported unless specifically requested via --compiler flag.
>> Though only importing distutils.msvccompiler has side effect.
> My impression is that distutils.msvccompiler is quite different from all 
> the other ones, right ? It does not have the same attributes, etc... 
> This fact is explicitely mentioned in distutils (msvccompiler.py):
> # Just set this so CCompiler's constructor doesn't barf.  We currently
> # don't use the 'set_executables()' bureaucracy provided by CCompiler,
> # as it really isn't necessary for this sort of single-compiler class.
> # Would be nice to have a consistent interface with UnixCCompiler,
> # though, so it's worth thinking about.
>> A seemingly easy fix would be to use the fix by checking os.name
>> and sys.platform but if one is using mingw32 compiler under windows,
>> the given warnings would be still wrong.
> Would it be possible to implement our own msvccompiler instead ?

Actually, there exist a simple and proper fix (as usual;):

numpy ccompiler.py should check if distutils.msvccompiler is
imported (via sys.modules). If it is, then set

   distutils.msvccompiler.gen_lib_options = <our gen_lib_options>

And if it is not, then do nothing. Note that when
distutils.msvccompiler is imported then it will pick
up the correct gen_lib_options from distutils.ccompiler
which has been already enhanced by numpy.distutils.


More information about the Scipy-dev mailing list