Re: Parallel installability with 1,3,4?

[Andy Wingo]

Hey Rob,

On Sun, 2004-09-12 at 18:51 -0500, Rob Browning wrote:
> Andy Wingo <address@hidden> writes:
> 
> > I really wish one could pass parameters to modules as they are used,
> > e.g. version.

Thought of another application of this: guile-gnome delays the creation
of generic functions and type classes until they are referenced in the
source, because GOOPS is really slow. However, you don't have a list of
those delayed classes and generics, you have to know them (or deduce
them from the normal procedures, which are always there). For
development, it would be nice to
    (use-modules ((gnome gtk) #:force-latents #t)).
Of course, we can just make a helper procedure to do this...

> > In short, the libraries are not parallel-installable. How do you
> > propose to fix this?
> 
> So we can call (dynamic-link "libguilereadline-v-12")

Seems ok for C extensions...

> For scheme level modules, you can do the same thing -- you might have
> (use-modules (g-wrap core-1)).  This is not as nice as some future
> mechanism that might support levels of backward compatibility the way
> that ld.so does,

You know, I think we can solve part of the problem in a similar manner,
via symlinks. For example, maybe have (g-wrap) be a link to an .scm
in /usr/share/g-wrap-XXXX/g-wrap.scm, and the g-wrap/ dir linked
to /usr/share/g-wrap-XXXX/g-wrap/. This allows for ease of development,
and then when you go to ship an app, you "link" it to the proper version
by pushing versioned dirs on guile's load path. Even easier with the new
command line switches in 1.7.

Perhaps since the shlibs of old g-wrap are distinct from the new one,
the best solution for gnucash would be to have their wrapper script
push /usr/share/g-wrap-1.3.5/ onto the load path. No changes to source,
besides their trampoline script.

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