The code in question is
(multiple-value-bind (output warnings-p failure-p) (apply #'compile-file source-file :output-file output-file (compile-op-flags operation)) (when warnings-p (case (operation-on-warnings operation) (:warn (warn "~@<COMPILE-FILE warned while performing ~A on ~A.~:>" operation c)) (:error (error 'compile-warned :component c :operation operation)) (:ignore nil))) (when failure-p (case (operation-on-failure operation) (:warn (warn "~@<COMPILE-FILE failed while performing ~A on ~A.~:>" operation c)) (:error (error 'compile-failed :component c :operation operation)) (:ignore nil))) (unless output (error 'compile-error :component c :operation operation)))
I don't like that behaviour at all for the following reasons:
a) WARNINGS-P is T even if only a style-warning is signaled.
OPERATION-ON-WARNINGS is :WARN by default, so a style-warning results in a gratuitous "COMPILE-FILE warned" message.
b) If COMPILE-FILE warned, FAILURE-P is T.
This means if a warning during compilation is signaled, ASDF will display a "COMPILE-FILE failed" message -- which is technically correct, but only for some obtusive meaning of "failed".
I'd rather have something like Slime's compilation statistics:
The operation #<COMPILE-OP ...> on #<CL-SOURCE-FILE ...> resulted in N1 style-warnings, N2 warnings, N3 non-fatal errors and 1 fatal error. # iff OUTPUT == NIL The operation failed at creating a fasl file. Aborting.. <..entering debuger..>
Or
The operation #<COMPILE-OP ...> on #<CL-SOURCE-FILE ...> resulted in N1 style-warnings, N2 warnings, N3 non-fatal errors The operation succeeded at creating a fasl file.
Suggestions?
-T.
"Tobias C. Rittweiler" tcr@freebits.de writes:
I don't like that behaviour at all for the following reasons:
I do. (Not that I have a vote, but I think there is some value in binary tools, which fail hard when things go wrong). Also possibly relevant is the fact that some of my systems use the current interface, in order to break early when something regresses; it may not be the best interface, nor expose the most information possible, but it's used: so please don't change the interface incompatibly.
In particular, I think that your characterization of failurep from compile-file being treated as a failure as "obtusive" is not helpful.
Cheers,
Christophe
Christophe Rhodes writes:
"Tobias C. Rittweiler" tcr@freebits.de writes:
I don't like that behaviour at all for the following reasons:
I do. (Not that I have a vote, but I think there is some value in binary tools, which fail hard when things go wrong). Also possibly relevant is the fact that some of my systems use the current interface, in order to break early when something regresses; it may not be the best interface, nor expose the most information possible, but it's used: so please don't change the interface incompatibly.
In particular, I think that your characterization of failurep from compile-file being treated as a failure as "obtusive" is not helpful.
My posting refered to the _diagnostics_ that is output, and not to the aborting behaviour.
What information do you currently deduce from "COMPILE-FILE warned ...", and "COMPILE-FILE failed" messages?
My point is that the information that at the moment must be deduced, can hopefully be reported more efficiently.
-T.
"Tobias C. Rittweiler" tcr@freebits.de writes:
In particular, I think that your characterization of failurep from compile-file being treated as a failure as "obtusive" is not helpful.
My posting refered to the _diagnostics_ that is output, and not to the aborting behaviour.
What information do you currently deduce from "COMPILE-FILE warned ...", and "COMPILE-FILE failed" messages?
Oh, right, sorry. No objection to adding information to the :warn cases. (I use the :error case extensively to control regressions)
Cheers,
Christophe
-
Christophe Rhodes -
Tobias C. Rittweiler