Re: Better support for transition to guile-1.6

[Rob Browning]

Thien-Thi Nguyen <address@hidden> writes:

> 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

If by this you're suggesting that we just go ahead and define our own
API, i.e. (dynamic-link "foo" 4) and then write back-ends for
whichever platform-specific linkers we have, then I've been leaning
that way myself lately.

Trying to document some hack that all users have to follow like
providing the library under a versioned name (or anything similar)
seems like a bad idea.  It pushes the problem off on to the users, and
seems to guarantee that we'll have to require backward-incompatible
changes to all the code that calls dynamic-link in the future.

It seems to me that if we've got to plaster over a mess, it's better
to do that internally rather than externally.  Then when the problem
is fixed (presuming it does get fixed), we can just change guile's
internal implementation of dynamic-link and not require users to
re-work their code a second time.

So I'd like to propose the following, and if no one objects (or
volunteers), I'd like to start working on this, or on whatever else we
decide would be better:

  1) augment dynamic-link (or a new function) to take an interface
     number as an additional argument.  This argument will be optional
     for now, but if deprecation is on, a warning will be issued if it
     isn't specified.  So we'll have (dynamic-link "foo" 4).  [Here
     I've dropped the "lib" prefix from libfoo -- but should we?  It
     seems like that might be a good idea since how the libs are named
     may be a platform dependent issue.  I'm undecided here.].

  2) provide a libtool module (when the platform supports it) which
     provides the raw lt-dlopen, lt-dlsym, etc. functions.  People are
     allowed to use this module directly, but not in code intended to
     be "portable".  Alternately, or additionally, we might want to
     provide a lower-level function than dynamic-link, something like
     (dynamic-link-this-file file) which doesn't do *any* path
     searching.

  3) For now, on most platforms, if not all, (dynamic-link "foo" 4)
     will perform the same work that libtool does, searching
     LTDL_LIBRARY_PATH and LD_LIBRARY_PATH, etc. to find a library
     satisfying libfoo interface 4, bottoming out in either failure,
     or a call like (lt-dlopen "/some/dir/libfoo.so.4").

Note that I know this isn't an optimal solution, since for the time
being it will mean duplicating some of libtool's logic in our code,
but that seems like less of a burden than requiring that *every*
end-user who wants to add a shared library understand and follow some
interim scheme.

> in parallel:
>
>  - spin off guile-srfi package entirely, use it to test above

I'm not completely sure about that, but perhaps it's the right thing
to do.  I could see a counter-argument for having guile provide all
the srfi's that it can "out of the box".  If nothing else, we may want
to replace some of our homebrew functions with the more standard srfi
calls internally.

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

Right, I thought about that later.  That's going to lead to a
semi-painful proliferation of debian packages, but I suppose it can't
be helped.

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