[asdf-devel] ASDF 2 questions

[Robert Goldman]

On 9/30/10 Sep 30 -1:05 PM, Didier Verna wrote:
> Faré <fahree at gmail.com> wrote:
> 
>>> 5/ Finally, I would like confirmation that ASDF now handles outdated
>>>   fasl's correctly, and we don't need to do the black magick
>>> ourselves.
>>>
>> I'm not sure what you mean, so I'd say probably not. If you have
>> "black magick" that you think should be part of ASDF, please submit it
>> here, and/or as an ASDF bug on launchpad.
> 
>   Sorry for being too vague. For ASDF 1, I had a plug to automatically
> recompile outdated fasls (I probably found it on the internet years ago;
> don't remember):
> 
>         (defmethod asdf:perform :around
> 	    ((o asdf:load-op) (c asdf:cl-source-file))
> 	  (handler-case (call-next-method o c)
> 	    (#+sbcl sb-ext:invalid-fasl
> 		    #+cmu ext:invalid-fasl
> 		    #+allegro excl::file-incompatible-fasl-error
> 		    #+lispworks conditions:fasl-error
> 		    #-(or sbcl cmu allegro lispworks) error
> 		    ()
> 		    (asdf:perform (make-instance 'asdf:compile-op) c)
> 		    (call-next-method))))
> 
> ... and I was wondering if ASDF 2 did something like this on its own.

I'd love to see a version of this patch installed in ASDF2.

In its present form it seems a little yucky.  Ideally, it seems to me,
the OPERATION-DONE-P test for the COMPILE-OP should fail on an
incompatible fasl.  That's a lot cleaner than the solution that involves
a direct outside call to PERFORM, which really breaches the API.  This
leads to a potential for error.  For example, I'm pretty sure that the
the ASDF:COMPILE-OP instance here is not built correctly --- it should
be inheriting its initargs from the top-level operation instance, which
is the way things are normally done in ASDF.

That said, I do not know how to probe a file to test whether it has a
compatible FASL type, aside from trying to load it.  Anyone know if this
is possible?