RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors
David Holmes
david.holmes at oracle.com
Tue Jun 2 09:57:14 UTC 2015
On 2/06/2015 6:58 PM, Magnus Ihse Bursie wrote:
> On 2015-06-01 19:23, Bertrand Delsart wrote:
>> Hi all,
>>
>> A small open webrev to fix some issues around
>> --disable-warnings-as-errors (this is not a full cleanup):
>>
>> http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/
>>
>> Without the fix, -Werror is used to compiled native JDK libraries even
>> when the --disable-warnings-as-errors is used.
>>
>> A lot of these libs are addressed by clearing
>> CFLAGS_WARNINGS_ARE_ERRORS in flags.m4
>>
>> Lib-jdk.sctp.gmk is a special case because it uses directly -Werror.
>> Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the
>> mechanism put in place in that file to disable -Werror and control it
>> through the WARNINGS_AS_ERRORS configured value.
> I think this patch will require some work to be OK.
>
> First of all, I'm not quite sure I understand what problem you are
> trying to solve. What libraries are compiled with -Werror when
> --disable-warnings-as-errors is used? This should not be the case, and I
> cannot reproduce it on my system.
>
> CFLAGS_WARNINGS_ARE_ERRORS should never be cleared, since that is only
> exported as the mechanism to use for enabling warnings as errors. If no
> compilation includes it (which it should not if warnings-as-errors are
> disabled), it won't affect the build. If CFLAGS_WARNINGS_ARE_ERRORS are
> used even though warnings-as-errors are disabled, then it is this usage
> that should be fixed.
AFAICS most uses of CFLAGS_WARNINGS_ARE_ERRORS are unconditional eg:
$(eval $(call SetupNativeCompilation,BUILD_LIBINSTRUMENT, \
LIBRARY := instrument, \
OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
SRC := $(LIBINSTRUMENT_SRC), \
OPTIMIZATION := LOW, \
CFLAGS := $(LIBINSTRUMENT_CFLAGS) $(CFLAGS_WARNINGS_ARE_ERRORS), \
So clearing it is the simplest way to avoid it being applied.
David
-----
> I can see that libsctp is a special case that hard-codes -Werror. But in
> this case we should remove the hard-coding and relying on the system
> setting. This is probably a remnant from before the overall -Werror
> usage, where the authors of a specific lib wanted to enforce a higher
> standard. Also, it might be worth revisiting if
> -Wno-error=unused-parameter is really needed. These things tend to bit-rot.
>
> /Magnus
>
>>
>> Best regards,
>>
>> Bertrand.
>>
>
More information about the build-dev
mailing list