[SciPy-dev] build system for scikit

[Dag Sverre Seljebotn]

Nathaniel Smith wrote:
> So I've had some reports of problems with the scikits.sparse build
> system; I'm sure the general thrust will be familiar to many people
> here:
>  -- Even on Linux, different distributions put the CHOLMOD headers in
> different places (argh wft people)
>  -- Apparently numpy headers are not always placed in the Python
> include path? This seems broken to me, but okay...
>  -- In principle, it might be nice to be able to build just some of
> the scikit, e.g. if the person has the right libraries installed for
> scikits.sparse.cholmod but not scikits.sparse.umfpack.

Most other libraries seem to "fix" this by statically linking all the .c 
files directly into the extension .so. That's the state we're currently 
in with Python building. (Please, plese don't do this.)

It seems to me that the best solution for now is to make things 
injectable from a configuration file, so that one has to explicitly set 
CHOLMOD header directory location in a configuration file.

This is no different I think from NumPy and SciPy, which will get their 
paths to MKL etc. (if used) from a configuration file.

(The Cython files should probably be changed to use include "cholmod.h" 
rather than "suitesparse/cholmod.h", and then rely on being passed -I 
flags).

That should give a baseline that's buildable with the Python tools with 
some manual configuration. Then other people would automate this as 
appropriate for their platform (e.g. to create a Linux package you'd 
hook it up with autotools as David suggested -- in my Sage package I am 
already autogenerating a setup.cfg for scikits.sparse with the 
Sage-specific NumPy include path in the package build process).

Creating something new which is "automatic" and tries to guess the 
location of CHOLMOD across different platforms is in my opinion a waste 
of time and makes things worse. What if you want to build your own 
SuiteSparse? Etc.etc. Explicit is better than implicit!


-- 
Dag Sverre