[Numpy-discussion] For review: first milestone of scons support in numpy
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)
> 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