[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Managing Guile and extensions versions

From: Kevin Ryde
Subject: Re: Managing Guile and extensions versions
Date: Sun, 02 Oct 2005 11:59:47 +1000
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

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 does, but yes.

> For instance, `dlopen ("/lib/")' 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]