Re: [HACKERS] SPI Headers -- RPM distribution

Tom Lane wrote:

> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > So, I'm going to put these headers under /usr/include/pgsql/backend.
>
> Some of these headers already are exported. The right thing is to
> export the rest in parallel, not throw in an extra level of directory.
> The path from /usr/include/pgsql should be the same as the path from
> .../src/include in the source tree.

Good point.

> The only real problem with doing that is with fmgr.h, which for reasons
> that I don't fathom isn't in src/include at all. Seems to me it would
> be a good idea to have fmgr.h (and I guess parse.h too) put into
> src/include, and then we could get rid of -I../backend from the switches
> used for backend compilations.

Also, I have noticed that some headers are #included with <>, while
others are included with "". Now, I understand that system headers
should be included with <>, but I'm seeing PostgreSQL headers wrapped
with <>. This makes the cpp -M variants a little confusing -- while
tracing down the header dependencies, I started using cpp -MM, which
only follows user headers and not system headers -- but it doesn't get
all of the headers.

And that fmgr.h thingy -- ewww. I'm sure there is a reason somewhere
that it is in backend, but it escapes me as to why.

> A good longer-term project would be to reduce the number of headers that
> we need to export. 80 include files to compile spi.h? Ugh.

After reading Jan's message about the list of dependencies for spi.c
containing more than the dependencies for a user SPI module, I was
prepared to see alot less headers -- and was quite disappointed to see
87 headers show up.

My goal is to provide the minimum required to build things for the
backend for those who want to do so, without requiring them to install a
source tarball and relearn where all of the files are located. Like I
said, if I have to provide a complete source tarball to do some things,
I will -- I just would rather not. If someone wants the source to
study, they can install the src.rpm and play to their hearts' content --
and they can then rebuild the whole package in a manner consistent with
the standard RPM installation with a single command, and not have to
relearn anything.

So, taking your suggestion, I'm going to add all these required headers
to the RPM package as part of the postgresql-devel RPM. Since RPM's
database handles the aspect of what files belong to what package, it is
redundant to place these SPI includes in a separate place -- and then
developers only need to properly set the location of the PostgreSQL
include tree once (/usr/include/pgsql).

I will try to fully document these changes -- and am building this RPM
as a beta RPM until such time as it is verified to work for those
developing SPI modules under the RPM installation.

Thanks Tom.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11