[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Modified load-path proposal
From: |
Ludovic Courtès |
Subject: |
Re: Modified load-path proposal |
Date: |
Mon, 17 Oct 2005 10:04:11 +0200 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) |
Hi,
Greg Troxel <address@hidden> 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
Re: Modified load-path proposal, Ludovic Courtès, 2005/10/14
Re: Modified load-path proposal, Neil Jerram, 2005/10/17
Re: Modified load-path proposal, Ludovic Courtès, 2005/10/18
Re: Modified load-path proposal, Neil Jerram, 2005/10/19
Re: Modified load-path proposal, Vorfeed Canal, 2005/10/20
Re: Modified load-path proposal, Ludovic Courtès, 2005/10/20
Re: Modified load-path proposal, Neil Jerram, 2005/10/20
Re: Modified load-path proposal, Ludovic Courtès, 2005/10/21