Re: pkg-config files for libpq and ecpg

Re: pkg-config files for libpq and ecpg

Re: pkg-config files for libpq and ecpg

On Wed, 2013-03-27 at 17:06 -0400, Tom Lane wrote:
> Peter Eisentraut  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 , 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.

Re: pkg-config files for libpq and ecpg

Re: pkg-config files for libpq and ecpg

Re: pkg-config files for libpq and ecpg

Re: pkg-config files for libpq and ecpg

pkg-config files for libpq and ecpg

I'll take another stab at providing pkg-config files for the client-side
libraries.

The main reason this time around is that this works a lot better (or at
all) for multi-arch library installations.

Another is that pkg-config has become a lot smarter and flexible over
the years, and it's probably a better choice for users who are already
used to its interface.  There is a lot of confusion, for example, about
what pg_config --libs really means.  We often evade that by saying,
well, those are the libraries we linked with, but there is a lack of
clarity in that context about what libraries a user should link with.

The way it's implemented, it doesn't require manual maintenance, so it
should not be much of a bother.

A side issue that arose: libecpg_compat is linked with libpq, but
doesn't seem to use it.  This was added many years ago in
cd75f94dafd43358305811b7576ad75d889097e3, but it doesn't appear to be
required anymore.  Needs some checking.

Re: pkg-config files for libpq and ecpg

On 1/15/13 6:53 PM, Tom Lane wrote:
> Peter Eisentraut  writes:
>> I'll take another stab at providing pkg-config files for the client-side
>> libraries.
> 
> This bit:
> 
>> +	echo 'Libs.private: $(filter-out $(PKG_CONFIG_REQUIRES_PRIVATE:lib%=-l%),$(filter-out -L..%, $(SHLIB_LINK)))' >>$@
> 
> appears to assume that SHLIB_LINK contains nothing except -L and -l
> switches.  I don't think I trust that a whole lot --- in fact, it
> looks guaranteed to fail on HPUX because of -print-libgcc-file-name.
> There might be other platform-specific bogosity on other platforms;
> PTHREAD_LIBS seems like a likely source for instance.

Updated patch addressing this concern.  Also added comments and
documentation.

Re: pkg-config files for libpq and ecpg

Re: pkg-config files for libpq and ecpg