getting a handle on build warnings

[Volker Simonis]

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).