[Top][All Lists]

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

Re: Better support for transition to guile-1.6

From: Steve Tell
Subject: Re: Better support for transition to guile-1.6
Date: Tue, 23 Oct 2001 00:05:28 -0400 (EDT)

On 14 Oct 2001, Neil Jerram wrote:

>     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

At the moment, we've already got the problem for 1.3.4 and 1.4, since some
major distributions _still_ ship 1.3.4.  (such as RedHat 7.2, released
today!) I hope no one minds unofficial discussion what has to be done to
get applications to compile on any of 1.3.4, 1.4, and 1.6, and also for
all three libguile's to coexist on a single system.

I develop one little application, and it seems a serious hindrance for
users to upgrade guile in order to build it.  Besides, things almost work
for multiple guile versions to coexist, at least as far as .so libraries
go.  Even if a user does choose to upgrade guile, that can't trash
distribution-standard packages. But wearing my developer hat, I feel that
its still very important to make my app run on 1.3.4, even though I mostly
develop on 1.4.   (I keep another machine around for testing under 1.3.4)

BTW, the following sequence seems to work on redhat 7.1: 
- start with a stock system 
- compile and install (or build RPMs for) applications that still
  only build with 1.3.4 and earlier (such as scwm, still my favorite
  window manager!) 
- build a guile-1.4 RPM 
- install guile 1.4 using "rpm -i --force", thus leaving /usr/lib with
  both /usr/lib/ and /usr/lib/
  /usr/share/guile already splits things into per-version directories
  beautifully, so ice-9 still comes out OK.

The only real hindrances seem to be:
- doesn't have a proper version number, but
 the 1.3.4 one and the 1.4 one don't mix.  So only one guile binary can
 use readline.
 But moving forward past 1.5.*/1.6, I expect similar trouble with the
 libguile-srfi-*.so's.  Would it be  possible to make their .so version
 numbers match the one on libguile?
My personal preference is to keep working this way:
- distribution-standard and current-stable guile both installed as
  packages into /usr on main machine.
- prerelease guile (1.5.4 now) installed into a totaly seperate --prefix
  for test builds.
So I if I come up with any little suggestions to make this easier, I
a hope nobody minds...

Would it be too much to ask for "make install" to install the interactive
guile binary with an explicit version number, and then create a symbolic
link?  So that /usr/bin might have guile-1.3.4, guile-1.4, and guile-1.6,
with guile being a symlink?

thanks for listening...

Steve Tell  address@hidden 

reply via email to

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