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

[Robert Goldman]

On 9 Mar 2018, at 17:02, Faré wrote:

> 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*.
>

This is a very good point.  What the OP asks for is actually the thing 
that you (I believe correctly) say they should not want: "...wrap around 
not just the system at hand, but all its transitive dependencies."

That's hard to do in a generally reliable way, because the author of the 
system definition has no way to tell whether the

In general, it's a Bad Idea to ignore warnings in this way.  Almost 
always the warnings you ignore will eventually come back to bite you.  
Even if they do not do so directly, the next time you introduce a bug 
that causes a warning, you won't see it because ASDF is not breaking 
when it should.

Not just in CL, but *everywhere*, it's good practice to require your 
systems to build cleanly, without warnings.

In fact, I'd say the only time when you want to ignore warnings is when 
you have someone else's library, they have done something that is wrong, 
but that you know will not cause an error, and you don't have a good way 
to get the upstream system fixed.  In that case, as Faré says, the 
right thing is to wrap *only that system* in a targeted muffling of 
warnings.

So, I think my around method solution is what you asked for, but Faré 
is right: you should think very hard about whether what you asked for is 
actually what you need.

Cheers,
r
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20180309/00c47b5a/attachment.html>