Re: [PATCH] Thread Plug-in Support #2

[Rob Browning]

NIIBE Yutaka <address@hidden> writes:

> If it is OK, we just put the modules into
>       /usr/lib/guile/VERSION_OF_GUILE/MODULE.so
> 
> As Guile knows its version, there's no confusion to load modules
> compiled for other version's Guile.

That's possibly a fine solution, and one I think Marius and I may have
discussed a while back when we were discussing module shared library
fs locations.

However, my main point was that we have to do something different from
what we're doing now.

But I think one of the first things we have to determine is how much
flexibility do we require -- what are our goals.  We need to answer
questions like (though not perhaps exactly) these:

 - When going from guile 1.6.1 to 1.6.2, should all C dynamically
   loaded .so files have to be recompiled?  If so, what about ones
   that aren't part of guile proper, i.e. do we have to recompile add
   on packages too?

 - If not, then when should we require recompiles?  Just at major
   version changes?  What happens if we need to change something from
   guile 1.6.1 to 1.6.5 that's likely to affect/break all the
   dynamically loaded .sos.  Do we just say "don't make changes like
   that"?

 - If we do want to be able to indicate incompatibile guile core
   changes to dynamically loaded .sos?  If so, how? (in C-land, you'd
   just bump the libguile major version number).

 - Should the system be able to detect when an incompatible (whatever
   we decide that means) .so file is loaded (or about to be loaded)
   and warn-about/prevent it?

 - Do we care about trying to manage inter-module versioning issues
   (both at the .scm only and dynamically loaded code levels)?
   I.e. say module (foo bar) version 1 depends on module (baz baz)
   version 2.  Then say (baz bax) is upgraded to version 3.  What
   happens?  If we had some kind of C-like versioning for modules, we
   could just keep both around.  If not, then *every* module that
   depends on a module that changes it's API has to be updated at the
   same time.  This is often an awkward situation and can cascade
   unplesantly.  This problem is not exclusive to .so parts of
   modules.  It is also relevant to pure .scm modules.

Anyway, I think we need to answer a set of questions like these
(though perhaps not these exact questions) before we'll know what we
want/need.

However, I *don't* think we need to kill ourselves coming up with the
perfect solution, just try and not miss something obvious.

For example, the C library versioning model, though limited in some
ways, seems to work pretty well, so perhaps we might consider
something like that as a default, if we decide we need anything at
all.  (Here I'm talking about the libtool model of CURRENT REVISION
AGE, not the actual implementation which relies on file names like
libfoo.x.y.z.so.)

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930