please review 7122061: enable -Werror in various jdk build steps

Stuart Marks stuart.marks at oracle.com
Wed Dec 21 02:10:37 UTC 2011


On 12/15/11 9:23 PM, David Holmes wrote:
> On 16/12/2011 12:59 PM, Stuart Marks wrote:
>> http://cr.openjdk.java.net/~smarks/reviews/7122061/webrev.0/
>
> Looks fine but ...
>
>> This defines the JAVAC_MAX_WARNINGS and JAVAC_WARNINGS_FATAL variables
>> in a variety of Makefiles within the jdk repository. This essentially
>> adds -Xlint:all -Werror to the javac command lines, so that henceforth
>> if any lint warnings are introduced, the build will fail.
>>
>> I'm applying these flags only to build steps that are already warnings
>> free. (Last week's warnings cleanup effort cleared warnings from four
>> build steps, in addition to knocking off a couple thousand warnings
>> across the build.) I've applied this change and have built successfully
>> on all platforms.
>>
>> With this change, 57 of the 93 javac build steps in the jdk repo are now
>> lint warning free, and are protected from the introduction of new errors
>> through the use of -Werror.
>
> ... as we're past the half-way point should we not set these by default and
> change the non-warning free steps to override them? That way as an area becomes
> warning free we would include the removal of the override as part of the
> changeset. That way when we get to being warning-free there should only be one
> occurrence of:
>
> JAVAC_MAX_WARNINGS = true
> JAVAC_WARNINGS_FATAL = true
>
> in the whole build system.

Yes, I think this is a good thing to consider. I had thought about this a bit 
and felt that it would be more appropriate to make a change after all (or at 
least almost all) the warnings had been cleaned up, not just the majority, 
though when we should make such a change deserves discussion. Jon Gibbons also 
pointed out that we should coordinate with the new build system effort on 
build-infra.

It's also a small puzzle to figure out the best way to do this without doing 
too much damage to the current makefile system. I think we now know how much 
damage even an innocuous change to a makefile can do. :-)

That said, here's a possible approach.

The current scheme has the leaf Makefile define these JAVAC_ variables *before* 
inclusion of make/common/Defs.gmk. This file ends up including 
make/common/shared/Defs-java.gmk, which tests these variables and adds options 
like -Xlint:all and -Werror if they equal true.

Unfortunately in this scheme it's not possible to supply a default value for a 
variable that's overridden by the leaf Makefile, since the leaf Makefile is 
read first.

There's an alternate approach that has a similar effect, which is to use the 
make construct ?= that means "set if not already set." Thus, in Defs-java.gmk 
we can do something like

     JAVAC_WARNINGS_FATAL ?= true
     ifeq ($(JAVAC_WARNINGS_FATAL), true)
         JAVACFLAGS += -Werror
     endif

and any leaf Makefile that doesn't want warnings to be fatal does

     JAVAC_WARNINGS_FATAL = false

prior to including Defs.gmk. I think this will work, but I haven't tested it. I 
don't think this construct has been used anywhere in the make system yet, though.

The alternative is to invert the sense of the test and rename the variable, so 
the leaf Makefiles would do this:

     JAVAC_WARNINGS_NONFATAL = true

and Defs-java.gmk would do this:

     ifneq ($(JAVAC_WARNINGS_NONFATAL), true)
         JAVACFLAGS += -Werror
     endif

This uses more conventional Make constructs, at the expense of having the 
double negative "if not non-fatal, add the -Werror option." I'm not sure which 
approach people would find preferable.

In any case there are other issues with -Werror raised elsewhere in this 
thread, which I'll need to address before proceeding with this.

s'marks



More information about the build-dev mailing list