Peter Eisentraut <peter_e@gmx.net> writes:
> On 1/15/13 6:53 PM, Tom Lane wrote:
>> 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.
> Updated patch addressing this concern. Also added comments and
> documentation.
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. With that gone, I noted
that I got this when building in a Fedora RPM environment (ie, the
same way I would package PG for Fedora):
Name: libpq
Description: PostgreSQL libpq library
Url: http://www.postgresql.org/
Version: 9.3devel
Requires:
Requires.private:
Cflags: -I/usr/include -I/usr/include/libxml2
Libs: -L/usr/lib64 -lpq
Libs.private: -lssl -lcrypto -lkrb5 -lcom_err -lgssapi_krb5 -lcrypt -lldap_r -lpthread
The -I for libxml2 seems pretty darn bogus; can't we avoid that?
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.
Also, I'm underwhelmed by the usefulness of the automatically-generated
description lines. It might be better to ask the individual makefiles
to set a PKG_CONFIG_DESCRIPTION macro.
Lastly, I wonder whether it's worth adding a configure option or some
such to control whether pkgconfig files are built, or at least whether
they're installed. In a lot of environments this would just be adding
useless clutter to the $(libdir).
Otherwise it seems about ready from here.
regards, tom lane