Re: [PATCH] Thread Plug-in Support #2

[Rob Browning]

NIIBE Yutaka <address@hidden> writes:

> If Guile is going powerful enough, we need more good support for
> interfaces, modules, and dependency.  Then, I think that it is not
> programmers job to keep the knowledge of dependency in his memory.

Hmm.  In the end, ideally, I think you should be able to say:

  (use-modules (foo bar))

and get the (foo bar) module loaded, along with whatever other
sub-modules it depends on, and whatever C shared libraries are needed.

*Ideally* you shouldn't have to specify a "version number" in the
use-modules statement.  However, if we actually *want* versioning for
guile level modules (which it's sounding like maybe we don't), I'm not
sure that given current tools, we can be that clever in the short run,
so perhaps you might need to say:

  (use-modules (foo bar :version 1))

It would then be up to the runtime system, based on information
provided by the various available implementations of (foo bar) (if
there was more than one) to figure out how to provide what you've
asked for.

However, let's presume for the moment that we *don't* want to deal
with guile level modules, then the only question is how do we deal
with loading the right version of a C shared library that provides
code that a given module (or modules) might need, especially if we
want to support cases where (foo bar) needs libXXX implementation
version 2 and (baz bax) needs libXXX implementation version 3.

In that case, for now, it seems like the person writing a given module
(which needs to load a C implementation part) will just have to know
what version of the library suits their needs (which will usually just
be whatever version is the current one), and then put that information
into their module file:

  (define-module (foo bar))

  ;; Note the integer arg to dynamic-link...
  (dynamic-call "foo_init_scm" (dynamic-link "libfoobar-main" 3))
  (dynamic-call "foo_init_scm" (dynamic-link "libfoobar-extra" 5))
  (dynamic-call "foo_init_scm" (dynamic-link "libfoobar-low" 9))
  
  ;; presuming there was corresponding scheme code too...
  (load "foo/bar/main.scm")
  (load "foo/bar/extra.scm")
  (load "foo/bar/low.scm")

I *think* that given libtool's conventions for versioning, from the
shared library client side, you only need to specify the main version
number of the library interface you need, so the single integer arg to
dynamic-link might be all we need.  Given that information, by
examining what's available on the system in LD_LIBRARY_PATH and
comparing what you asked for to the available CURRENT and AGE numbers,
libtool can find the most recent shared lib that satisfies your
request, which is what ldso already does for normal dynamic loads.

> When Guile will support interface/module/dependency, I think that
> Guile system should support compiling/building as well as running.
> 
> For current system, I agree with you. 

Then it sounds like we're all pretty much in agreement.  Basically,
there's a discrepancy between what we might want to do right now,
given existing tools, and what we might *really* want to do later,
with improved tools.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930