Re: pkg-config files for libpq and ecpg
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2013-03-27T21:06:15Z
Lists: pgsql-hackers
Peter Eisentraut <peter_e@gmx.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
Commits
-
Adjust Darwin build to use the default 'two level namespace' linking
- cd75f94dafd4 7.4.1 cited