Re: packaging the add-on libs...

[tomas]

On Thu, Oct 10, 2002 at 10:22:42AM -0500, Rob Browning wrote:
> address@hidden writes:
> 

[...]

> It's been stated that we're going to keep all the directly linkable
> libs in the "normal place".

Yes, I know (that's why I know I was taking risks ;-). I felt uneasy
then and still feel uneasy abut it (see below).

>                              That means /usr/lib, and that would apply
> to all the add-on libs so far (i.e. we don't have any non-directly C
> linkable) add-on libs right now.
> 
> I guess you could argue for a versioned directory for any new shared
> libs that aren't supposed to be directly linkable by any other apps or
> libs.

Yes, kind of. Only that I'd substitute ``that aren't supposed to be
directly linkable by'' for ``that have to go with guile to be linked
by...''

In other words, if you need guile in conjunction with libfoo, then
libfoo has no business in /usr/lib or /usr/local/lib -- but rather
in /usr/lib/guile/1.6/ (or something like that). IMHO, of course.

[snip]

> These libraries *have* to care about which guile version they're
> linked against.  For example, libguile-srfi-srfi-4-v-1 *has* to be
> linked against libguile12 so it can use even primitive operations like
> car and cdr.  And of course libguile12 depends intimately on the
> particular source in ice-9/ that it comes with.  There's no such thing
> as a stand-alone guile module/shared-lib.  If they don't depdend on
> libguileX, they can't *do* anything -- no car, no cdr, no GC, etc.

Well -- one could imagine (say) some regexp library or some DBM library
which is delivered with guile but would make sense as a stand-alone.
If it's possible to keep the glue code separate, it might be possible
to make it guile-independent (my hazy memory suggests SDBM from Perl
as an example, but may be I'm forgetting important bits here).

Regards
-- tomas