[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI-13 again [was: Re: string vs list processing]

From: Martin Grabmueller
Subject: Re: SRFI-13 again [was: Re: string vs list processing]
Date: Wed, 25 Apr 2001 06:32:16 +0200

> From: Marius Vollmer <address@hidden>
> Date: 25 Apr 2001 02:46:50 +0200
> Martin Grabmueller <address@hidden> writes:
> > I think I'll just merge my two shared libraries into one (called
> > or something) , and let it get loaded by
> > both the (srfi srfi-13) and (srfi srfi-14) Scheme modules.
> You could initlize the library like this in srfi-13.scm
>   (dynamic-call "scm_init_srfi_13" (dynamic-link "libguile-srfi-srfi-13-14"))
> and like this in srfi-14.scm
>   (dynamic-call "scm_init_srfi_14" (dynamic-link "libguile-srfi-srfi-13-14"))
> You don't need scm_init_srfi_13_14.

The problem is that some of the SRFI-13 procedures use a smob type
defined in srfi-14.c, so at least this must be initialized anyway.  so
I thought the cleanest thing was to just put them together.

The way I implemented it, the C primitives of SRFI-13 always get
loaded when SRFI-14 is used, and vice versa.  This is done behind the
user's back and the bindings of the module *not* imported are not
visible until it is imported explicitly.  The drawback is that the
loaded library is a bit bigger, but honestly, I can hardly think of
users who import SRF-14, but do not use SRFI-13.  It is not a
performance issue either, I think; and maintainability is okay, too.

And, we can always change this without breaking the interface.

> You can also put srfi-13.c and srfi14.c into their own shared
> libraries, and then make depend on
> like this (untested)
>     lib_LTLIBRARIES = \
>     libguile_srfi_srfi_13_la_SOURCES = srfi-13.x srfi-13.c
>     libguile_srfi_srfi_13_la_LDFLAGS = -version-info 0:0 -export-dynamic
>     libguile_srfi_srfi_13_la_LIBADD =
>     libguile_srfi_srfi_13_la_SOURCES = srfi-14.x srfi-14.c
>     libguile_srfi_srfi_13_la_LDFLAGS = -version-info 0:0 -export-dynamic
> I'm not sure if that will be an improvement, though.

I don't think it is, but maybe I am missing something.  I propose not
to change this now and see if it turns out to be a problem.  I'll keep
this in mind, though.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]