[Top][All Lists]

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

Re: The load path

From: Neil Jerram
Subject: Re: The load path
Date: Thu, 18 Nov 2004 19:44:39 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3

Greg Troxel wrote:

The situation tha motivates this comment is e.g. when one installs
guile with --prefix=/usr/pkg (perhaps as part of pkgsrc, so it's semi
part of the OS), and then installs some guile module "foo bar" as
--prefix=/usr/y0 (not choosing /usr/pkg because every file in /usr/pkg
is supposed to be registered as part of the pkg db).  Then, one wants
to be able to (use-modules (foo bar)) in guile without fuss.  the foo
bar module source is nominally expecting to install in the same prefix
as guile, so it might have installed things in either
$prefix/share/guile or $prefix/share/guile/site.  (If it's not ok to
install in the former, a) please point me to the docs that say this
and b) explain why it's in the load path :-)

So, in the general case, to suppport packages in /usr/y0, one needs to
add /usr/y0/share/guile and /usr/y0/share/guile/site to %load-path -
the "standard" locations within the load path.
/usr/y0/share/guile/1.6 would be for _parts of guile_, and I agree
that this makes no sense for alternate prefixes.

I view 'site' as being a directory that can be shared among a group of
admin'd machines, but really it's like site-lisp in emacs and thus
local.  I put things in /usr/pkg/share/guile (no site) when they are
packaged rather than local.
I see your argument, and I think this is a useful clarification of .../guile vs. .../guile/site (I was previously wondering what the point of having both of these), but I'm afraid I'm still not convinced.

(1) If site is like site-lisp, then why does there need to be a site other than the one belonging to the Guile install itself?

(2) Even if there is a need, it's still nicer - because more explicit - to add both .../guile and .../guile/site independently to the configure option.

ttn's guile supports binary modules (which I think are a cool thing,
despite also seeing the merits of the arguments that one should use a
scheme shim to load them and export symbols).  These are deprecated in
guile 1.6, but I really hope they don't go away, because it would make
guile-pg (PostgreSQL interface with automatic type conversion - very
spiffy) harder to use under the upcoming 1.8, and I don't see the harm
in leaving them as a deprecated feature.  Because these modules are
shlibs, rather than scheme, they are arch-dependent and can't go in
$prefix/share, and in ttn-guile they belong in LIBSITE_DIR, which is
normally $prefix/lib/guile/site:
Thanks for explaining. I don't think I fully understand what's behind the lib vs. shared split. (If shared is really shared, for example, how does it work that both <installation in $prefix/lib> and <installation in $prefix/shared> are 1:1 with <make install>?) However, given also that the lib idea is currently controversial, I'm inclined to argue that this is a further motivation for saying that the arguments to the configure option should be complete additional directories, not prefixes. :-)


reply via email to

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