[Numpy-discussion] For review: first milestone of scons support in numpy

David Cournapeau david@ar.media.kyoto-u.ac...
Thu Oct 11 22:34:56 CDT 2007


Pearu Peterson wrote:
>
>> Anyway, scons does not 
>> require anything else than a python interpreter. Actually, an explicit 
>> requirement of scons is to support any python starting at version 1.5.2 
>> (this is another important point which I consider important for a 
>> replacement of numpy.distutils).
>
> Though, it is irrelevant as numpy/scipy packages require python
> versions starting at 2.3.
Sure, I just meant that we don't have to worry that scons may depend on 
2.4 or 2.5 features (I am not sure waf have such a requirement, for 
example).
>
> No, my original suggestion was that I don't mind if you would develop
> scons support in trunk as it does not affect the current state
> of numpy/scipy builds. Don't know if other developers would have
> objections in that.
Ah, ok. I am not sure I can guarantee it will never affect the build 
process. As this is a pretty fundamental change, I though about doing 
that in a 1.1 branch of numpy. But I do not have strong opinion on that, 
nor much experience in that area.
>
> My point was that
>
>    root/numpy/linalg > scons
>
> should work (without the -u option). 
Since scons is called by distutils, and never by the user, I don't see 
how this can be a problem ? distutils would have to figure out when to 
use -u, not the user.
> A subpackage may not require all
> the stuff that other subpackages require and therefore scons should
> not configure everything - it's a waste of time and efforts - especially
> if something is broken in upper packages but not in the subpackage.
>
Note that scons caches the configuration, so I don't think speed will be 
an issue here (except maybe if you keep changing the configuration 
before building). What I could do is for each subpackage, to declare the 
tests to use in each subpackage, but then, what to do if two packages 
have some common tests ? I cannot just remove double tests, because the 
order is significant (because of link options, for example).

The way I see it, either we keep the current behaviour (each package is 
totally independant, scons is called for each subpackage, and scons has 
no way to know about other subpackages; this has the disadvantage of 
being slower: this will be significant of many subpackages use costly 
checks like fortran mangling and so on), or we have a main sconscript 
with the configuration, which does not prevent building subpackages, but 
which requires a global configuration.

If none of those approach seems right to you, I will see if I can come 
up with something better, but this will certainly add some complexity 
(or I am just stupid to see an obvious solution :) ).
> To use f2py succesfully, a fortran compiler must support flags that make
> fortran symbol names lowercase and with exactly one underscore at the 
> end of a name. This is required when using numpy.distutils.
>
> f2py generated modules make use of the following CPP macros:
> -DPREPEND_FORTRAN -DNO_APPEND_FORTRAN -DUPPERCASE_FORTRAN -DUNDERSCORE_G77
> and therefore the above requirement would not be needed if
> scons could figure out how some particular compiler mangles
> the names of fortran symbols. This would be especially useful
> since some fortran compiler vendors change the compiler flags
> between compiler versions and one has to update numpy.distutils
> files accordingly.
>
Thank you for those information. Do I understand correctly (sorry for 
being slow, but I don't know anything about fortran) that what you need 
is macro like:
    - AC_F77_WRAPPERS (which defines C macros for converting C functions 
to fortran compiler mangling)
    - AC_F77_FUNC (which retrieves the name mangled by fortran linked 
from the 'canonical' name: this is already implemented, as it is 
necessary for checking blas/lapack)

And that's it ?

cheers,

David


More information about the Numpy-discussion mailing list