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