Le 12/03/2011 01:51, Lex Trotman a écrit : > On 12 March 2011 11:44, Colomban Wendling <lists....@herbesfolles.org> wrote: >> Le 12/03/2011 01:32, Lex Trotman a écrit : >>> On 12 March 2011 11:23, Colomban Wendling <lists....@herbesfolles.org> >>> wrote: >>>> Le 12/03/2011 01:18, Lex Trotman a écrit : >>>>>>> Maybe some other tests might be good, but I think this is a start. >>>>>> I'd like to commit this to the Autotools build system: >>>>>> >>>>>> 1) run cppcheck on `make check`; >>>>>> 2) enable by default, if compiler understands them, the following >>>>>> warnings (discussed in other mails of this thread): >>>>>> * -Werror=implicit-function-declaration >>>>>> * -Werror=pointer-arith >>>>>> * -Wundef >>>>>> * -Wshadow >>>>>> * -Wwrite-strings >>>>> >>>>> Good start. >>>> Feel free to suggest more :) >>>> >>>>>> There are currently 2 problems that would prevents the tests to pass: >>>>>> 1) The debugger plugin don't compile with >>>>>> -Werror=implicit-function-declaration (this should be fixed -- >>>>>> Alexander, could you fix them please?); >>>>>> 2) cppcheck reports an error on geanylatex plugin; but I know Frank >>>>>> already fixed this and so has probably only to import the fix in the >>>>>> geany-plugins copy. >>>>>> >>>>>> 1 is really problematic since it require one to disable the debugger >>>>>> plugin to be able to compiler the others, >>>>> >>>>> Why do we have to disable the dubugger, sure it gives warnings, but >>>>> for nightly builds and SVN builds thats ok, the disabling only comes >>>>> at release time. >>>> Since I set -W*error=*implicit-function-declaration, the implicit >>>> function declaration warnings are treated as errors and then aborts the >>>> build (unless one uses make -k of course). >>>> >>>> We could downgrade this to a warning, but I think this is a problem >>>> important enough to trigger an error. >>> >>> The general consensus seemed to be to not disable plugins from the >>> nightly builds or SVN just because they fail some tests, so these will >>> have to all be warnings. >> It's a bit more complicated IMO: if these warnings are on by default in >> everyone's build, a code failing with them would just be as invalid as >> an invalid C code (e.g. breaks everyone's build, and isn't acceptable at >> all). > > Well on the development code base warnings should not break the build, > if they do thats another problem :-) ...and invalid C code should neither, but it does :( What I mean is that it is acceptable IMO to consider some "mistakes" as "invalid syntax".
> In fact even errors should also > not break the whole build, just the specific plugin. agreed. But that's a somewhat different point I guess... maybe just tell people to use `make -k` ^^ >> The problem here is that there is currently a plugin that can't be >> compiled with them, so enabling them would mean disabling the plugin >> that used to build. >> >> Maybe the solution is to wait for Alexander to fix these problems, and >> then enable the "errors". >> > > But the next patch commit on any plugin could fail one of the checks, > so then the whole dev build fails again, thats no good, its got to > still build with warnings, its a development build after all. but again, what if I add hello guys! in the middle of the code? Or even more realistic (someone might even understand... :D) if some test { foo_bar(); } In this case, what would you do? Blame the programmer most probably. And you'd be right IMO :) Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel