Re: The load path

[Neil Jerram]

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