[Top][All Lists]

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

Re: Managing Guile and extensions versions

From: Ludovic Courtès
Subject: Re: Managing Guile and extensions versions
Date: Mon, 03 Oct 2005 14:58:07 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Kevin Ryde <address@hidden> writes:

> 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.)

Right (but I'm under the impression that Libtool releases are more
frequent than Guile releases ;-)).

> 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.

Sure.  But while Guile developers can do their best to ensure that
Guile's modules don't change much over time, one cannot assume that
users of Guile won't ever need some versioning.

In actuality, versioning is something people have been expecting when
writing C code (and Libtool helps with this), and it's something which
other run-time supports, like Guile, should provide IMO.  Most of the
time, when one defines an API, be it in C or in Scheme, they cannot
guarantee that it won't ever change.

> 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.

Right, but you're talking of Guile itself.

> 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.

I'm not sure what you're talking about here.


reply via email to

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