Hi Faré,
On 08/12/2012, at 2:23 PM, Faré wrote:
On Fri, Dec 7, 2012 at 7:37 PM, Mark Cox markcox80@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.
No I had not. Adding this method solves the problem that Luis encountered. I have attached a new patch incorporating this method. Thank you for your help.
Let me know if there are any other issues.
Thanks Mark