[Numpy-discussion] Merging new (optional) build system in the trunk ?

[David Cournapeau]

Hi,

    I would appreciate to get some comment on whether there is any 
chance to get my numpy.scons branch merge into the trunk at some near 
future. I feel to have reached the point where the only big thing 
missing is more testing. I tried to test it on many platforms, but there 
is a limit to what I can test just by myself. The branch has been 
conceived such as by default, the current numpy.distutils is used to 
build, and the scons-based build is used only by explicit request 
(another setup.py), so this does not force any use now: except the work 
related to numpyconfig (which can be tested separately, since it was 
done in a different branch, and is only a few lines of code), everything 
else is exactly the same than before.

Thanks,

David

P.S: Just as a reminder, here are some of the already implemented goals 
currently:
    - all the facilities of scons are available to build extensions 
(parallel builds, automatic dependency, easy extension through of new 
builders and configuration checks, etc...)
    - ability to build shared libraries and Ctypes-based extension in a 
cross platform way.
    - optimization flags logic cleanly separated from the other flags: 
you can now easily replace, add, remove optimization flags without 
having to handle platform specific flags such as -fPIC, etc...
    - facility replacing system_info which is easier to use (one 
function call to support most common cases)
    - performance library checks are stronger, for more reliable build 
results. MKL, Sunperf, ATLAS, vecLib and Accelerate are already 
supported; new libraries can generally be added in a few lines, as they 
all use the same infrastructure.
    - the current (successfully) tested platforms are : Mac OS X Intel 
(gfortran + gcc), Linux (g77 + gcc, gfortran + gcc, intel compilers), MS 
Windows (mingw, VS 2003 + g77, VS 2005 + g77), Solaris (with sun compilers).
    - Generally, I tried to follow the autoconf philosophy (do not check 
for version, check for facilities). The fortran runtime, for example, is 
found automatically, as is the fortran name mangling.
    - easier maintenance: no more distutils monkey patching because 
upstream distutils does not have a clean API, the current codebase is a 
bit below 3000 lines of code, not counting scons (as a comparison, 
system_info.py is almost 2000 lines by itself), most of the code is 
totally cross platform, and platform specific are encapsulated; there 
are a few hacks, but they are implementation-only hacks.

So concretely, I believe that most of the things stated in 
http://projects.scipy.org/scipy/numpy/wiki/DistutilsRevamp are available 
*now*. More concrete info here: 
http://projects.scipy.org/scipy/numpy/wiki/NumpyScons