Le 12/03/2011 02:37, Lex Trotman a écrit : >>>>> 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. Unfortunately, believe me that non-fatal warnings are use to be ignored by unexperienced programmers, believing that if their code compile it is then OK. And I don't see why a warning upgraded to an error on every build would be worst than a syntactical problem (as I described above previously)? In a typical situation, the developer who writes the plugin should get the warning (well, the error), see his plugin don't build, care (hopefully :D), and then fix it directly even before committing and then before anybody else could face the problem. Don't you think?
>>> 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" :-) Maybe my English knowledge is not good enough, but I meant "beat down to death" :D [1] Cheers, Colomban [1] hopefully the reader will see the humor and understand I actually meant something like "gently ask the programmer to fix the problem"... _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel