On Sat, Mar 08, 2003 at 11:10:47AM -0500, George Staikos wrote:
> > What libs were you using it with? Some libs get it a bit wrong
> > perhaps. If a lib doesn't install .pc files if pkg-config isn't found
> > at build time, that's just a bug in the lib's build. GLib certainly
> > does not do that. You can't blame something like that on the
> > pkg-config tool.
> 
>   glib was the main one.  I had to install glib, pango, atk, gtk+ (from 
> memory) to get swfdec to install.  It took hours, and the compiling itself 
> was only minutes of that. 

If you're saying you had to rebuild to get a GLib .pc file, but you
already had GLib, I just don't believe you... ;-) There is no way GLib
doesn't install its .pc file; it's not conditionalized in any way in
the makefiles:

  pkgconfigdir = $(libdir)/pkgconfig
  pkgconfig_DATA = glib-2.0.pc gobject-2.0.pc gmodule-2.0.pc gthread-2.0.pc
  
Standard automake stuff... it has to get installed to pkgconfigdir.

Maybe you were missing the glib2-devel package (or equivalent for your
OS) if using packages? Maybe you had GLib 1.2 installed but not glib
2.x? 1.2 does not have .pc files (but also would not satisfy an app
expecting 2.0).

> > You have to set PKG_CONFIG_PATH if you install a lib in a different
> > prefix from pkg-config itself, but this is documented in the man page
> > and works just like LD_LIBRARY_PATH, PATH, and so forth which
> > presumably already have to be set when using nondefault prefixes.
> 
>   This was not the case.  I had to set PKG_CONFIG_PATH even though I
> installed in the same place.  Perhaps something else locally was to
> blame.  I ended up wiping everything out and reinstalling 3 times
> before it worked.

I would like to blame something locally - it works for thousands and
thousands of people and I've never had this bug report.  If you had
captured pkg-config --debug output during the failure, we probably
could have figured it out.

> > libxml, libpng, Xft, fontconfig, etc. are all using pkg-config, in
> > addition to GNOME.
> 
>    Of course I have all of those installed without pkg-config.  If I install 
> pkg-config, do I have to reinstall all of these things, or write my own .pc 
> for them?

Only if they are broken. They should unconditionally install a .pc
file as glib does. (Assuming recent enough versions to have a .pc
file, some older ones don't.)

Including a .pc file in a library package/install does not create a
runtime or buildtime dependency on pkg-config. A .pc file is just
data. It only creates the need for apps to use pkg-config to read the
.pc file.
 
>    Fair enough..  but it has to work well on all the platforms we use if we 
> are to use it. Working well means that it can be installed at a later date 
> and not require the user to reinstall all his libraries. 

There is absolutely no reason you should need to reinstall libraries,
I have not heard that bug report, and the only way I can imagine it
being required is if some library does something really broken and
only installs a .pc file if pkg-config is found. There is no need to
have pkg-config installed to install a .pc file, so such a thing would
be categorically broken.

There is nothing complicated about pkg-config. There's a trivial file
/prefix/lib/pkgconfig/foo.pc, and 'pkg-config --cflags foo' reads the
cflags field from that file and prints it.  There's a little bit more
smart data munging than that, but really, not a lot else going
on. Certainly pkg-config has no way to be causing a need to reinstall
libraries. Either the library installed the .pc file or not. If it
didn't, the library's makefiles are hosed somehow. If it did, then
pkg-config will find it.

> There's no point in supporting pkg-config and traditional methods
> simultaneously either, imho.  At that point we've defeated the
> purpose of pkg-config.

I agree completely, the GLib-and-above library stack does not ship
with a custom *-config script anymore for that reason. Some libraries
don't have religion though.

Havoc