[Numpy-discussion] For review: first milestone of scons support in numpy

David Cournapeau david@ar.media.kyoto-u.ac...
Wed Oct 10 22:55:46 CDT 2007


    (if you are not interested in numpy developement, you can stop now :) ).
    Following the discussion a few days ago on using scons to build 
extensions in numpy, I have reached a somewhat usable milestone, in the 
numpy.scons branch of numpy, and would like to hear some comments, 
remarks, critics, etc...:

Where to get/see:

svn repository : http://svn.scipy.org/svn/numpy/branches/numpy.scons
looking at the code: 


To see how it feels from the package developer point of view, I have put 
three really simple examples:
    - Building a python extension: 
    - Building a ctypes-based package: 
    - An example on how to check for libraries and symbols in them: 

For the numpy user, this should be totally transparent (no difference 
when building/installing).


This first milestone implements the following:
    - adding a scons command to numpy.distutils
    - adding an add_sconscript function to numpy.distutils setup, for 
packages willing to use scons
    - two builders: one for ctypes extension, and one for python extension
    - a basic implementation to check for libraries (the paths can be 
overwritten exactly like with distutils, using site.cfg; I have not yet 
implemented overwriting with environment variables).

I have been testing this on the following platforms:
    - linux with gcc
    - linux with icc
    - linux with suncc
    - windows with MS toolikit 2003
    - solaris studio express with suncc
    - mac os X (tiger, x86)

And now ?

As discussed previously, I think numpy would benefit from exclusively 
using scons to build compiled extensions. I have started working on 
fortran support for scons (separate project, since this may be useful to 
all scons users, not just numpy):


and I can already do some non trivial things, not possible with 
numpy.distutils (automatically figuring out fortran mangling, flags for 
linking with C, blas/lapack flags). As expected, this is much more 
robust than distutils approach of hardcoding everything: although I used 
g77 for development, it worked without any change with ifort, gfortran 
and sun fortran compiler (on linux). There are still some issues for 
sure, but I don't see big problems. I don't want to do the work for 
nothing, though, so I would like to know the feeling of numpy developers 
first on this direction, in particular which platforms should work 
before merging consideration, etc...



More information about the Numpy-discussion mailing list