On 01/13/2014 03:03 PM, Jonathan Schleifer wrote:
Am 13.01.2014 um 14:42 schrieb Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:Having useful warnings only visible never gets them fixed, or at most from time to time if someone thinks it's about time to go through that list again. Forcing each developer to fix their own problems works much better in practice. It also is just one other method to improve the overall code quality.Well, it helps fixing them over time. Fixing them all at once is a task we cannot accomplish for Haiku.
This discussion is getting a bit tedious, since you seem intent on ignoring the approach I suggested in my first mail. So once more:
1. Add an optional parameter (a build feature specification) to EnableWerror that allows us to disable the warnings for clang.
2. Disable -Werror for clang for every component.3. (Over time) Component by component fix all clang warnings and enable -Werror.
This is basically the same approach we have used for introducing -Werror in the first place. As you can see, it has allowed us to clear the (gcc) warnings for a substantial part of the code base already. So it has been proven to work for us.
As I and again Axel have tried to explain, iteratively enabling -Werror for warning types for the whole code base, as you suggest, is very likely not going to work for us.
CU, Ingo
