Re: Better support for transition to guile-1.6

[Neil Jerram]

>>>>> "Mikael" == Mikael Djurfeldt <address@hidden> writes:

    Mikael> The guile-1.6 release will be a real pain for many
    Mikael> application developers. [...]

My first thought: "But surely this is what our deprecation mechanism
is for!  Why isn't that enough?"

One of your points is that some changes in the API have not been
properly put through our existing deprecation policy -- I agree
completely that those omissions should be identified and fixed.

But what else?

Analyzing a little further, I think that your argument breaks down
into two points:

(1) perhaps the recent deprecation period has not been long enough

(2) perhaps the deprecation mechanism does not in fact help in the
    most common scenarios of transitioning between releases.

And I think you're right about (2).  Here's why...

The scenarios that application writers have to worry about when
considering different Guile versions are as follows.

(1) An application is distributed as source and should be compilable
    against whichever version of Guile is installed on the user's
    computer.

(2) An application is distributed pre-built but dynamically linked,
    and so should link against whichever version of Guile is installed
    on the user's computer.

(3) An application is distributed pre-built and statically linked, so
    it is convenient for the application writer if the application
    code is partly protected from changes in the API of the Guile
    installed on the writer's computer.

I think our current deprecation mechanism only really helps with (3),
which is the least common scenario in these packaged and dynamically
linked days.

(2), the most common scenario, I don't totally understand, but I think
it is addressed as much as is possible by libtool and the
version/revision/age system.  Isn't it a problem, though, that we
don't differentiate between the names of shared Guile libraries that
are configured with and without threads, or with and without
SCM_DEBUG_DEPRECATED?  Surely any ./configure level switch should
result in a differently named library, or else how is an application
to know what the library that it tries to link with actually contains?

(1), which is still more common than (3), is the scenario that could
be helped by autoconf macros and a compat.h header file, and which
isn't addressed (AFAICS) by the current deprecation mechanism.

But I'm not sure that it is necessary to provide configure.in tests
for individual changes.  Wouldn't a simpler mechanism like the
_GNU_SOURCE one used in libc suffice?

For example, an application written using the 1.4 API would always say

#define _GUILE_SOURCE_1.4
#include <libguile.h>

and then the libguile.h header in, say, version 1.6, could consist of

... normal 1.6 header decls ...
typedef ... scm_t_bits;

#ifdef _GUILE_SOURCE_1.4
... 1.4 compatibility decls ...
typedef scm_t_bits scm_bits_t;
#endif

Would that be any simpler?  (Probably this is an old debate, but I'm
not familiar with the outcome.)

Regards,
        Neil