Re: pkg-config support

[Ludovic Courtès]

Hi,

Thien-Thi Nguyen <address@hidden> writes:

> () address@hidden (Ludovic Courtès)
> () Mon, 28 Apr 2008 23:33:34 +0200
>
>    +# Note: `sitedir' must be kept in sync with
>    `GUILE_SITE_DIR' in `guile.m4'.
>
> The 1.4.x guile.m4 (appended) also has GUILE_LIBSITE_DIR.
> I think this would be a good addition; third parties can
> install machine- (architecture-) dependent files there.

Actually, both look like a bad idea to me.  :-)

Having a package that installs its modules to $(GUILE_SITE) instead of
$prefix/something is Bad(tm) as it breaks user expectations and the GCS
(see "Variables for Installation Directories"), and it makes it
impossible to run `distcheck' anyway.  Thus many packages end up having
their own `--with-guilemoduledir' option or similar that determines the
installation directory of Guile modules and defaults to
$prefix/something.

As for libraries, there's an additional problem.  Libraries that are not
meant to be used from C (e.g., bindings of some C library whose C API is
not public) would better fit under $pkglibdir than under $libdir.  In
that case, the `.scm' module that calls `load-extension' must contain
the full path to the lib, since it cannot expect it to be in ld.so's
search path.  The problem is that doing so precludes running tests from
the build tree, before installation.  (This is another instance of the
problem that Libtool has with `RPATH', where the `RPATH' in the build
tree must be different from the one in the installed library, so that
the in-tree library can be used for testing purposes before
installation.  Libtool solves it by rebuilding the library with the
right `RPATH' at "make install" time.)

IMO what we really need is:

  1. Autoconf support for, say, `--guilemoduledir', so that Guile
     packages can use it consistently;

  2. Automake support to somehow solve the above problem with the path
     passed to `load-extension'.

Both would be nice usability improvements.

Thanks,
Ludovic.