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.
> 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?
We could, but only in a hardcoded way. As it is, it's part of the
general set of flags that we use to build. libxml isn't special in this
regard. It only shows up because you have it in a nondefault path. If
you had openssl somewhere funny, it would show up as well.
> 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.
So in general, it won't work so easily to trim this list intelligently.That's something that could perhaps be tuned in
thefuture, but I'd
rather offer a few flags too many than not enough.
One way to look at this for now is: It's not worse than what pg_config does.
> 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.
I think nobody reads that, so it would be a waste of time to maintain
it. The URL is more important. I'd be more interested if some Windows
thing had already put in the need for a package description (see
PGFILEDESC). I'm not strictly against it, though.
> 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).
Considering how much other clutter we install without any options, I
think it's fine as is.
