Re: Include files for SPI are not installed

Lamar Owen <lamar(dot)owen(at)wgcr(dot)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