[Gbbopen-list] Loading GBBopen open using asdf
Dan Corkill
corkill at gbbopen.org
Sat Aug 11 12:47:33 EDT 2007
I'm moving this over to the GBBopen user list, as this discussion may be
helpful to others...
> I did see that gbbopen.asd is like a "wrapper" for the
> gbbopen mini-module fns. I'm trying the asdf route for GBBopen just to
> be uniform and "asdf-like" with my other asdf systems, so that I can
> just put :gbbopen in my depends-on list. Also, in my setup it makes a
> more "uniform" interface to systems because I have asdf register all
> systems in a sandbox, then I can load them without having to
> individually specify paths.
>
> My output looks like this (alo is just a shortcut for
> (asdf:operate 'asdf:load-op <name>)):
>
> cl-user> (alo :gbbopen)
> ; loading system definition from
> ...
> ; registering #<system :gbbopen @ #x106cfa22> as gbbopen
> ; registering #<system :mini-module @ #x106ed312> as mini-module
> ; registering #<system :gbbopen-tools @ #x1070dfa2> as gbbopen-tools
> ...
> ; registering #<system :http-test @ #x10722cda> as http-test
> ; registering #<system :agenda-shell-test @ #x1074312a> as
> ; agenda-shell-test
> ; registering #<system :compile-gbbopen @ #x10764102> as compile-gbbopen
> nil
> cl-user>
>
> After this, the gbbopen package doesn't exist and it looks like only
> registration of the systems took place. Is that expected? Is there a
> way through the gbbopen asdf interface to compile the system(s) if their
> fasl's are out of date?
The :gbbopen "system" defined in gbbopen.asd is, as you guessed, only
the ASDF registrations of the GBBopen modules (loaded as "in memory"
ASDF systems). There's not really a single combinations of GBBopen
modules that is "GBBopen" (maybe :agenda-shell-user comes closest). To
actually compile/load a desired GBBopen module via ASDF, a second
asdf:operate is required (for reasons to be explained shortly). So, if
you were doing this in the REPL (using your aol), you would need to do:
> (alo :gbbopen) ; to load the GBBopen module registrations
followed by:
> (alo :agenda-shell-user) ; for example, if that is the desired
; GBBopen module
If you are defining your own mysys.asd definition, it could look like:
> (in-package :cl-user)
>
> (require :asdf)
>
> (asdf:operate 'asdf:load-op :gbbopen)
>
> (asdf:defsystem mysys
> :depends-on (:agenda-shell-user)
> ...
> )
Again, the first asdf:operate loads the registrations and the second the
:agenda-shell-user module. The above asdf-system definition can be
improved, so that both activities happen as dependencies of mysys (and
are only loaded into CL if mysys is loaded):
> (in-package :cl-user)
>
> (require :asdf)
>
> (asdf:defsystem mysys
> :depends-on (:gbbopen)
> :components ((:system :gbbopen
> :components ((:system :agenda-shell-user)))
> ...
> ))
Then your (alo :mysys) will operate as you are expecting.
We could have taken the approach of having *.asd files for each of the
typical GBBopen module combinations, but having more than one *.asd file
for all of GBBopen just seemed needless and messy to maintain. The one
gbbopen.asd is essentially a bootstrapping mechanism for all the GBBopen
modules.
I need to get this information added to the Reference Manual (!)...
-- Dan
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the Gbbopen-list
mailing list