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

[Marius Vollmer]

NIIBE Yutaka <address@hidden> writes:

>  > Yes, good point.  I haven't thought of this previously.  But again, I
>  > feel safer when we would do it the standard way (standard for C, not
>  > for Perl, etc, since the shared libraries have been designed for C).
> 
> Well, how about static linking?  Building the library B which depends
> on library A, there's no dependency information within the library B
> (except the references themselves).
>
> When we use the library B, say, build the executable with library B,
> we need library A too.  Here, the information of dependency is not in
> library B, but programmer specifies library A.  In this view, it's not
> rather trycky but usual for C programming.  Well, YMMV.

Yes, right.  I think we can elevate libtool to define the standard for
us.  It handles dependencies between static libraries by including the
needed information into the .la files, right?
 
> While I assume Guile system should provide the dependency information
> about extension, it seems you're not.

Well, I agree that having the dependencies managed automatically is a
good thing.  But I feel not confident enough that I can design a
really universal system for that, and thus, I want to refrain from
pretending that we do handle dependencies, while in fact we are only
making the shared libraries mess worse.

Libtool is handling dependencies between shared libraries already, and
I think we should just use that.

> I'm afraid of putting extension under /usr/lib, because it means, it
> can be used under no control of Guile system, which results chaos.
> It seems that you think that it is programmer who cares which
> extention is depends on which.

These are two unrelated things, I'd say.  I'm not too much afraid of
name clashes in /usr/lib (or more generally, between all shared
libraries available on the system) when we have a simple naming scheme
like using libguile-foo-bar for an extension associated with a module
(foo bar).

Dependencies between extensions should be specified by the authors of
the individual extensions, of course, but we should use libtool to
cover up for the deficiencies of the Unix library system.

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

Yes, I agree.  Which dependencies must the programmer handle manually,
right now?  Dependencies between Scheme modules are taken care of by
`:use-module' etc and auto-loading, dependencies between C level
extensions are delegated to libtool.  What do you think is missing
(serious question)?

> For current system, I agree with you. 

Ok!

One thing to keep in mind is maybe that Guile Extensions should be
regarded as second class to Modules.  A user should not directly
request an extension, but only inderectly thru a associated module.
That is, extensions written in C are one implementation technique for
modules.