Re: [PATCH] Declare `GC_dump' ourselves if <gc/gc.h> doesn't.

[Thien-Thi Nguyen <ttn@gnuvola.org>]

() ludo@gnu.org (Ludovic Courtès)
() Tue, 12 Jan 2010 18:19:44 +0100

   > | dnl See note for PKG_CHECK_MODULES in aclocal.m4.
   > | PKG_PROG_PKG_CONFIG
   > | if test "$BDW_GC_CFLAGS" || test "$BDW_GC_LIBS" ; then :
   > |   dnl We don't need to declare those env vars precious;
   > |   dnl PKG_CHECK_MODULES does that.
   > | else
   > |   PKG_CHECK_MODULES([BDW_GC], [bdw-gc])
   > | fi

   This patch shouldn’t be necessary since it duplicates what
   ‘PKG_CHECK_MODULES’ does.

Not exactly.  If there is no bdw-gc.pc on the system (as is the
case here on a Debian Etch installation),  PKG_CHECK_MODULES dies,
and so does the configure script.  The original README recommends
in such case to munge three variables.  Two of them are valid:
BDW_GC_CFLAGS and BDW_GC_LIBS.  The other (PKG_CONFIG) is bogus
because munging it interferes with "make installcheck".

   ... without reading ‘README’, so you basically shoot yourself
   in the foot and there’s not much we can do.  :-)

I don't know where you got that idea.  Here's what actually
happened: I read the README, applied the bogus advice, noticed the
breakage, and then worked on the patch so that the now-updated
README gives good advice, supported by the now-updated configure
script.  Lastly, i posted the patch for review.

There IS something you can do: take a stand against pkg-config and
DTRT (the Autoconf Way).  I know there are other packages that are
heavily reliant on pkg-config, but Guile doesn't seem to be one of
them.  You can do this by helping identify what are the features
of libgc (whatever version) that Guile requires.  With that info,
it would not be hard to write a test for the configure script.
So, please help answer that question (if you can).

thi