On 9 Mar 2018, at 17:02, Faré wrote:
On Fri, Mar 9, 2018 at 5:34 PM, Robert Goldman <rpgold...@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
