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

[David Cournapeau]

Pearu Peterson wrote:
>
> I think this is good.
> Does scons require python-dev? If not then this will solve one of the
> frequent issues that new users may experience: not installed distutils.
Isn't distutils included in python library ? 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).

But please remember that this work is not intended at replacing 
distutils entirely, only the build_ext/build_lib commands. All the build 
process would still be driven by distutils (in particular, supporting 
distutils is a requirement to support setuptools and eggs).
> I think numpy is quite stable now that it's safe to develop in a branch
> (if trunk is very actively developed then merging branches
> can be a nightmare). However, IMHO using a branch makes other
> developers to stay aside from branch development and in time it is
> more and more difficult to merge.
I don't have strong experience in subversion, so I was afraid of that. 
Do I understand correctly that you suggest opening a new dev branch, and 
then do all subsequent dev (including non distutils/scons related ones) 
there ?

>
> The third approach would be to cache those checks that are called
> frequently to, say, $HOME/.numpy/scons.
>
> numpy.distutils setup.py script gathers the information from
> subpackage setup.py scripts recursively and then passes all the
> information to one setup function call.
> I think setupscons.py should do the same. If scons does not support
> recursive reading of scons scripts then the corresponding feature
> should be implemented, I guess it would not be difficult.
Scons supports recursive calls. To be more clear about the possibilities 
of scons wrt to this, let's take a simplified example:

root/Sconstruct
root/numpy/Sconscript
root/numpy/core/Sconscript
root/numpy/linalg/Sconscript

If you are in root and call scons (> is a shell prompt):

root > scons

Then it will call recursively all the sconscript (as long as you request 
it in the sconscript files). The other supported method is

root/numpy/linalg > scons -u

this will look every parent directory to find the "root" Sconstruct. So 
as long as we configure everything (by everything, I mean checking for 
libraries and compilers) in the root Sconscript, this should work. To 
sum it up: the build process would be more like projects using 
autotools; a configure step, and a build step (this would be internal; 
there is no need to expose this mechanism to the user).
>
> I meant that Configuration class could have a method, say 
> toscons(<filename>),  that will generate SConstruct script
> from the information that Configuration instance holds. I thought that 
> this would just ease creating SConstruct scripts from
> existing setup.py files.
I don't think it would worth the effort for numpy (the main work really 
is to implement and test all the checkers: blas/lapack, fortran). Now, 
as a general migration tool, this may be useful. But since we would 
still use distutils, it would only be useful if it is easy to develop 
such as tool.

cheers,

David

P.S: would it be easy for you to make a list of requirements for fortran 
? By requirement, I mean things like name mangling and so on ? Something 
like the autoconf macros: 
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_66.html