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-27 21:06:15
Message-ID: 4741.1364418375@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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.

>> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2013-03-27 21:20:56 Re: [COMMITTERS] pgsql: Allow external recovery_config_directory
Previous Message Heikki Linnakangas 2013-03-27 21:05:26 Re: [COMMITTERS] pgsql: Allow external recovery_config_directory