[Numpy-discussion] [ANN] numscons 0.3.0 release

[David Cournapeau]

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.
>>
>> https://launchpad.net/numpy.scons.support/0.3/0.3.0
>>
>> To use it, you need to get the build_with_scons numpy branch: see 
>> http://projects.scipy.org/scipy/numpy/wiki/NumpyScons for more
>> details.
>
> 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 
started this.

There are also other points which are less obvious, or for which I am 
too biased:
 - 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.

cheers,

David