Tom Lane wrote:
> I agree with Karel on this --- it's difficult to visualize doing useful
> SPI work without a source tree at hand, and it also seems unlikely that
> SPI authors would get along for long with *only* those header files
> needed to pull in spi.h. So I think it's pretty pointless to add just
> those header files.
I'm waiting to see what Mike Mascari says about the issue, as he is
doing SPI work from an RPM install (no source) and was the gadfly (in
the best sense of the word) that got me putting the SPI headers in in
the first place.
Besides headers, what files are required? Makefile.global?
Makefile.shlib? ???
> 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.
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). The contents of
-devel-spi (or maybe just -spi) would be all the other headers (no
duplicates) (again, expounding upon what Tom said already).
Comments?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11