Re: Include files for SPI are not installed

Lamar Owen <lamar.owen@wgcr.org> writes:
> Tom Lane wrote:
>> What would make more sense is for the standard install to install only
>> those headers needed for *client side* programming, and then to have
>> an optional install target that installs the whole darn src/include
>> tree.

> I can go for that.

>> (Or in RPM terms, a client-devel RPM and a separate server-devel
>> RPM that adds the rest of src/include.)  Anything in between is
>> guaranteed to be the wrong set of files.

> Ok, RPM users who do SPI work, sound off.  Which would you like?  I'll
> admit to liking the idea Tom has put forward, but I want more feedback. 
> I would have a 'postgresql-devel' and a 'postgresql-devel-spi' -- to
> throw out a tentative name.  I am loath to split the existing -devel
> subpackage into two packages with different names, throwing out the
> original, but I can do that as well, if that is the consensus.

client-devel and server-devel are the right division IMHO.  SPI is a
subset of server-side development, but not all server-side code needs
SPI.  Consider user-written functions and datatypes.  These guys do not
need SPI (usually), but they do need access to header files that aren't
installed now.

> The contents of -devel would be the headers installed by 'make install'
> -- although I question why spi.h and some friends are installed in the
> first place, given the 'client-side' focus (but this _is_ what Tom just
> said -- I'm just being a little more specific).

My thought was that we'd remove spi.h from the minimal install, along
with anything else that's not useful for client-side programming.  Thus
the standard install footprint would get smaller.  I haven't looked to
see exactly what the list of client-side headers should be, but if
people like this idea I will do the legwork to make the list.
        regards, tom lane