[Numpy-discussion] For review: first milestone of scons support in numpy
Thu Oct 11 03:54:13 CDT 2007
Pearu Peterson wrote:
> Examples look good. It seems that you have lots of work ahead;) to add
> numpy.distutils features that are required to build numpy/scipy.
Thanks for reviewing this, especially since you are arguably the
most knowledgeable about this part of numpy :)
> Few comments:
> 1) Why SConstruct does not have extension? It looks like a python file
> and .py extension could be used.
It looks like but isn't. This is actually the part of scons I like the
least: scons uses python, but sconscripts files are not proper python
modules. Sconscripts files are used declaratively:
I think this is one of the biggest design mistake of scons. Waf, which
was briefly mentioned by David M. Cooke, and which is based on scons,
does not do this, though (I did not use waf because it is new, is
maintained only by one developer, and is more geared toward unix, that
is MS tools are not supported).
> 2) It seems that scons does not interfare with numpy.distutils much.
> If this is true and numpy/scipy builds will not break when scons is
> not installed then I think you could continue the scons support
> development in trunk.
It won't break if scons is not installed because scons sources are
copied into the branch. Scons developers explicitely support this:
(AFAIK, it does not pose any problem license-wise, since scons is new
BSD license; it adds ~350 kb of compressed source code to numpy).
> 3) In future, if we are going to replace using distutils with scons
> then all numpy/scipy need SConstruct scripts. I think one can implement
> these scripts already now and use, say, setupscons.py, containing only
> def configuration(parent_package='',top_path=None):
> from numpy.distutils.misc_util import Configuration
> config = Configuration('packagename',parent_package,top_path)
> return config
> if __name__ == '__main__':
> from numpy.distutils.core import setup
> to build the packages. Or can scons already be used with only
> SConstruct script and setupscons.py are not needed? Implementing these
> scripts now would give a good idea what features are required in using
> scons to build numpy/scipy packages.
> Also, it will prove that scons can replace numpy.distutils in future,
That's what I had in mind (setupscons.py). I don't see any big reasons
for not merging the current branch (since it is optional and should not
Now, concerning migrating all compiled extensions to scons, I would
prefer avoiding doing it in the trunk; but I heard horror stories about
subversion and merging, so maybe staying outside the trunk is too risky
? Also, when I said that I don't see big problems to replace distutils
for compiled extensions, I lied by over-simplification. If scons is used
for compiled extension, with the current design, distutils will call
scons for each package. Calling scons is expensive (importing many
modules, etc...: this easily takes around one second for each non
trivial Sconscript), and also, because each of them is independent, we
may check several times for the same thing (fortran compiler, etc...),
which would really add up to the build time.
I see two approaches here:
- do not care about it because numpy is unlikely to become really bigger
- considering that numpy is really one big package (contrary to
scipy which, at least in my understanding, is gearing toward less
inter-package dependencies ?), we should only have one big sconscript
for configuration (checking blas/lapack, compilers, etc...), and use
scons recursively. In this case, it should not be much slower than the
> 4) though, we cannot remove numpy.distutils for backward compatibility
> with software using numpy.distutils. However, it should be possible
> to enhance Configuration class to generate the corresponding SConstruct
> scripts. It will save some work when converting configuration()
> functions to SConstruct scripts.
Could you elaborate on this point ? I am not sure what you mean by
generating Configuration class ?
More information about the Numpy-discussion