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
_______________________________________________
Numpy-discussion mailing list
[email protected]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
