Re: The load path

[Neil Jerram <neil@ossau.uklinux.net>]

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. :-)

Regards,
    Neil




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