guile-devel
[Top][All Lists]
Advanced

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

Re: Better support for transition to guile-1.6


From: Marius Vollmer
Subject: Re: Better support for transition to guile-1.6
Date: 07 Oct 2001 13:35:56 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102

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.

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

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

Requiring 1.6 might be needed when he wants to use new features, of
course, and then the question is mood whether the sources can continue
to work with 1.4.

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

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

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

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

> (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.
> [...]
> (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.

Right.

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

Yes.

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

That's a good idea, I think, for the future.



reply via email to

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