[Numpy-discussion] [ANN] numscons 0.3.0 release
Thu Jan 24 22:45:30 CST 2008
Stefan van der Walt wrote:
> Hi David
> On Thu, Jan 24, 2008 at 12:34:56AM +0900, David Cournapeau wrote:
>> I've just released the 0.3.0 release of numscons, an alternative
>> build system for numpy. The tarballs are available on launchpad.
>> To use it, you need to get the build_with_scons numpy branch: see
>> http://projects.scipy.org/scipy/numpy/wiki/NumpyScons for more
> Fantastic job, thank you for investing so much time in improving the
> build system. I noticed that you were trying to get scipy building --
> how is that progressing?
Not much, but there is not much left to do: I don't remember exactly,
but umfpack was still problematic; but except that, scipy should be able
to build with numscons once I change the imports (to cope with the split
between scons support and numpy.distutils).
Scipy is much easier to build than numpy, because except f2py/fortran
related problems, everything needed in scipy is needed by numpy. And the
really hard job was to understand distutils anyway :)
> Scons should make building on non-*nix
> platforms a lot easier.
Not so much, because scons does not know how to build python extensions
(I had to develop my own builder, which fortunately should end up in
scons at some point). Since I started this work, my perception on the
advantages have changed:
- real dependencies handling. I did not think it would be so
interesting, but while using it, I got used to not removing the build
directory when I change one configuration.
- ability to use different compiler options for different extensions.
- easy customization of compiler flags (interesting for debugging, or
find the best optimization flags).
- checks are logged in config.log files
- and of course, the ability to build shared library (c-types
extensions), static libraries, etc... which is one of the reason I
There are also other points which are less obvious, or for which I am
- the system is simpler: the codebase is 3 times smaller (2500 vs 8000
lines) and there is a clear distinction between configuration and code
(flags are not buried in the code anymore, they are defined in separate
.cfg files). Also, even if scons is 'unpythonic' for some aspects, the
codebase is so much better than distutils in the stdlib. Everytime I
touch stdlib distutils, I fear that it will break something in another
unrelated place, or that I did not call some functions in the right,
platform specific order; I don't have this problem with scons.
- the SConscripts also are simpler to read than setup.py I think
(specially for numpy.core and other modules with complicated
configurations). They are longer, but there is less magic, and the
intent is more obvious I think. This is really important, because I
think I spent more than 50 % of my time on understanding distutils for
this. I hope that nobody will have to do that anymore.
More information about the Numpy-discussion