Re: pkg-config support for guile

[Greg Troxel <gdt@ir.bbn.com>]

  [I sent a patch to add pkg-config support.]

  I don't think we should offer two ways to get configuration
  information about Guile.  When pkgconfig is better than our current
  method, we should use it exclusively.  When not, we should keep our
  current stuff.

pkgconfig is better in that programs that use guile will not have to
include a guile-specific m4 fragment into configure - there is a
standard pkgconfig m4 fragment that suffices to link all programs that
use pkgconfig for config info.

But programs needing GUILE_MODULE_FOO will still need the guile m4.
This is really a separate problem from guile-config - using guile as a
scripting language rather than a libary, so not trying to use
pkgconfig here seems fine.

I don't understand why you think there should not be two ways.  Users
can use whichever way they like better, and this makes guile more
friendly.  Over time, I expect pkg-config to be more prevalent.  The
pkg-config support is very small, and most of the contents are
substituted via configure.  So having two ways is a reasonable
transition strategy.

  (When I say "we should use pkgconfig exclusively", I mean we should
  use it to re-implement guile-config in a compatible way.  We should
  definitely continue to offer the guile-config interface.)

Sure, the old interface should be retained.  But the real win comes
from people being able to just write a simple line to include the
library that is similar to how many other libraries are included.  I
have a line in some of my own (unpublished so far) sources that reads:

PKG_CHECK_MODULES(FOO, libfoo, AC_DEFINE(HAVE_LIBFOO), true)

The final 'true' prevents an error if the package is not found.

  > The file won't be useful without pkg-config installed, of course,
  > but this gives users a choice of configuration means.

  Why would they need this choice?  [genuine question(tm)]

Well, it seems the world is heading to a standardized method of
representing how to link with libraries (and handling recursive
dependencies, so linking with gtk gets you glib without explicitly
asking for it).  I view this as an abstraction of using libraries with
autoconf, and it's really only better because it implements a
well-defined interface instead of the ad-hoc
sort-of-like-other-packages homegrown one in guile.

The only downside is that the pkgconfig way requires that pkgconfig be
installed on systems where one links with pkgconfigized libraries.
pkgconfig is installed on most systems, since both the gnome and kde
worlds need it.

        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel