Re: The load path

[Greg Troxel <gdt@ir.bbn.com>]

I agree that there is a problem, but I'm not comfortable with
hardcoding /usr/local.

On NetBSD 2.0, /usr/local/include is _not_ in the default search path
for the compiler.  One includes -I/-L if one wants that.

And, adding /usr/local to guile's search path (as opposed to the
prefix with which guile is built, which is already there) doesn't
really solve the problem - it just means that guile built with some
prefix and some module built with /usr/local will work, not any other
combinations.

Often people use prefixes to keep things separate.

With C libraries, techniques like pkgconfig find linking information,
but that's not available.  Even still, one has to muck with
PKGCONFIGPATH.

I think what's needed is first agreement about whether modules
installed in prefixes different from guile's prefix should be visible
to guile programs that don't set %load-path, and then how to do that
in the general case of two different prefixes.

One way that seems pretty simple is to have a directory in guile's
prefix that has files containing extra directories for %load-path, and
a guile utility that takes a prefix and ensures that a file for it is
in this directory.  Then, modules can simply call

guile-prefix-ensure $(prefix)

as part of the install process.  Alternatively, a similar per-user
directory could be used, so that one could do 'guile-prefix-ensure
--system' for the global one.

I've also symlinked module dirs from another prefix into guile's.
This isn't super clean, but it was easy.

Binary libraries for modules are another story; IMHO modules should
construct absolute paths for their own libraries from the configured
prefix, and not rely on search paths.

-- 
        Greg Troxel <gdt@ir.bbn.com>


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