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)
(f)
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*
#P"c:/Users/anton/projects/cl-test-grid2/work/warntest.wx64fsl"
T
T
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
_______________________________________________
asdf-devel mailing list
[email protected]
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
