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 Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion