This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Improving C++ error output?
On Fri, Dec 20, 2002 at 03:16:01PM -0800, Randy.Dunlap wrote:
> I'm interested in this thread because OSDL is building each new Linux
> kernel release and checking for (many) warnings and errors.
> (There is some early sample output at:
> http://www.osdl.org/archive/cherry/stability/2.5.52.results/
> )
>
> We could stand to see more consistency in warning and error messages,
> unless things like (above:) -fmessage-length=0 will help out.
> I'll try that now.
> Multi-line messages can also be a problem for post-processing/automation.
>
> Any hints or clues on how to do this consistently and successfully?
One of the projects that I am involved with (The ACE ORB, TAO), has
a set of Perl scripts which checks out the TAO source code every day,
builds it, and parses the build output for any errors:
http://tao.doc.wustl.edu/scoreboard/
The code which parses the build output was cobbled together over time
and consists of a lot of if/switch type statements and Perl regular
expression parsing code. It does a decent job of catching most
gcc and linker error messages. The TAO autobuild scripts are available
as Open Source if you are interested in looking at the parsing logic.
One way that GCC could make this type of system much easier to
develop is to format error messages consistently so that they can be parsed.
Right now, the formatting and content of GCC error messages seems
to be ad hoc.
A few years ago, I worked a lot with the IBM AIX C++ compiler
which had a nice convention for error messages. Each
line would contain either: (S), (I), or (W), where I believe that:
(S) was for fatal errors
(W) was for non-fatal warning messages
(I) was for informational messages.
IBM's compiler output was very helpful for making it easy to
write scripts to parse the error messages from huge nightly builds
and isolate error messages and warnings.
--
Craig Rodrigues
http://www.gis.net/~craigr
rodrigc@attbi.com