On Wed, Oct 29, 2014 at 11:40 PM, Robert P. Goldman <rpgold...@sift.info> wrote: > #P"/Users/rpg/lisp/asdf/build/fasls/sbcl-1.2.0-macosx-x64/asdf/test/fun-with-undefined-locals.fasl" > > ; file: /Users/rpg/lisp/asdf/test/fun-with-undefined-locals.lisp > ; in: DEFUN FUN-WITH-UNDEFINED-LOCALS-PACKAGE::FOO > ; (+ FUN-WITH-UNDEFINED-LOCALS-PACKAGE::A > FUN-WITH-UNDEFINED-LOCALS-PACKAGE::B) > ; > ; caught WARNING: > ; undefined variable: FUN-WITH-UNDEFINED-LOCALS-PACKAGE::A > ; > ; caught WARNING: > ; undefined variable: FUN-WITH-UNDEFINED-LOCALS-PACKAGE::B > ; > ; compilation unit finished > ; Undefined variables: > ; FUN-WITH-UNDEFINED-LOCALS-PACKAGE::A > FUN-WITH-UNDEFINED-LOCALS-PACKAGE::B > ; caught 2 WARNING conditions > ; > ; compilation unit aborted > ; caught 2 fatal ERROR conditions > Expected error type: COMPILE-FAILED-ERROR > Script succeeded > Using sbcl, test-deferred-warnings.script passed > > > How do you distinguish between the build failing and succeeding but > being followed by an error signal? > Nothing in ASDF should cause an error signal at the end of the W-C-U. You're discussing the behavior of a file that isn't checked in; does it have interesting handler-bind's? Does your SBCL and/or some configuration file include some interesting patch with respect to W-C-U and/or compile conditions? (Which version of SBCL is it?) I don't understand what's going on for you.
>> On the other hand, differences between compilers easily explain >> variations between condition reported by ASDF, since they depend both >> on what conditions the compiler reports, that are not portable, and on >> the *compile-file-warnings-behaviour* and >> *compile-file-failure-behaviour* values, that are also unportable. >> Note that unless you :force t, non-fatal warnings can disappear the >> second time around. > > It is the "not portable" part of this that makes it seem like a > maintenance nightmare, and not ASDF's job. If SBCL wants to signal > warnings at oddball times, that's too bad, but I don't see that it's > ASDF's job to fix that. We have to leave some fun for the SBCL > maintainers ;-) > ASDF is a portability layer. It has to handle some non-portability in underlying implementations and provide portable abstractions. In this case, how to interpret the return values of COMPILE-FILE is de facto non-portable, with different implementations having wildly different interpretations of the CLHS regarding secondary values. ASDF thus provides the variables *compile-file-warnings-behaviour* and *compile-file-failure-behaviour* to interpret the warnings-p and failure-p return values of compile-file. It is *already* a nightmare, and ASDF has been *solving* that nightmare for a decade. Thanks, danb. As for fine control of compiler conditions, ASDF doesn't do it, but it provides hooks in the form of uninteresting-conditions and compiler-hook. A colleague has written a portability layer for compiler conditions. I'm hoping he will clean it up and opensource it at some point. >> NB: Back when I first pre-released ASDF3, I wanted to enable >> deferred-warnings by default, but this turned out to be a >> community-wide coordination nightmare, and I had to bail out. If >> someone wants to make it happen, he'll have to make sure that it >> doesn't break quicklisp and then still have to convince the community >> and the ASDF maintainer that the change is worth it and that enough >> publicity is made that random users don't get badly surprised. > > My experience with the deferred warnings on Allegro left me deeply > dissatisfied. ACL seems to deal with deferring warnings to the right > place simply through use of WITH-COMPILATION-UNIT. In particular, it > correctly waits on UNDEFINED-FUNCTION warnings until the whole > compilation unit has been processed, yet I don't recall delays in seeing > UNDEFINED-VARIABLE references (I should check to confirm this, but I > feel sure I would have noticed if undefined lexical variable warnings > were deferred till the end of the build). > One reason why I didn't include a test for undefined-variable behavior in the existing ASDF3 test/test-deferred-warnings.script is precisely that the way this is treated is highly implentation-dependent, and I didn't have the time and energy to track down the behavior on 16 implementations and figure out a portability layer or at least a conditional test. > This suggested some conjectures: > > 1. AFAICT, using ASDF's deferred-warnings would have required first > breaking the logic that ACL already provides, and then recreating it in > ASDF. > No. It doesn't require anything but suitable defaults. It might "just" be that check-deferred-warnings needs be made more clever, and/or might need to have its own separate variants of *compile-file-warnings-behaviour* and *compile-file-failure-behaviour*, and maybe also *compile-check*. > 2. If ACL can handle this sensibly w/o requiring any outside assistance > from ASDF, then I don't believe that this should be ASDF's job. > By definition, it's ASDF's job to put the correct W-C-U, and to emulate a system-wide W-C-U when warnings were deferred in a previous session (i.e. file "a" was previously compiled with deferred warnings, and least we forgo all intra-system incrementality, we don't want to recompile it). The implementation just can't make that stuff up out of thin air. Hopefully, we don't have to write clever handler-bind's as part of ASDF itself, but there's a possibility we might, and indeed someone should look at the undefined-variable behavior on each and every of the 16 implementations. > 3. The job of deferring warnings properly seems to involve thinking > hard about which warnings should and should not be deferred. That's > something that the implementation's maintainers will always be able to > do better than we can, since the condition classes are poorly > standardized. > No. The implementation is already doing the deferring or not. ASDF's job is just to capture the relevant warnings, and either (1) effectively discard them, which it currently does with its W-C-U, unless some implementations convert them to errors at the end of W-C-U and that's a huge incrementality and portability issue that needs be solved or (2) replay them deterministically at the end of the system's compilation, which ASDF does when you enable-deferred-warnings-check. > 4. It seems like the implementation needs to think carefully about how > to defer warnings in WITH-COMPILATION-UNIT anyway. > No. We only need worry if some implementations convert warnings to errors at the end of W-C-U, in which case it becomes much more important to implement and deploy deferred-warnings. > I believe that you had a reason that you disliked W-C-U, but I'm afraid > I would have to go back and recover that argument. > I hope the above explanations help. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Sure, we must render unto Caesar what is due to Caesar. But what is that? Any and all specie he coined that we possess, or 23 stab wounds? _______________________________________________ Asdf-devel mailing list Asdf-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
