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

["Treggiari, Leo" <leo.treggiari@xxxxxxxxx>]

I agree with you that the re-ordering is not a good idea and should be
dropped (post 2.0).

But I disagree on another point.  

I think that an error parser should return true if it handled the error
and that the other error parsers should not be called.

I think a new attribute should be added to specify an ordered list of
"build output watchers".  These would be called with each line of
output, and it may not be necessary (desirable) to have them changeable
via the UI.

Regards,
Leo

-----Original Message-----
From: cdt-core-dev-admin@xxxxxxxxxxx
[mailto:cdt-core-dev-admin@xxxxxxxxxxx] On Behalf Of Alain Magloire
Sent: Thursday, June 10, 2004 3:24 PM
To: cdt-core-dev@xxxxxxxxxxx
Subject: Re: [cdt-core-dev] Default Error Parsers was(Re: [cdt-patch]
Fix

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


_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev