On 9/30/10 Sep 30 -1:05 PM, Didier Verna wrote: > Faré <[email protected]> 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? _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
