On Jul 11, 2008, at 2:29 AM, Volker Simonis wrote:
On 7/10/08, Jonathan Gibbons <[EMAIL PROTECTED]> 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
