Re: pkg-config files for libpq and ecpg

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pkg-config files for libpq and ecpg
Date: 2013-03-24 17:55:21
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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
Version: 9.3devel
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

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2013-03-24 18:07:24 Re: Page replacement algorithm in buffer cache
Previous Message Atri Sharma 2013-03-24 17:03:58 Re: Page replacement algorithm in buffer cache