Re: What replaces scm_register_module_xxx (Doc update?)

[Dale P. Smith]

On Thu, 8 Aug 2002 18:19:58 +0200
address@hidden wrote:

> I think there's a misunderstanding/misconception here (or, better:
> in guile's current C api). The 'load-c-functions-through-scheme' 
> aproach might be fine and all that's needed as long as we only want
> to extend _guile_ (the application) with external libs. But guile
> is inteded to be an embedded srcipting language as well (at least that's
> what the documentation says). If i want my users to be able to script
> some of my applications functionality there's no library i can load
> with 'load-extension' -- of course i could put the tiny scm_* wrapper
> functions into a dll and have _that_ loaded, but i wouldn't call this 
> good design practise (oh, i could 'load-extension' my own application
> instead, but that's not really portable ...). Having to provide (and
> deploy!) scm file(s) just to be able to put my functions into different
> modules feels clumsy. 

I think it's possible with the (undocumented) scm_c_* functions in
libguile/modules.c.  It looks like this is the first stab at providing a
C interface to the module system.

A problem that I see is that there is no way to tell the snarfing system
which module to put things in.  It's not that big of a problem if you
split up different "modules" into different C files.  In the init
routine for the file, you first call scm_c_define_module, then #include
the .x file, then call scm_c_exports with the names of the symbols you
need to export.

You might want to verify the scm_c_* fucniton names I used.

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
address@hidden            | http://cleveland.lug.net
440-746-9000 x339               |