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

[Joe Darcy]

On 12/22/2011 3:52 AM, Alan Bateman wrote:
> On 22/12/2011 01:51, Stuart Marks wrote:
>>
>> I dug up a bit of background on this. Apparently Sasha ran across 
>> this problem back in July and asked about this on net-dev [1]. 
>> Discussion continued on build-dev [2]. Kurchi later picked up this 
>> work and after some discussion got it integrated [3].
>>
>> I didn't see Sasha's original webrev, but he might have fixed all the 
>> warnings in the java.net package, enabled -Werror in 
>> make/java/net/Makefile, and then was surprised to find that this 
>> build step was (implicitly) compiling files that weren't in the 
>> java.net package. Kurchi's fix [3] apparently fixed warnings in these 
>> other files as well before enabling -Werror.
>>
>> In my proposal to add -Werror, I've ensured that specific runs of 
>> javac to which -Werror will be added actually have no warnings at 
>> all, whether in implicitly or explicitly listed files.
>>
>> I'm also not entirely clear what's meant by "partial" and 
>> "incremental" builds. I've been doing clean builds, but only in the 
>> jdk repo. Is this a "partial" build, as opposed to a full forest or 
>> "control" build? I'm doing one of those now and I'll certainly 
>> correct any issues that arise because of -Werror.
>>
>> Or, is a "partial" build what happens if one descends into a make 
>> subdirectory, e.g. jdk/make/java/net, and calls "make" from there? I 
>> haven't been doing that. Should I?
>>
>> Still trying to figure out what I need to do to move this forward.
> Just on terminology, when I use the term "partial" build then I meant 
> building a subset of the repositories with an import JDK providing the 
> per-built bits from the other repositories. I think this is what most 
> folks working in the jdk repository do, at least in Oracle. 
> Incremental builds are where folks go into specific directories and 
> run the make file so that it re-builds just the changed sources for 
> that area. It's far from perfect, requires local knowledge, at least 
> one amulet, but critical to productivity when working in the jdk 
> repository.
>
> Anyway, I think you've been digging in the right place. Warnings were 
> fixed and builds completed successfully but then later we found cases 
> where areas hadn't been completely cleared of mines. This is not a 
> criticism of Sasha's great work, it's just that they slipped through 
> because classes were compiled implicitly by something earlier in the 
> build. This is just one reason to look forward to the new build.
>
> As to moving this forward. If you are happy that these areas are 
> completely warning free then I think we are happy and you should push 
> the changes.
>

As an aside, I've thought it was a bit of design error that implicit 
compilation was the default.

Since JDK 6 there has been a javac option that can be used to disable 
implicit compilation, -implicit:none.

Perhaps this option could be used in some portion of the JDK build.

-Joe