Re: [Numpy-discussion] arrayobject.h (and friends) install location

[<kon...@la...>]

On Jan 17, 2006, at 1:18, Sasha wrote:

>> Also note that not all potential numpy users are able/willing/..  
>> to use
>> --prefix option. Why we should scare them away when we can provide
>> defaults that work for all situations, though the defaults are not
>> standard and require some tolerance from developers to follow  
>> numpy docs.
>
> Personally, I can tolerate any location less that 10 levels deep under
> install prefix
> and current location is only 8 :-). However, if there is a valid
> reason to change the location of include files, this functionality
> should be implemented as a (possibly default) option to distutils, not
> by treating includes as "data_files" rather than "headers".

I tend to agree, and I am a bit less tolerant about playing with  
header file location. The argument "just follow the NumPy docs, it's  
not difficult" ignores that NumPy, like many other Python library, is  
a software component that many people install without reading any  
documentation, just because some other component requires it. If  
NumPy header files end up in a non-standard place, the authors of all  
Python packages that depend on NumPy, no matter by how many levels of  
indirection, have to add obscure code to their installation scrips.  
If every popular Python library did the same, we'd soon have a big mess.

Moreover, it is possible that other libraries implement the same API  
as NumPy, but use different header conventions (in fact, Numeric and  
Numarray are candidates). Then every author of a package that  
indirectly depends on this API must not only add NumPy-specific code  
to his setup.py, but also check which of the multiple implementations  
is actually installed.

Standard locations, be it for Python code or for header files, have  
been created to avoid this kind of mess. The standard for Python is  
defined by distutils, and at the moment it's putting header files  
into $prefix/include/pythonX.Y. If that turns out to be a bad  
decision on some platform, then distutils should be modified. If  
individual packages start trying to outsmart distutils, we lose the  
advantages of a standard installation system.

Konrad.