Re: Managing Guile and extensions versions

[Kevin Ryde]

address@hidden (Ludovic Courtès) writes:
>
> In fact, Libtool's versioning mechanism already makes this possible for
> programs: the loader and/or dynamic linker chooses the one version of
> the library the program expects to be linked against.

Oh, well, libtool only wraps what ld.so does, but yes.

> For instance, `dlopen ("/lib/mylib.so.2.3.4")' does
> load a specific version of the lib, but in a non-portable and unclear
> way.  `libltdl' could provide a higher-level, portable API to do such
> things.

I think difficulties with two .la's at the same time has been a
more-or-less known issue for quite a while.  There may be plans afoot,
but you might have observed the pace of libtool development is, well,
glacial.  (No disrespect to the libtool developers, it's a big and
arcane beast.)

> (However, I'd be glad to hear your thoughts about adding support for
> versioning to Guile's module system.)

I believe it needs very careful thought, because it's about planning
for or imagining what the future will look like, something that's far
from settled.

A system of versions virtually concedes that compatibility won't be
maintained, and that some kind of perpetual revision or at least
rebuilding of modules will be necessary.  It'd be better if that could
be avoided.

I think the present seems worse than it is, because the last couple of
releases have had a lot of changes.  If it settles down then the need
to version stuff like crazy ought to vanish.

The doco for the present is pretty light-on though.  Perhaps only
power-users have gone beyond the basics. :-)  I'm not aware of any
outright show-stoppers in the code though, not for any sensible sort
of arrangement.