[Top][All Lists]

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

Re: Modified load-path proposal

From: Neil Jerram
Subject: Re: Modified load-path proposal
Date: Fri, 16 Dec 2005 01:00:26 +0000
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Neil Jerram <address@hidden> writes:

> [... initialize-packages vs. config.scm approach ...]

I just thought of one more argument that favours initialize-packages,
namely that initialize-packages allows execution of arbitrary code to
initialize a package (whereas config.scm would only modify
%load-path), and that's bound to be useful sooner or later.

One example is the (gnome-0) module that guile-gnome installs in
/usr/share/guile/site, and which modifies %load-path (to point to the
rest of the install under /usr/share/guile-gnome-0) and
LD_LIBRARY_PATH.  This unusual arrangement prevented me from loading
guile-gnome at first, because I was using /usr/local/bin/guile, which
doesn't have /usr/share/guile/site in its load path.  If the stuff in
(gnome-0) was instead installed under /etc/guile/packages, it would
work in principle for both /usr/bin/guile and /usr/local/bin/guile.

Then, if we allow that guile-gnome has to munge LD_LIBRARY_PATH in
(gnome-0), i.e. outside of its main installed module tree, we have to
go with the initialize-packages approach.  In fact guile-gnome
_doesn't_ have to do this, so its not an open and shut case.  (It
could move the LD_LIBRARY_PATH code to a module in the main tree, and
make sure that this module is always used before any that depend on
LD_LIBRARY_PATH.)  But it makes sense to munge the load path and
LD_LIBRARY_PATH in the same place, so I'd say this is a good argument
for the initialize-packages approach and for allowing arbitrary code


reply via email to

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