Re: Modified load-path proposal

From: ludovic.courtes@laas.fr (Ludovic Courtès)
Cc: Guile Users <guile-user@gnu.org>, Neil Jerram <neil@ossau.uklinux.net>
Subject: Re: Modified load-path proposal
Date: Mon, 17 Oct 2005 10:04:11 +0200	[thread overview]
Message-ID: <87ach8bmdg.fsf@laas.fr> (raw)
In-Reply-To: <rmi7jcedc08.fsf@fnord.ir.bbn.com> (Greg Troxel's message of "15 Oct 2005 11:40:39 -0400")

Hi,

Greg Troxel <gdt@ir.bbn.com> writes:

> before deciding about tags and descriptions, I think we need to be
> clearer on the semantics of these directories and why they'd be used.
> Let me take a stab at it, and I'm sure I'll leave out other's use
> cases.

I don't think we should reason about installation directories in terms
of packaging-system-managed vs. human-managed installations.  I think
the packaging system is just a special case of the "human-managed
installation".  However, packaging systems do provide an important
installation pattern that has to be made possible to use.

Looking at your proposal, I don't see why modules installed by a
packaging system would end up in a different directory than modules
installed "by hand".  When I install a C program, whether "I" really
refers to me or to a packaging system, I can specify installation
directories with a very fine grain.

In fact, maybe we should just mimic Autoconf/Automake and the GNU
Standards[0] by (i) identifying exactly what the various installation
directories we care about are, (ii) ensuring that they can be configured
at installation-time, and (iii) make sure there's a way for Guile to
know about them.  The good thing is that this is policy-neutral.

I guess the Guile-specific installation directories, for any given Guile
module set (I'm not talking about modules that come with Guile), are:

  - `guileschemedir', which is where Guile Scheme source files should
    get installed; by default, this could be
    `/usr/share/guile/MAJOR.MINOR';

  - `guilelibdir', which is where C libraries (glue code, wrappers,
    etc.) that come with a module should go; by default, this could be
    `/usr/local/lib';

  - `guileobjectdir', which is where we'd put byte-compiled code if we
    had a working VM.  ;-)

At `make install'-time, we'd still need to use a mechanism like the one
Neil proposed in order to `add-load-path $(guileschemedir)'.  We might
actually want to do this also for C libraries.  [BTW, Neil's proposed
`config.scm' is not unlike `ld.so.conf' (or equivalent) for C code.]

>From the user's view point, this wouldn't be any different from what is
done when installing C programs:

  $ ./configure --bindir=/usr/bin --guileschemedir=/there \
                --guilelibdir=/usr/share/lib/guile/2.3

In summary, if we look at Neil's `config.scm', it really cares about
`guileschemedir' (or `load-path'), and that's it.  So it might be
possible to make it contain just a simple list of directories.

OTOH, it might be a good idea to make it aware of `guilelibdir'.  This
way, if Guile is able to load a `.scm' file, it would _always_ be able
to load the shared object it opens via `dynamic-link', no matter what
LTDL_LIBRARY_PATH and friends look like.

Hope this makes some sense,
Ludovic.

[0] http://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user