Best Practice for an ASDF Variable Like *compile-file-failure-behaviour*

Faré fahree at gmail.com
Fri Mar 9 23:02:10 UTC 2018


On Fri, Mar 9, 2018 at 5:34 PM, Robert Goldman <rpgoldman at sift.info> wrote:
> Are you just using this for yourself? If so, a simple
>
> (let ((asdf:*compile-file-failure-behaviour* :warn))
>     (asdf:load-system "my system"))
>
> will suffice.
>
Yup.

> Alternatively, you could put something like this in the .asd file:
>
> (defmethod operate :around ((operation load-op) (system (asdf:find-system
> "my-system")))
>    (let ((asdf:*compile-file-failure-behaviour* :warn))
>      (call-next-method)))
>
> The above most emphatically has not been tested, so it might be wrong.
>
As a rule of thumb, you should never define :around methods for
operate, for they do NOT do what you might naively believe they do:
1- they are only called on the top-level system, and/or on systems
loaded directly by a defsystem-depends-on
2- they wrap around not just the system at hand, but all its
transitive dependencies.

The working approach to changing variables for a system, no more no
less, is an :around-compile hook for your system.

But the correct approach is to NOT modify
asdf:*compile-file-failure-behaviour* but instead to catch
specifically the warnings that you want to ignore, using
*uninteresting-conditions* and the with-muffled-compiler-conditions
implicit in compile-file* and thus perform compile-op. See notably the
variable *usual-uninteresting-conditions*.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Intentions are not so much direct descriptions of actual mind processes as
Schelling points in the way social animals communicate.



More information about the asdf-devel mailing list