Re: Better support for transition to guile-1.6

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> (Hmm, I don't think waiting for something to be _fully_ resolved is an
>  implementable goal.  There will always be one last sticky thing...)

Well, by full resolution, I just meant that we consider the issue, and
come up with a plan, and then document the issue and the plan, noting
in particular what people developing with guile should and should not
do if they want to have the greatest chance of avoiding trouble.

> I think we should work with the libtool guys to add this feature to
> libltdl or libtool as a whole.  Off hand, I think the libtool would
> need to be changed so that multiple versions of a ".la" file can be
> installed simultaneously.

Already done yesterday :>

> Before we have that feature, we can make sure that passing an absolute
> file name to `load-extension' without an extension will work.  We can
> then tell people that need to distinguish between multiple versions of
> a plugin that they can install each version into their own directory,
> and pass the absolute filename (without ".so" suffix etc) to
> `load-extension'.

So people would need to name their libraries say libfoo4.so... and
then you'd say (dynamic-link "libfoo4")?

If so, would libfoo4 be provided via a symlink, or what?  We'll still
need the plain old libfoo.so.4... around, otherwise direct C linking
won't work right, and this definitely isn't likely a good long term
solution since we'll only be approximating the libtool versioning
algorithm.

>> Anyway, in the end I'm not too concerned about *which* policy we
>> chose, just that we choose one while understanding the ramifications,
>> and stick to it.
>
> I think the current way of doing it assumes very little on the part of
> Guile itself, and gives people the freedom to roll their own,
> including isolating plugin style libraries so that they don't clash
> version wise.

OK, so here's a first stab at a policy:

  1) All of our libraries will be versioned, even "semi-internal"
     ones.

  2) For the first release of a given library that needs to be
     dynamic-linked (i.e. our current releases), we'll just name them
     libfoo.X.so and you can access them from guile via (dynamic-link
     "libfoo").

  3) For subsequent releases where the interface has changed in a
     backward compatible way, until we have a dynamic-link that
     supports an interface argument, the "interface number" must be
     added to the name of the shared library, so we would have
     libfooX.Y.so and would say from scheme (dynamic-link "libfooX").
     (I'm not sure whether or not X and Y would always be the same --
     I'd have to re-examine the libtool versioning algorithm).

  4) Eventually we hope that dynamic-link will support an "interface
     number" argument and so we can drop the number in the library
     name and have instead (dynamic-link "libfoo" 4) or similar.

Does that seem right?

For debian, this means that guile's about to split into a much larger
number of packages, I'll at least have to add:

  libguilereadlineX
  libqthreadsY
  libguilesrfi-srfi-4-0
  libguilesrfi-srfi-13-14-0

so that we can support guile version transitions smoothly.

On the development side, I think I can get by with just the current
single libguile-dev package which would contain all the -dev bits.
(Right now, you can only develop for the latest guile using the debian
packages, since the -dev package isn't versioned).

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD