Re: address@hidden: dynamic loading of native code modules]

[Rob Browning]

Thien-Thi Nguyen <address@hidden> writes:

> alternatively, we need to document *why* 1.6 chooses to rob the
> users so, at least to ourselves.  "This has been found to be too
> tricky, and is no longer supported" is, although not dis-honest,
> still pretty lame.

This was not done to "rob" anyone.  It was done because (after a lot
of heavy use of the shared lib system), the previous "automagic"
loading was in some cases a little too smart for it's own good.  It
made it difficult to create a module that needed several shared libs,
or a shared lib that served several modules.  It also didn't allow any
easy way to work around problems in libtool (which are still serious)
from the scheme level.  I'll comment more on this later, but for part
of the issue see workbook/bugs/versioning-of-extensions.

Don't get me wrong, I'm not opposed to a more user-friendly,
higher-level interface, but IMO we need a sufficiently flexible
alternate (or lower-level) interface first, and in the process we need
to come up with a coherent solution that includes shared-lib-esque
versioning for scheme level modules (i.e. via use-modules).  We also
need to make sure that our interface abstracts the lowest levels
enough so that we can work around any libtool "issues".  I have a good
idea of how I think most of this should look, but was planning that
this wait until 1.8.

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