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