When there are nested COMPILE-FILE calls, we --since forever--
propagate failures to the outermost COMPILE-FILE call. I used to
believe this was correct, but now I'm getting doubts, and I cannot
seem to find a place in the spec that _requires_ this behaviour. We
are also not quite consistent in the propagation.
>From a practical point of view, consider this:
;; good.lisp
(eval-when (:compile-toplevel)
;; Compiling bad.lisp fails
(multiple-value-bind (fasl warn fail) (compile-file "bad.lisp")
(declare (ignore warn))
(if fail
(error "Compiling bad.lisp failed!")
(load fasl))))
(defun good () 42)
If compiling bad.lisp causes a full WARNING, eg.:
(defun bad () (nil))
it is percolated to compilation of good.lisp and the (COMPILE-FILE
"bad.lisp") returns a tertiary value of NIL -- and bad.fasl is loaded!
If bad.lisp on the other hand causes a bona fide ERROR, eg.:
((bogus))
then the (COMPILE-FILE "bad.lisp") returns a tertiary value of T.
In the very least both of these should behave identically.
Moreover percolating the error upwards serves no purpose that I can
see -- it only subverts the tertiary return value of COMPILE-FILE.
If *both* calls returned a tertiary value of T, that would seem
somewhat better to me, but even that only seems to make life harder
when there are nested COMPILE-FILE calls.
Any thoughts on this?
Cheers,
-- Nikodemus
|