Re: Better support for transition to guile-1.6

[Thien-Thi Nguyen]

   From: Rob Browning <address@hidden>
   Date: Sun, 18 Nov 2001 23:33:53 -0600

   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.

ewwww, parsing.

can i suggest a different approach?  now that we know that there are
multiple versioning/namespace schemes that control external lib access
(including those we've invented and abandoned), and whereas the
transition guide is still vapor (correct me if i'm wrong), and whereas
possession of guile may require exercising duplicity, why don't we:

 - write a general extension-protocol dispatcher
 - write default, ltdl, pre-1.5 and 1.6 specialization modules
 - write an autoselect (easy)
 - document this heavily

in parallel:

 - spin off guile-srfi package entirely, use it to test above
 - finish NEWS-combing
 - write a migration guide

i guess i'll start at the bottom of the list.  :-/  but a goops hacker
should start at the other end...

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

the ramifications of not supporting a general pluralistic solution from
the beginning is a slow painful approximation over time.

     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?

these particulars can be encoded.

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

this won't work cleanly -- the headers must reflect the libraries;
versioning is required.

thi