[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: dynamic loading of native code modules]
From: |
Thien-Thi Nguyen |
Subject: |
Re: address@hidden: dynamic loading of native code modules] |
Date: |
Tue, 14 May 2002 17:19:52 -0700 |
From: Rob Browning <address@hidden>
Date: Wed, 24 Apr 2002 10:28:14 -0500
i.e. other apps are supposed to be able to
link appropriately and then call scm_make_u8vector directly.
"directly linkable" is less important an attribute to consider than
"independently linkable". to continue w/ this example, you still need
libguile around to make sense of `scm_make_u8vector' return value, that
is, libguile-srfi-srfi-4 is not independent of libguile. understanding
this is crucial to understanding how much freedom you can gain by not
subscribing to system-wide conventions.
It may well be that the subdirectory approach is suitable, and in fact
its one I originally leaned toward, but I was shifted away after
talking to Marius about direct linking and realizing that if we were
going to properly version all our shared libs to accmodate etc.
well, then i say you were swayed by fuzzy thinking -- "direct linking"
by 3rd party programs is a red herring for the plug-in system designer.
it's a nice feature to provide, but its implementation is best done
through the interface provided by libguile, aka `load-extension'.
btw, i think your ideas on extending `load-extension' argument list are
a good start. concentrate on designing this abstraction interface in a
general way and you'll be fine -- do not confuse extension namespace and
sofile namespace.
thi