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