The last piece in parallel-install

[Andy Wingo]

Yo,

As Greg noted (but I don't have offline), we need a programmatic means
for selecting the guile-gnome version to use[1]. There are a few
options, so we should discuss them I guess.

Priorities: conciseness, from the point of view of application code,
clarity of semantics, and Just Works(tm) foo.

The code to select a version should be encapsulated in a module, that's
clear. Ideally it would be a part of guile[2], but with 1.6 around for
the forseeable future we need to do it in guile-gnome. 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. 

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. (One for the standard load path, to get the
versioning module, and one that actually has the code.) Just (gnome-N)
is a better idea I think.

I thought about having just (gnome), which would export a procedure to
choose the version, but such a module won't allow for parallel
installation of different versions in different prefixes. This could be
a common case, e.g. when the distribution puts guile-gnome-0 in /usr,
but you install guile-gnome-0 to /usr/local or something.

For the record, this is what pygtk does:

import pygtk
pygtk.require('2.0')

For the version 2.0, it searches for directories named gtk-2.0 located
in the directories of the load path, and pushes them on the front of the
load path. We could have that strategy with (gnome), even hacking around
the /usr/local problem so that default installs Just Work. However, this
sounds tricky, especially regarding shlibs.

pygtk.require also raises an error if an incompatible version of pygtk
was already loaded. We can check the versions as well, either by
defining something in the root module (ugly) or by dynamically making a
(gnome) module, and defining a version variable there. The latter is
probably better

Now, the semantics: What actually happens when I (use-modules
(gnome-0))? Since (gnome-0) is tied to a particular installation of
guile-gnome, it knows where to find the modules, so it can push the
guile-gnome-0 load path directly (without searching like pygtk does). 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!

So I guess if we get this working, guile-gnome-0 can die. It bothered
me. Thoughts? I'll hack something up tonight, because I need it to work
to build against an installed guile-gnome.

[1] Parallel install and module versioning appear to be the same
problem.

[2] If versioning were a part of guile, it would mean putting
guile-gnome modules in a versioned subdir of the load path, like pygtk
does, because the generic mechanism can't know the specific location of
an installation. It would also entail solving the shlib problem.

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