[SciPy-user] install location of the newcore header files

[Gerard Vermeulen]

On Tue, 11 Oct 2005 10:22:59 -0700
Robert Kern <rkern at ucsd.edu> wrote:

> Gerard Vermeulen wrote:
> > Sorry if this shows up in a strange place in the thread, but some replies did
> > not make it into my inbox.
> > 
> > Robert Kern wrote:
> > 
> >>>I finally discovered where the header files get installed when reading CAPI.txt;
> >>>on the scip-dev list it is argued that the Python include directory is not a
> >>>standard place for headers.
> >>
> >>No one is arguing that it's not standard. I'm arguing that it's a *bad*
> >>place because frequently people can't install to it.
> > 
> > To anybody who can't install some files in the "standard" locations, I advise
> > to do something like:
> > 
> > python setup.py install --root=~/MyPythonStuff
> > 
> > The directory layout of this installation under ~/MyPythonStuff is the
> > same as if it would be installed in the Python tree.
> > 
> > It is a minor adjustment for the dictates of distutils; and works for
> > any package which tries to install headers in the "standard" locations.
> 
> I know about that. You're missing my point, however, that it then
> requires one to modify the setup script of every *other* package that
> needs the scipy header files to compile to point to this alternate,
> nonstandard location.

Why?

(1) One can always add non-standard include directories:

python setup.py build_ext --help
..
--include-dirs (-I)  list of directories to search for header files
..
    and this is a worst case.  I am pretty sure this can be taken
    care of in a config file.

(2) If you recommend the 'install --root' method the location of the
    alternative Python include directory is implicitly known and is
    easy to figure out. I will use such a facility if SciPy offers it.
                       
> That interferes with automated building and
> installation. It's also incompatible with PythonEggs because they can't
> contain header files to be installed the old way.
>

I have refrained from commenting on PythonEggs, but I think it has a design
problem if it can't handle standard distutils packages (how does PythonEggs
handle C extension modules?).

> 
> It's a burden on the user rather than the developer. It's a cost that
> gets paid every time he has to install something that needs the scipy
> includes.

You mean a minority of users (< 5 % ?) and you should not think in terms of
SciPy only.  Isn't it better in the long run to educate those users so that
they can cope with any distutils package that exports a C-API?

> Putting the headers into the package means that it will work
> in every conceivable installation in exactly the same way everywhere
> without effort on the part of the user.

True; but the cost is that you are breaking a standard.

> That's worth making developers
> read the documentation (or the compile commands spat out by distutils)
> to find the headers.

I see myself recompiling SciPy (or any other package) when I want to find the
headers. IMO the problem can be solved with 10 lines in a README (see point 2
above) without putting a burden on developers.

Gerard