Recompile fasls when incorrect version

[Robert P. Goldman]

Reported by Didier Verna:

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))))

[Robert P. Goldman (rpgoldman)]

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?

[Robert P. Goldman (rpgoldman)]

Actually, handling all errors as in the default case in the reader macro also seems wrong. Better to fail to handle this than to incorrectly handle miscellaneous errors by recompiling.

[Faré (fahree)]

I propose that we don't even try to fix this bug. There's no way we can get this right in more than a fraction of the cases, at the cost of more, unmaintainable code.

Instead, I invite Didier and others to use the ASDF Output-Translation facility to keep his fasls segregated by implementation version, so that a given implementation will never try to load a previous or otherwise different implementation's fasls.