bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

pkg-config (was: installable gnulib library)


From: Ralf Wildenhues
Subject: pkg-config (was: installable gnulib library)
Date: Mon, 11 Oct 2010 19:42:12 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

Hello Gary,

* Gary V. Vaughan wrote on Mon, Oct 11, 2010 at 09:31:55AM CEST:
> On 9 Oct 2010, at 22:40, Bruce Korb wrote:
> >> I think I know why pkg-config makes autotools people wince...
> >> 
> >> <rant>
> >> I still regret not having noticed pkg-config before it became so pervasive 
> >> -
> >> it basically repeats all of the work libtool already did, and then ignores
> >> a few critically important parts, so that if you use any kind of directory
> > 
> > I submit that it isn't completely too late.  Add a LT_CREATE_PKG_CONFIG
> > configure macro that spits out a .pc file named after the AC_INIT-named
> > package.  How hard can that be?  (I am *not* volunteering....)
> > However, you are certainly right about that PKG_CONFIG_PATH thing.
> > /etc/sysconfig/pkgconfig would have been very useful.....
> 
> It is the .pc files that are the problem actually.

No.  The files themselves are fairly innocent actually.  It's that they
are used wrongly, and the pkg-config semantics aren't right.

> libtool already contains most of the information that pkg-config wants,

But libtool doesn't, and cannot, deal with per-package preprocess and
compile flags.  Trying to make it do so is bad design.

Even the inherited_linker_flags are, in hindsight, not well designed.
Sure, -pthread needs to be used for dependent packages, but it needs
to be used at compile time already, not just at link time.  And passing
it on precludes building a dependent package with a different compiler
that spells -pthread differently (both of these have happened to me, by
the way).  The right thing would have been a system- and
compiler-independent wrapper option that translates to the right opton.

> and
> it is much smarter about looking for deplips along the library search path
> without requiring the manual maintenance of *another* path for a tool that
> doesn't know it's way around the library search path.

Granted, but it has its warts as well.

> The right solution would be to make sure that the .la files include any
> additional details required to provide the output that pkg-config users are
> chasing, and to add a mode to the libtool script to extract and display it.

But the number of packages using .pc files is much larger than those
using libtool.  Unless you are going for vendor lock-in strategy, it's
not a decent idea to consider that .pc files are going away.

Cheers,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]