This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Help: modules and -s switch
- To: Ian dot Grant at cl dot cam dot ac dot uk
- Subject: Re: Help: modules and -s switch
- From: thi <ttn at revel dot glug dot org>
- Date: Tue, 30 May 2000 08:40:01 -0700
- CC: guile at sourceware dot cygnus dot com
- Reply-to: ttn at glug dot org
From: Ian Grant <Ian.Grant@cl.cam.ac.uk>
Date: Mon, 29 May 2000 17:52:37 +0100
I used to use (use-modules ...) to load my C module but now I use
(dynamic-call # (dynamic-link #)) instead because of the problem of
putting architecture dependent executables in $(datadir).
This works, except I don't know how to get the new definitions into
the right module because which module that is depends upon whether
guile is being run interactively (when it should be the guile-user
module) or in command-line mode with the '-s' option to run a script.
Currently I have a scheme module (database postgres) that looks like this:
(define-module (guile-user))
(dynamic-call "init_postgres" (dynamic-link "libpostgres.so"))
(define-module (database postgres))
(define-public (other-parts-of-the-interface-written-in-scheme ....
which only works for interactive sessions. How can I conditionally
execute the '(define-module (guile-user))' appropriately? Or is
there a specific top-level module for non-interactive guile?
there seems to be many module access/init conventions:
(1) call dynamic-call/dynamic-link directly
(2) guile-gtk style
(3) hobbit style
(4) libtool-module style (???)
i've used hobbit style for THUD, fwiw. i think libtool-module style is
going to be the default in the future, but that's from perusing source a
few months ago; perhaps that has changed.
w/ that background, the answer to your question is: it depends. (my
copy of) ice-9/boot-9.scm defines var `registered-modules', although i
notice its value does not change when loading scheme-defined modules;
it's for C-defined modules only. you can either extend this or bypass
it entirely [untested code follows]:
;; machinery
(module-add! the-root-module 'my-modules '())
(module-add! the-root-module 'register-my-module
(lambda (name)
(module-set! the-root-module
'my-modules
(cons (name (current-module))
(module-ref the-root-module
'my-modules)))))
(module-add! the-root-module 'my-module-registered?
(lambda (name)
(assoc name (module-ref the-root-module 'my-modules))))
;; usage
(define-module (my module-1))
(register-my-module '(my module-1))
(or (my-module-registered? '(my module-2))
(define-module (my-module-2)))
;;;;;
however, this is all pre-caffeine advice and on reflection i would
actually recommend against implementing yet another module init/access
convention. something like the above should be integrated w/ the
C-defined module registry; each convention does basically the same
thing so all that code should be factored, not re-re-(re!)-duped.
thi