On 9/30/10 Sep 30 -1:05 PM, Didier Verna wrote:
Faré fahree@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?