[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