[Gbbopen-list] Loading GBBopen open using asdf

[Clayton Morrison]

Sorry to belabor the point, but I'm still having a little trouble --  
but this might be due to not fully groking asdf.  I'm trying your  
third suggestion: Here is the file of the system I'm defining (in  
case the context is causing trouble):

(in-package :cl-user)

;;;  
------------------------------------------------------------------------ 
---

(defpackage #:asdf-lbn-system (:use #:asdf #:cl))
(in-package #:asdf-lbn-system)

;;;  
------------------------------------------------------------------------ 
---

;; Use jLinker
(require :jlinker)

;;;  
------------------------------------------------------------------------ 
---

(defsystem :lbn
     :depends-on (:lbn-package :lbn-src))

(defsystem :lbn-package
     :depends-on (:gbbopen)
     :components
     ((:system :gbbopen
       :components ((:system :agenda-shell-user)))
      (:module "dev"
       :serial t
       :components ((:file "package") (:file "logical-pathnames")))))

(defsystem :lbn-src
     :depends-on (:lbn-package)
     :components
     ((:module "dev"
       :serial t
       :components ((:file "hello-java") ))))

My strategy here is to conceptually separate the package loading from  
the lbn source, but have a top-level :lbn system that I can call.   
The lbn package uses gbbopen, so I want the gbbopen package to exist  
by the time I'm doing the package definition.  So I have made :lbn- 
package depend on :gbbopen, and as per your last example, added  
the :gbbopen system as a component (with the agenda-shell-user  
component) of :lbn-package.  But the agenda-shell-user system is not  
being loaded before the lbn package def, so the gbbopen package can't  
be used by the lbn package.

I also tried your second suggestion and that works fine:

(in-package :cl-user)

(require :asdf)

(asdf:operate 'asdf:load-op :gbbopen)

(asdf:defsystem :mysys
   :depends-on (:agenda-shell-user)
   :components
   ((:module "dev"
     :serial t
     :components ((:file "package")
		 (:file "logical-pathnames")
		 (:file "hello-java")))))

I can live with this because the first (asdf:operate 'asdf:load- 
op :gbbopen) only defines the gbbopen systems (via the mini-module).

I did, however, find one small issue with this latter approach: when  
compiling gbbopen on my system, the directory darwin-allegro-m-8.1/  
is created in the GBBopen root directory and all of the fasls live  
under it (in respective subdirectories), but if I'm compiling gbbopen  
for the first time while loading :mysys, then I get the continuable  
error that the mini-module directory does not yet exist -- one of the  
continuations creates this and any other missing directories; once I  
select that continuation, everything completes and loads fine.  I  
don't get this error when I load manually:

(load "/Users/clayton/repository/bootstrap-learning/lisp/GBBopen/ 
startup.lisp")
(mini-module:compile-module :gbbopen-test :propagate :create-dirs)

presumably because of the :create-dirs directive.

Sorry if this is getting obtuse -- is what I'm doing non-standard?   
Thanks for you help,

-Clay

On Aug 11, 2007, at 9:47 AM, Dan Corkill wrote:

> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://GBBopen.org/pipermail/gbbopen-list/attachments/20070811/ba58211b/attachment-0001.html