[EMAIL PROTECTED] (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 <[EMAIL PROTECTED]>
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
