Re: pkg-config files for libpq and ecpg

On Wed, 2013-03-27 at 17:06 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > On 3/24/13 1:55 PM, Tom Lane wrote:
> >> I experimented a bit with this version of the patch.  The hunk that
> >> removes -I$(libpq_srcdir) and $(libpq) from the ecpg/compatlib build
> >> breaks the build for me, so I took it out.
>
> > What was the error message?  Probably not important, but curious.
>
> ecpg's #include of libpq-fe.h failed.  I speculate that you didn't
> notice because you tested on a machine where libpq-fe.h exists in
> /usr/include.

Right, we need to keep libpq in CPPFLAGS, but we can remove it from
SHLIB_LINK.

> >> At least for the libraries we are currently proposing to pkgconfig-ify,
> >> it seems to me that we only want a -I for where we are installing our
> >> own headers; there is no need for anything else.  That is,
> >> echo 'Cflags: -I$(includedir)'
> >> seems like plenty.  We aren't exposing any other packages' headers
> >> in the public header files for these libraries, so there's no need
> >> to tell client packages about them.
>
> > libpq exposes at least openssl and gssapi, so we need those at least.
>
> No, it does not.  A client might choose to #include those of its own
> accord, but then it's the client's problem.  Our exported headers do
> not #include anything more exotic than <stdio.h>, and it's not the
> business of the pkg-config switches to provide for anything beyond
> allowing inclusions of our headers to succeed.

I was actually thinking of PQgetssl(), which is documented to require
OpenSSL, but that was actually changed a long time ago and the
documentation not updated.

So actually you are right, we don't need to provided any extra -I flags
(if we ignore libpq-int.h).  We do need that whole logic for
Libs.private however.

So here is my updated patch, with the ecpg business changed as explained
above, and the extra magic removed from the Cflags lines.