[SciPy-dev] problems with numpy.setuptools("single_version_externally_managed")
Pearu Peterson
pearu at cens.ioc.ee
Wed Sep 26 02:44:46 EDT 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.
Pearu
More information about the SciPy-Dev
mailing list