Hi Faré, On 08/12/2012, at 2:23 PM, Faré wrote:
> 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.
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.
0001-CFFI-GROVEL-now-uses-ASDF-operations-to-compile-and-.patch
Description: Binary data
Let me know if there are any other issues. Thanks Mark
_______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
