Andy Wingo <[EMAIL PROTECTED]> writes:
> Hi Neil,
>
> On Sat, 2006-01-21 at 09:01 +0000, Neil Jerram wrote:
>> Basically agreed, but what I now plan precisely is as follows.
>
> Oh good, a summary of this thread of many moons :)
I'm sorry it's gone on for so long. Every time we appear to near a
consensus, some new issue pops up.
> A question though. What is the problem which is being solved here?
The basic scenario is this: someone has Guile installed (probably by
their distro) in /usr, and then builds and installs an additional
package using ./configure && make && sudo make install, which installs
with a different prefix than /usr (usually /usr/local). Then they try
to do a (use-modules (newly-installed-package)), and it doesn't work,
because the installed Guile's load path doesn't include anything
beginning with /usr/local/share/guile.
So the question is: can we define a mechanism so that the use-modules
would just work?
Some time back, I thought that the right thing to do might be for the
package to discover the installed Guile's site directory and install
its modules there. But there was a strong consensus that that was
wrong, and that when a package is configured with a given prefix, it
must install all its files under that prefix (except for config files
which go under the configured sysconfdir).
> In guile-gnome I only really use the load path in one place. That is
> that (use-modules (gnome-0)) adds the path for version 0 of the
> guile-gnome API to the load path. Before that you cannot import (gnome
> gobject), for example, because it's not in the path. Afterwards you
> can.
Then the question in your case would be how do you get the initial
(use-modules (gnome-0)) to work?
> This was done this way to allow me to break API in the future, but leave
> existing programs still working.
>
> In that sense a global path that adds gnome isn't terribly interesting,
> because you have to select the API version in the first place.
The way I see it, the global path would be the one that allowed
(use-modules (gnome-0)) or (use-modules (gnome-1)) to work. It's fine
if (gnome-0) or (gnome-1) then extends the load path further.
>> 2. Each Guile package installs a file under /etc/guile which contains
>> its load path as a single string.
>
> What about packages that depend on each other? Is that out of the scope
> of this proposal?
No; the idea is that each installed package does whatever is needed to
allow Guile (or any other Guile package) to bootstrap its modules.
> I assume you mean /etc/guile/$effective_version
Actually I meant to be vague, hence "under" :-). My guess is that
many Guile packages are version-independent, so could install their
paths under /etc/guile/common. Packages that know they are
version-dependent could install under one (or more)
$effective_version's. I'm not really sure on the details here yet.
> I think requiring users to run a command to fix the cache is an
> invitation for bugs. I think it would be sufficient to have a cache in
> ~/.guile.d/cache, that would effectively hold the output of running
> guile-config. That way the normal case is that one only stats the cache,
> reads the system path dir, statting entries there, and then if
> everything is up to date just load the cache file. That's one readdir,
> one file read, and about 5 stats. Not expensive at all.
Sorry, I understand your overall idea about the cache, but I don't get
the details; can you be more precise about the reads and stats?
> Perhaps I'm just burned by the fiasco that was gstreamer's gst-register.
> Now having gotten rid of it, making the "registry" user-local and with
> strict cache semantics, we get no bugs about it.
That sounds like useful experience. Can I go somewhere to read more
about it?
> Sorry to bring up issues this late in the game.
No problem; thanks for your input.
Regards,
Neil
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
