> On January 13, 2014 at 2:14 PM Jonathan Schleifer > <js-haiku-commits@xxxxxxxxxxx> wrote: > You could define them per component of course. Just treating all warnings as > errors can often > break things through a simple compiler upgrade. While for GCC, we currently > enforce the GCC we > bundle, we should not do that for Clang, as it's always a cross-compiler that > supports Haiku > and takes quite long to build. Thus we should only check that the installed > Clang has a certain > minimum version (which would be 3.2 at the moment). That we cannot require a specific version of clang to use for building is indeed a very important limitation. I'm also not sure it's a good idea as compilers tend to introduce new optimizations that do not work correctly in all cases, or in other words, the same applies to -O2 vs. specifying all optimizations manually. Both cases are problematic without a specific release to target, though, as the number and names of warnings and optimizations change between releases. If clang manages to maintain compatibility for those, we would only ever need a minimum release requirement, though. In any case: useful warnings should always break the build, useless warnings should not be visible. 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. It's okay if new compiler releases break the build if the warnings that trigger the issue improve the code quality. If not, the new warning should be turned off completely. If you go the other way around, as you suggest, you'll never (well, rarely, on manual intervention only) benefit from new warnings a new compiler release has to offer. And that's why it also makes sense to require a specific compiler release to build Haiku, even for clang. However, for the latter, we might want to add an option to turn new warnings into actual warnings to be able to work with newer compiler releases without too much hassle (in general, I think updating the build files for each and every new compiler release sounds quite manageable). Turning off -Werror on a per component basis is not ideal either, but is kind of a reality clash we have to accept at least as a temporary work-around due to man power. An additional clang mode there would only make sense if clang offers a lot of useful warnings we do not want to hide in general, and that would cause a lot of work to fix for every component. Otherwise it would needlessly clutter the Jamfiles. An alternative way would be a single Clang build file that does that per component, ideally turning off only the warnings that are problematic. The same could be done for GCC, so that we would have all problems listed in a single file, which would make it easier to follow the aim to keep those files empty. Bye, Axel.