[Numpy-discussion] Merging new (optional) build system in the trunk ?
david at ar.media.kyoto-u.ac.jp
Mon Nov 12 06:39:20 EST 2007
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.
P.S: Just as a reminder, here are some of the already implemented goals
- 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:
More information about the NumPy-Discussion