[SciPy-dev] build system for scikit
Dag Sverre Seljebotn
Wed Jan 13 03:47:50 CST 2010
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
> -- 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
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!
More information about the SciPy-Dev