On Fri, Dec 7, 2012 at 7:37 PM, Mark Cox <markco...@gmail.com> wrote: >> Right, it seems that for some reason ASDF is not picking up >> basix-unixint's compile-time dependency on packages.lisp. Does that >> seem like a plausible (if incomplete) explanation? > > Yes you are correct. The problem can be seen with ASDF::TRAVERSE returning > the wrong plan: > >> (asdf::traverse (make-instance 'asdf:load-op) (asdf:find-system "osicat")) > > ((#<ASDF:LOAD-OP NIL {100793C8D3}> > . #<ASDF:CL-SOURCE-FILE "osicat" "osicat-sys" "osicat-sys">) > (#<ASDF:LOAD-OP NIL {100793C8D3}> . #<ASDF:MODULE "osicat" "osicat-sys">) > (#<CFFI-GROVEL::PROCESS-OP NIL {10076A7263}> > . #<CFFI-GROVEL:GROVEL-FILE "osicat" "posix" "basic-unixint">) > (#<ASDF:LOAD-OP NIL {10077E2133}> > . #<ASDF:CL-SOURCE-FILE "osicat" "posix" "packages">) > (#<ASDF:COMPILE-OP NIL {1007609953}> > . #<CFFI-GROVEL:GROVEL-FILE "osicat" "posix" "basic-unixint">) > .... > > For some reason there exists a PROCESS-OP on "basic-unixint" before the > LOAD-OP on "packages". > Did you define a method on component-depends-on, so that process-op will depend on the load-op?
Something like that might do: (defmethod component-depends-on ((o process-op) (c grovel-file)) `((load-op ,@(component-load-dependencies c)) ,@(call-next-method))) You might even skip the call-next-method. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Don't have good ideas if you aren't willing to be responsible for them. — Alan Perlis _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel