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

[Pearu Peterson]

David Cournapeau wrote:
> Pearu Peterson wrote:

>> 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.

Yes. I was considering the situations where distutils in not used at 
all. May be it will be relevant in future..

> 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 :) ).

I would prefer the former solution where each package is totally
independent. Let's first see what is the acctual performance and then
maybe consider more complex solutions if the build is really slow.

>> 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)

These macros are fine. May be we need more such macros for F90 compilers
but we can discuss about these when the corresponding issues will emerge.

However, if you could also provide the macros
that f2py uses then everything would work with no change in f2py part.
f2py uses the following defintion of F_FUNC, for example:

#if defined(PREPEND_FORTRAN)
#if defined(NO_APPEND_FORTRAN)
#if defined(UPPERCASE_FORTRAN)
#define F_FUNC(f,F) _##F
#else
#define F_FUNC(f,F) _##f
#endif
#else
#if defined(UPPERCASE_FORTRAN)
#define F_FUNC(f,F) _##F##_
#else
#define F_FUNC(f,F) _##f##_
#endif
#endif
#else
#if defined(NO_APPEND_FORTRAN)
#if defined(UPPERCASE_FORTRAN)
#define F_FUNC(f,F) F
#else
#define F_FUNC(f,F) f
#endif
#else
#if defined(UPPERCASE_FORTRAN)
#define F_FUNC(f,F) F##_
#else
#define F_FUNC(f,F) f##_
#endif
#endif
#endif
#if defined(UNDERSCORE_G77)
#define F_FUNC_US(f,F) F_FUNC(f##_,F##_)
#else
#define F_FUNC_US(f,F) F_FUNC(f,F)
#endif

> And that's it ?

I don't recall that there would be more issues that would prevent
using f2py (we'll see if I am going to be wrong here;).

system_info has a feature of providing architecture specific
and optimization flags for fortran compilers. Could scons
support such a feature?

Pearu