[haiku-commits] Re: haiku: hrev46660 - build/jam src/system/libroot/posix/glibc/stdio-common
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 13 Jan 2014 14:42:48 +0100 (CET)
> 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.
Other related posts:
