Re: The last piece in parallel-install

[Andy Wingo]

Yo,

On Fri, 2004-11-12 at 09:26 -0500, Greg Troxel wrote:
>   Greg suggested that the module be named (gnome gnome-N), where N is a
>   version. I think this is suboptimal because it requires that there be
>   two directories in the load path that have a gnome/ subdirectory, which
>   could lead to ambiguities.
[...]
> By ambiguity, I think you mean [...]

What I really meant was...

> [...] that it could be or later become confusing.

Not a strong point, but people poking around /usr/share/guile could get
confused.

> Just (gnome-n) is fine; the actual number installed at any time is
> unlikely to be more than three, even if guile-gnome achieves World
> Domination.  So the gnome-turds level in the standard path will be
> small, and they'll sort near each other, so it won't annoy people.

Hah! gnome-turds is funny. I agree they would be ugly, but also that
they wouldn't be too many.

>   The fact that the
>   module can be used at all indicates that it must be installed in a dir
>   of the standard load path, regardless of what the user's prefix is. This
>   also hacks around the default-inst-dir-not-in-the-default-load-path
>   problem. 
> 
> This is combining two issues, about one of which we do not appear to
> have consensus.  One is how a module installed in a prefix different
> from guile is accessed.  The other is how module-version-specific
> paths get added.  (With guile-gnome-0, the user has to put the
> $prefix/bin dir in their PATH.)   The versioned libs are intentionally
> put someplace that essentially cannot be in a normal load path, and
> that's fine.

> (BTW why are they in $prefix/share/guile-gnome-0, instead of
> $prefix/share/guile/guile-gnome-0?  Is that to keep them from being
> invoked as (guile-gnome-0 gnome glib), which would be a mess?
> Actually that seems like a very good reason.)

Neil's idea that guile modules should be "discoverable" is a nice one,
but until it's clear what modules are versioned and what ones aren't I'd
rather not invite this mess. (Although (use-modules (foo gnome gobject))
would raise a "no code for module" error.)

> So putting gnome-n  in the standard place (site or not :) in guile-gnome's
> prefix solves the version issue, leaving the different-prefix issue
> to be solved.  Whatever solves that will work with the version plan,
> so it's not necessary to have a joint solution 

I wanted to kill two birds with one, er, module. But I buckle! My real
priority is that I don't have to deal with a lot of crap bug reports
about "I tried (use-modules (gnome gobject)) but it didn't work." I'll
solve this in the 1.6 era by requiring that the user pass --prefix to
configure, erroring out with a note explaining the situation otherwise.
This will make sure that that naive user (it's a state I aspire to,
actually ;) won't get screwed by autoconf defaults. No more /usr/local
hacks.

>   It
>   can also munge the LD_LIBRARY_PATH with getenv and setenv, so that the
>   libs are found. Which means, it subsumes all of the functionality of the
>   guile-gnome-0 script!
> 
> I view this as only a workaround until the scheme code is fixed to
> load things from the right place.  In general as we get more
> complexity adding searching rather than 'look in the right place'
> seems to be asking for trouble, and thus searching should be avoided
> when the right place can be programmatically known (which it can for
> the libs).

I also see it as a workaround, but fixing it is a low priority for me.
See the other mail.

> Perhaps gnome-n can use some variable (in the (gnome) module?) as a
> flag that gnome-n has been used for some value of n, and error out if
> a different version is tried.

I'm ahead of you ;) It's already implemented. (Note that when you
use-modules (foo), a (foo) module must actually be defined, though.)

The current version is attached, pre-substitution. (It will be output to
gnome-$version.scm.)

Cheers,
-- 
Andy Wingo <address@hidden>
http://ambient.2y.net/wingo/

gnome.scm.in
Description: Text document