Re: [cdt-core-dev] Default Error Parsers was(Re: [cdt-patch] Fix

["Alain Magloire" <alain@xxxxxxx>]

> 
> > Sounds like a good idea.
> > Is that satisfactory to you Leo ?
> > Was the reordering of importance to you ?
> 
> As I think I've written to cdt-dev during the last month or so, I found
> a few surprises in the base error parser code when implementing the
> error parser support dialog box for the managed build system.
> 
> I committed to Sean Evoy that I would look into these.  However, none of
> these problems are any more important to an Intel integration than to
> any other integration that supplies an error parser.  What I need to
> know now, is whether an Intel C++ error parser should always return
> false when used in CDT 2.0.  I would not suggest making any changes in
> 2.0 that don't match our long term intentions for the support (which it
> sounds like we need to discuss).
> 

I would suggest that it returns false.

> For post-2.0 discussion:
> 1.  What does returning true vs. returning false from an error parser mean?

Something like this:

  void IErrorParser.processLine(StateObject state);

> 2.  What does the order of the error parsers in the dialog box mean?
> The error parser manager appears to ignore the order.

It indicates the order the parserManager will call the error parsers.

> 3.  If the order is important, should the error parser manager be
> dynamically modifying the order - even for perceived performance
> reasons?

Exactly,  I would advocate to remove the dynamic stuff in the current code base(post-2.0).
It defies the purpose of allowing the clients to order the parser..
Say an ISV set a particular order because it needs some parser to be last ...

> 4.  If the order is important and performance is important, should the
> user have the option to say whether to specify the order or leave the
> order up to the error parser manager?

The point is that we(I) think the dynamic order and the short-circuit(stop the
other parsers from looking at the output)  are not usefull.

For example, some implementation wants to save the output build log to a
file or redirect it to another stream, to do this an ErrorParser to sniff the build stream
is added in the list of parser,  If a parser in the chain returns true, the others will be skip.
Not very usefull, all parsers should have a chance to peek at the stream.


This is one opinion 8-)