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 :(
Hmmm, that IS a problem, do we know why? Is make -k sufficient to fix it? (Sorry I can't try building things on this machine so I can only ask the question)
What I mean is that it is acceptable IMO to consider some "mistakes" as "invalid syntax".
Maaaybe, sort of see your point, but not really convinced that uprating warnings to errors is a good idea on the dev codebase, it stops people trying and testing things.
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` ^^
Yep.
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 :)
Of course it should fail the plugin, but as above, not the whole build.
And I hope we use "blame" in the non-emotive sense of "identify the cause of the problem" :-)
Cheers Lex
Cheers, Colomban