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