Re: Libtool and Pkg-Config

[Havoc Pennington]

Alexandre Oliva <address@hidden> writes:
> On Apr 21, 2001, Havoc Pennington <address@hidden> wrote:
> 
> > This would also help handle -R on Solaris and stuff like that.
> 
> If it could handle a list of packages at once, yes, it would probably
> help on other systems such as DU too.  But the main problem with DU is
> that -rpath flags override previous -rpath flags, instead of adding to
> them.  You must use a single -rpath flag with a colon-separated list
> of directories.  And then, there are other systems that require an
> environment variable to be set, because there's no -R/-rpath
> equivalent.  If only *-config scripts had been designed with these
> problems in mind... :-(
> 

The basic deal is that you need a single tool with fairly high-level
and detailed knowledge of all the packages on the link line, which can
then construct an appropriate link command. I don't think *-config
really could have been designed with this stuff in mind; it's
inherently a big-picture problem involving multiple packages, so
requires a thing like libtool or pkg-config, not a thing like
gtk-config.

pkg-config/*-config really isn't that powerful; it handles:

 - the case where libraries are in odd prefixes (-L flags)
 - the case where the app author doesn't know in advance the -l flags
   for each platform or set of configure options used for a library
 - the case where we have include files somewhere funny, such as 
   /usr/include/gtk-2.0
 - the case where it's just annoying to type some huge list of 
   flags
 - it's easy to write a cheesy one-off Makefile or compile 
   line using something like gtk-config

Both *-config and pkg-config amount to "give me the link flags" and
"give me the compile flags," i.e. give the flags to hand off to
compiler/libtool. pkg-config improves on *-config a bit in that it can
give you the flags for a bunch of packages at once, so in theory it
could handle the DU -rpath you mention. (But typically it's used in a
way that doesn't allow that:
 GLIB_LIBS = `pkg-config --libs glib-2.0`
 FREETYPE_LIBS = `pkg-config --libs freetype`
i.e. concat (GLIB_LIBS, FREETYPE_LIBS) is not going to be the right
thing always.)

pkg-config has some intelligence, i.e. if you request two libs at once
it will nuke duplicate flags and order the -l flags properly. Also, it
can gripe about missing dependencies or conflicting libraries. 

The CVS version of pkg-config also has nice syntax:

 pkg-config --check-requires 'gtk+-2.0 >= 1.3.2 ORBit >= 2.0' 

i.e. on the command line the syntax is the same as the .pc files, with
RPM-like dependency stuff. This sort of supercedes the
--atleast-version type of options we had before, and lets you check
versions while still giving a list of modules, so you can get all the
flags at once. Which puts us in a position to eventually have a global
view of the link line and assemble it correctly. 

I think for libtool it's as simple as having a concept of a "package"
in addition to a concept of a library, so we can pass "gtk+-2.0" to
libtool instead of "-L/home/hp/unst/lib -L/usr/X11R6/lib -lgtk-x11-1.3
-lgdk-x11-1.3 -lXext -lgdk_pixbuf-1.3 -lm -lpangox -lX11 -lpango
-lgobject-1.3 -lgmodule-1.3 -ldl -lglib-1.3", then there is little
point in pkg-config --libs. And at that point it's trivial to glom the
--cflags behavior in there too.

Then the remaining thing to add is the RPM-style version comparisons,
which is beyond my ability to implement in shell, but I'm sure someone
can figure it out. ;-)

Havoc