Re: Better support for transition to guile-1.6

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <address@hidden> writes:

    Marius> Neil Jerram <address@hidden> writes:
    >> 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.

    Marius> This is the one we need to worry about most, I'd say.
    Marius> However, it doesn't have to work for "whichever" version,
    Marius> only for a reasonable subset.  Right now, let's only worry
    Marius> about 1.4 and 1.6.

OK, but should we aim in future to provide more than one level of
backwards compatibility?  (Which would require a more complex
mechanism than our current deprecation approach.)  Or do we think that
one level will probably always suffice?

    Marius> A developer who is using Guile needs to decide whether
    Marius> he/she wants to require 1.6 or not.

    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?

    Marius> The critical situation is probably that someone does wants
    Marius> his program to work for 1.4 and 1.6 at the same time
    Marius> because he doesn't need features from 1.6 but he also does
    Marius> not want to force people with 1.4 on their systems to
    Marius> upgrade to 1.6.  I can imagine that say Debian is shipping
    Marius> 1.6 and RedHat ships 1.4.

    Marius> System-wide installed 1.6 versions should come with all
    Marius> deprecated features enabled.

Currently, this means with --enable-deprecated.  How are distro
builders to know this?  Is there any protocol for telling distro
builders how to build libraries for inclusion in a distribution?

If not, I think that we should arrange things so that

- the libguile we want distributed is the one that results when you
  run ./configure with _no_ options

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

    Marius> Ok, what I'm trying to say here is that we should only
    Marius> concentrate on what it means to make a program that is
    Marius> written for 1.4 to work unchanged with 1.6.  I have no
    Marius> idea how far we are off, frankly.

I guess we need to try building some key applications with the 1.5.x
releases.  But I think we should sort out the position on configure
options and naming first, so that we are clear about the objective.

    Marius> The problem of having a program use new features from 1.6
    Marius> and at the same time work 1.4 (by configuring the
    Marius> new-feature-using things away), is a different problem
    Marius> that we do not need to address within the 1.6 release.  It
    Marius> is good to provide help and code snippets for this issue,
    Marius> of course, but this doesn't nbeed to happen inside the 1.6
    Marius> release itself.  It can be provided from a web page, for
    Marius> example, and evolve as people contribute to it.  A wiki,
    Marius> using Thien's wikid.

This approach sounds fine.  I presume that a useful subset of these
snippets would gradually be packaged for inclusion in Guile
distributions.

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

    Marius> Yes.

See naming suggestions above.

        Neil