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

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

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:


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.



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: 

More information about the Numpy-discussion mailing list