Re: Modified load-path proposal

[Greg Troxel]

address@hidden (Ludovic Courtès) writes:

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

The point is that package systems demand exclusive access, and this is
on of the reasons to use multiple prefixes.

> 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';

It's not clear why this but not libdir should be versioned.

>   - `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';

arguably should be $(prefix)/lib/guile to keep from polluting lib.

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

this belongs under share, since it's machine independent.


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

Perhaps dynamic-link should look in guilelibdir _only_ if an absolute
path is not given, or a primitive that does this.  One important
feature is that inclusion, dynamic link, etc. should be able to ensure
it gets exactly what was searched for and tested at configure time.


-- 
        Greg Troxel <address@hidden>