Piping compiler output to a script + bugreport

[Tarjei Knapstad]

On Fri, 2003-03-07 at 15:28, falk.brettschneider at gmx.de wrote:
> > Is KDevelop 3.0
> > the trunk in CVS
> cvs HEAD
> 
> > > And the reformatting of gcc errors concerning to templates would just
> > mean
> > > another additional regular expression there.
> > > 
> > I'm not sure what you mean here...?
> +
> > As far as I can understand compiler errors should be sent through
> > STLfilt (if the user wants to), before being sent to the Messages
> > output. Would that be the correct approach?
> KDevelop internally filters the gcc output through several QRegExp's before
> the text comes out of the output view. For instance it colours the error
> messages red.
> 
I see. Hopefully then, the raw gcc output can (optionally) be run
through STLfilt prior to entering KDevelops regexp's.

> I just mean you shouldn't use STLfilt but wrote additional Qt regular
> expression for STL gcc-error-messages. Those must be added in
> parts/outputviews/makeview.*
> But of course you can see how STLfilt works to do the same in our QRegExp.
> 
That's what I was afraid of :) Looking at the STLfilt script you'll see
that it's more than just a few simple regexps to get the gcc output to
behave nicely.

However simple or difficult it may be to incorporate the STLfilt
functionality into KDevelop using regexp's I view this alternative as a
complete waste of time:

1. Reinventing the wheel is never a good thing.

2. Whenever a new version of the STLfilt script is released, it will be
a complete and utter horror to update and maintain the "KDevelop regexp
version" which duplicates STLfilt's functionality.

3. If this kind of funtionality is implemented in a somewhat generic
way, it would mean that the user could run the compiler output through
any script he/she wants. You could for instance run it through a script
that produced HTML build reports for a website.

For these reasons I think the best approach is to run the gcc output
through STLfilt before the KDevelop regexp's kick in (and if needed run
a slightly different set of regexp's on the STLfilt output, instead of
trying to emulate STLfilt in the first place).

> Anyway it's a good idea to beautify the gcc output ;-)
> 
It certainly is :) Recently my top line in a stack trace consisted of
more than 6000 characters when debugging some code that used parts of
the Boost libraries, i.e. heavily templated.

This also made me discover a bug in the KDevelop 2.1.4 stack trace
display: When you get extremely long lines the whole display just blanks
out (all you can see is the '-' sign). You can get it back by clicking
'-' on the thread you're viewing and then clicking '+' again, but as
soon as you start scrolling all or part of the text disappears.

To me this looks like a bug in either the Qt or KDE widget used to
display the stack trace, but I haven't had time to investigate, or try
it out in KDevelop 3.0a3. Currently I don't know at what line length
this bug occurs either, but it could probably be reproduced by trying to
compile some of the examples distributed with STLfilt.

Cheers,
--
Tarjei


-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«