Re: Better support for transition to guile-1.6

[Marius Vollmer]

Neil Jerram <address@hidden> writes:

> OK, but should we aim in future to provide more than one level of
> backwards compatibility?

Maybe, but not this time. :)

>     Marius> Requiring 1.6 might be needed when he wants to use new
>     Marius> features, of course, and then the question is mood whether
>     Marius> the sources can continue to work with 1.4.
> 
> For this case, how do we write an autoconf macro to help check that
> the installed Guile is new enough?

It will also matter whether it is from a stable or an unstable branch.
I'd say we modify the existing GUILE_FLAGS macro to take a `requested
version' argument and look for a matching major version number,
raising an error when it doesn't match, for a minor version number
that is at least the requested one, issuing a warning when it doesn't
match, and when the minor numbers are equal, for a micro version
number that is at least the requested one.

> Currently, this means with --enable-deprecated.  How are distro
> builders to know this?

It will be in the release notes of 1.6.

> - running ./configure with any other set of options causes the built
>   libraries to have modified names, e.g. libguile-nodeprecated,
>   libguile-threads, libguile-nodeprecated-threads etc.

I have to think more about this (and listen to what others say).  It's
not only the library, maybe it's also the header files.
 
> I guess we need to try building some key applications with the 1.5.x
> releases.

Isn't that happening already?