getting a handle on build warnings

[Jonathan Gibbons]

On Jul 11, 2008, at 2:29 AM, Volker Simonis wrote:

> On 7/10/08, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
>> The JDK build generates a whole lot of warnings along the way. This  
>> is
>> bad because these warnings can sometimes mask real errors. For a
>> variety of reasons, it appears to be hard to try and get rid of all  
>> the
>> warnings, so this message is about a set of possible ideas to try and
>> get some control over the problem, by providing a relatively general
>> framework to use within the build, to minimize the introduction of  
>> new
>> warnings, and by providing a reporting framework for those developers
>> that *are* interested in reducing the warnings in their code.
>>
>
> This would be nice!
>
>> 1. Collecting warnings.
>>
>> The simplest, easiest way to collect the warnings is to save the  
>> output
>> from
>> a build, for subsequent processing by any new tools we provide.
>>
>> David Herron has also suggested we could prefix the build macros for
>> selected commands like cc, javac, javadoc etc such that the output  
>> from
>> each invocation of the command is appended to a log, perhaps a  
>> directory
>> specific log.  For example, the macro to invoke javac could instead  
>> invoke
>>   savelog -a $(pwd)/javac.log javac ...
>> where savelog is a new command to run a subcommand and save its   
>> output.
>>
>> Whichever way we go, the first step in getting a handle on warnings  
>> would
>> be to save the output from the commands generating the warnings.
>
> I always build with "make jvmg 2>&1 | tee ../../hotspot_c2_debug.log".
> This way I get the whole output produced by the build in the terminal
> window as well as in a log-file.
>
> Perhaps the easiest thing would be to add this feature to a top-level
> Makefile such that it always calls subsequent Makefiles in a way that
> redirects their output to a file (e.g. <OUTPUTDIR>.log).


Yes, that technique can work well. But either way, the next step is
to try writing the code to analyze the build log, to see how far the  
general
idea can be taken, and how much interest there is to track/fix warnings.

-- Jon