Build portability: enable or disable warnings

[Kelly O'Hair]

Be careful here, it actually can be very costly, and sometimes risky to fix the warnings.
You could argue that it's worth the cost, but unless you force developers to keep the warnings
at bay by using something like -Werror, many will ignore warnings, and then they just accumulate,
like much of the jdk native code (non-hotspot code).

There is also the issue of developers deciding that the warnings are bogus or silly, and adding
options to the compile line to not generate those warnings instead of going all out to make the
compiler happy when they disagree with it.
In some rare cases that might be warranted, but it's a slippery slope that needs to be dealt with
carefully.

I suspect that if you added -Wall -Werror to all the native compiles of the entire jdk,
the changes would be in the hundreds of lines to get it to build successfully, maybe thousands. :^(

And that is just gcc/g++, once you make all these changes, you need to look at Windows and
Visual Studio 2010, and Solaris and the Studio compilers.
Sometimes these compilers are at odds on the recommended fixes for warnings, fixing one
may generate another. It can be frustrating.

I'm certainly not arguing we should not do this, just trying to make sure people's eyes are wide
open when they do try.

-kto

On May 16, 2011, at 9:50 AM, Dmitry Samersoff wrote:

> Andrew,
> 
> I guess we can add to build system something like
> 
> ALT_COMPILER_FLAGS
> 
> and turn on all warnings and -Werror by default.
> 
> Having zero-warning build is good practice and it's not too costly.
> 
> -Dmitry
> 
> On 2011-05-16 19:56, Andrew Haley wrote:
>> On 05/16/2011 04:35 PM, Kelly O'Hair wrote:
>>> 
>>> On May 16, 2011, at 7:23 AM, Dr Andrew John Hughes wrote:
>>> 
>>>> I think the issue is actually having -Werror enabled for all builds, not
>>>> just debug builds.  Without that, these additional warnings would just be
>>>> noise.  Having -Werror on also causes problems just upgrading the version
>>>> of gcc, regardless of distro-specific patching, as new warnings are
>>>> introduced or old ones reclassified.
>>> 
>>> The code being compiled is different with debug vs. product builds
>>> due to assert logic, so I consider it important that all builds use
>>> -Werror if they use it at all.
>>> 
>>> The -Werror option is a blessing and a curse. I find it highly
>>> commendable that teams (like hotspot) have taken a 'no warnings
>>> allowed' approach to their code base, more teams should do this.
>>> Given the critical nature of a VM in the JDK, it only makes sense to
>>> take all precautions in verifying the code is correct.
>>> 
>>> But it only makes 100% sense when using the same compiler, same
>>> compiler version, and on the same system.  For hotspot, you should
>>> be able to get rid of -Werror by setting WARNINGS_ARE_ERRORS to
>>> empty.
>> 
>> The core problem here, I think, is that some warnings really would be
>> hard errors by any reasonable measure, so you have to use -Werror.
>> The example that tripped us up this time was totally innocuous,
>> though.
>> 
>> Andrew.
> 
> 
> -- 
> Dmitry Samersoff
> Java Hotspot development team, SPB04
> * There will come soft rains ...