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

On Fri, Mar 9, 2018 at 5:34 PM, Robert Goldman <rpgoldman@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