[gnutls-dev] Guile needs 1.8?

[Ludovic Courtès]

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Hi!  I think it is common in Debian to allow multiple versions of
> libraries to be installed, and that they don't conflict with *-dev
> packages unless the ABI isn't backwards incompatible.  In this case,
> doesn't the guile 1.8 libraries support the 1.6 API/ABI?

Oh, you're right: 1.8 does support (in deprecated form) the 1.6 API (and
ABI too, I think).

> My view is that the Guile M4 macros are broken here, the autoconf
> approach is to test for the features you need instead of relying on
> version information.

The Guile M4 macros don't check for versions.  I added such a check in
GnuTLS to address your (valid) concerns.

Guile has a versioning policy similar to that of GnuTLS: odd-numbered
branches are unstable and even-numbered branches are stable; there *are*
significant API changes between two subsequent stable branches, although
the previous stable API is still supported (and deprecated).

The switch from 1.6 to 1.8 was such a major change.  New features were
added and the API was overhauled.  The GnuTLS bindings are written
against the 1.8 API.  They also use features that were not available in
1.6 and never will, such as SRFI-4 vectors.  There's no way they could
someday "work" with 1.6.

Therefore, checking for *specific* features (such or such macro or
function) is irrelevant: we really want the whole shebang, not just one
macro.  Checking for `scm_from_locale_string ()' allows us to know that
we really get 1.8 (or some later backward-compatible version): this is
one of the functions that was introduced in 1.8 and that will definitely
never be available in 1.6.

> I'm not sure, do the GnuTLS guile bindings uses and require the
> scm_from_locale_string function?

Yes, they do require this specific function.  But even if they didn't,
that would still make sense to check for it, for the reasons outlined
above.

I hope this clarifies the rationale for the autoconf tests.

Thanks,
Ludovic.