[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The load path

From: Greg Troxel
Subject: Re: The load path
Date: 11 Nov 2004 08:23:40 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

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

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

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 <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]