[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkg-config support
Re: pkg-config support
Wed, 30 Apr 2008 15:24:52 +0200
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)
() 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
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
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
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"
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,