[asdf-devel] Failures due to deferred warnings

Anton Vodonosov avodonosov at yandex.ru
Thu Feb 21 18:30:59 UTC 2013

I want to say do not really support chaning the warinings handling. For two reasons:

1. I don't see how it can be introduced smoothly. Faré, you did significant piece of work
    by contacting all the maintainers, and it will take more work to track their responses.
    Somebody will not respond, because the systems are not developed for several years,
    somebeody will report the undefined variable if fixed, but when we try we will find next undefined variable.
    Warnings are not always trivial to fix. It's not utf-8 where author can just set the :encoding attribute.
    Fixing warning involves changing code, analyzing how variables for functions are used,
    is it possible to reorder definitions, and so on. Also it may result in new bugs.
    So I am affraid it will take half a year to push the fixes and it's work for you and for the maintainers.

    Changing the warning rules without fixing the affected systems is not an option at all IMHO.
    This CL codebase we inherit is a valueable asset, we should direct efforts to preservig it functioning,
    but not breaking. If we want to direct evolution of CL into some more robust direction, it's better to
    find a way without rejecting previous work.

2. I do not really understand the change in warning handling. Of course, this point doesn't mean the
   changes are wrong, and it's all in my hands to study the subject. But untill I get the understanding
   I can't support this feature.

   Faré, you said that the change introduces (with-compilation-unit (:override t) ... )
   around compilation of every file, and the warnings reported by this with-compilation-unit
   are saved and may result in compilation failure. In the previous ASDF there was only
   one with-compilation-unit around whole ASDF system - this big with-compilation-unit
   remains in new ASDF too.

   Do I describe it right?

   Why it is better? Do we catch more warnings or why?
   What are the use-cases when new warnings behaviour make life better?

   And in general, warnings handling. I created a file warntest.lisp with this content:

      (defun f () *my-var*)
      (defparameter *my-var* 1)

  On both CCL and SBCL, (compile-file "warntest.lisp") returns the following:

      ;Compiler warnings for "c:/Users/anton/projects/cl-test-grid2/work/warntest.lisp" :
      ;   In F: Undeclared free variable *MY-VAR*

  Recall that CLHS calls the 3 values returned output-truename, warnings-p, failure-p.
  So failure-p is T. Is this program non-conforming? Does it violate CLHS?

  As far as I understand, this program is correct.

  I creted also a wartest.asd and included wartest.lisp into this ASDF system.
  Old ASDF performs load-op without error on this system. I am satisfied with
  this behaviour. Will new ASDF fail this system?

  I must say the warnings are very useful. When I work in SLIME they help
  me all the time. But failing asdf:load-op on warnings by default is not good IMHO.
  Warnigs are hints for developer.

  If develper wants to be very clean, he should be able to enable for his code
  a mode when warnings fail compilation.
  But taking into account that different compilers produce different warnings,
  this mode should not be enabled when system is delivered to other people.
  Moreover, new versions of the same compiler can introduce new warnings.

  I experienced such problem with big C programs, where build scripts enforce warning
  free compilation. But since then gcc introduced many new warnings, so when
  I wanted to rebuild the system myself there were hunderds of warnings.
  It was unpleasant suprsie. I hoped to just "configure; make; make install", 
  but in result abandoned the program at all.

  Therefore, I think it's better to use warning-clean mode only on the developer machine.

Faré, I can help you with testing with warning, without warnings, as you want. 
But so far I don't see a win of the new warnings handling.

Best regards,
- Anton 

More information about the asdf-devel mailing list