Re: pkg-config support

[Thien-Thi Nguyen]

() address@hidden (Ludovic Courtès)
() Wed, 30 Apr 2008 13:49:14 +0200

   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")

I guess i will disagree on user expectations.  I'm a (strange, granted)
user and when i install Emacs Lisp, i expect there to be a `lispdir'
(with defaults under Emacs' tree, but customizable, of course), and
likewise for both .scm and .so files, under GUILE_SITE and
GUILE_LIBSITE, respectively.

This is because Emacs advertizes its "site" directory and nicely handles
third-party files installed there.  Likewise Guile w/ its "site".  In
Guile 1.4.x (and, as you may know, also for Guile 1.6.x), specially
crafted shared object files somewhere under %load-path (either "site" or
"libsite") can be handled just as well as scheme files, w/o any libtool
hassles.

So, having used these facilities, i expect them and welcome macros like
GUILE_SITE and GUILE_LIBSITE that make the process easier.  Probably the
GCS should be extended to encourage use of these (then inclusion in
Autoconf will be a side-effect).

   and it makes it impossible to run `distcheck' anyway.

Could you please explain this (or point me to some relevant docs)?

   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.

This sounds like an argument for including GUILE_SITE and GUILE_LIBSITE.
Am i misunderstanding you?

   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.

Sure.  Private libraries should not be installed under GUILE_LIBSITE.
That's not under discussion.

   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.)

I sympathize w/ the `load-extension' difficulties, but don't experience
them, personally.  Guile 1.4.x treats (certain) shared object libraries
as first-class modules, using "module catalogs" to locate a particular
module.  This builds on capabilities that were dropped after Guile 1.6.x
(IIUC).  Perhaps those can be brought back.  The end result is that i do
"make check" all the time using pre-installed modules.  No Big Deal.

Libtool is nice, but i've discovered that having Guile answer the "where
is it on the filesystem?" question is nicer.

   IMO what we really need is:

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

For Autoconf to adopt something, it helps our case if that something
exists and is in use, first.  It's backwards to expect a good-fitting
standardization effort to come from Autoconf.

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

Good luck w/ that!  I've been happy w/o `load-extension'; IMHO the
sooner you let go of its approach the sooner you can be happy w/o it,
too.

thi