Is it time to --enable-warnings?

[Fred Wright]

On Sat, 8 Feb 2025, Hal Murray via devel wrote:

> waf configure --help says:
>      --enable-warnings   Enable annoying CC warnings
>
> Are they really annoying?  My normal build script turns it on without
> problems.

I've certainly seen warnings without that option, so it probably just 
means "enable *more* warnings".

> What does gitlab do with warnings?  Should we be running with -Werror to
> turn warnings into errors so gitlab/CI will notice?  Any reason not to do
> that?

Turing it on in CI builds might be reasonable as a way to get notified 
about warnings.

> ./wafhelpers/check_strerror.py says:
>   # This uses -Werror which may not be portable.
> Has anybody noticed any problems?

Turning on -Werror in general is a really bad idea.  The "nonportability" 
in question is the huge variation across compilers on what produces 
warnings.  There are lots of things which are perfectly legal C code but 
which the compiler may decide to warn about, just in case you *may* have 
done something unintended.  There's no way to predict when that happens, 
so turning on -Werror by default is just a recipe for broken builds.

For example, I just submitted an MR to fix a warning for something which 
is perfectly legal, but which broke the build here due to -Werror.

A less heavy-handed way to make it easier to spot warnings would be to 
implement an option to hide most of the "success chatter", so that the 
warnings don't get buried in a ton of uninteresting output.

Fred Wright