[Numpy-discussion] scipy.scons branch: building numpy and scipy with scons

[David Cournapeau]

On Dec 5, 2007 1:14 PM, Robert Kern <robert.kern at gmail.com> wrote:
> David Cournapeau wrote:
>
> > So to go back to your problem: if I understand correctly, what is needed
> > is to update the scons tools. Since those are kept at one place, I think
> > it would be safe to update them independently. But I don't understand
> > exactly how this could be installed in the source tree without
> > reinstalling numpy ? I think this is better than completely overriding
> > the compilation flags, personally. But if you really want this
> > possibility, I can add it, too, without too much trouble.
>
> I don't think you could install it into an already installed numpy package. My
> suggestion is to keep the implementations of the tools inside the numpy package
> as they are now *except* that we look for another package first before going
> inside numpy.distutils.scons.tools . I called it "numpy_fcompilers" though I now
> suspect "numpy_scons_tools" might be more appropriate. If the package
> numpy_scons_tools doesn't exist, the implementations inside
> numpy.distutils.scons.tools are used. A variation on this would be to provide an
> --option to the scons command to provide a "package path" to look for tools. E.g.
>
>   python setup.py scons
> --tool-path=my_local_fcompilers,site_fcompilers,numpy.distutils.scons.tools
>
Ok, I was confused by numpy_fcompilers, I thought you were talking
about the numpy.distutils.fcompiler module.

A priori, I don't think it would cause any trouble to add this option.
Internally, I already use a list of directories to look for paths, so
this should be a matter of pre-pending the new directory to this list.

> This, too, is a workaround for the less-than-desirable situation of having
> numpy's sizable build infrastructure bundled with the numpy package itself. If
> this stuff were an entirely separate package focused on providing this
> scons-based build infrastructure, then we wouldn't have a problem. We could just
> update it on its own release schedule. People would probably be more willing to
> use the development versions of it, too, instead of having to also buy into the
> development version of their array package as well.

The only problem I see is that this increases the chance of losing
synchronization. I don't know if this is significant. IMHO, the only
real solution would be to fix distutils (how many people want a shared
library builder in python community, for example ?), but well, it is
not gonna happen in a foreseeable future, unfortunately

cheers,

David