>>>> 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 > _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel