Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-core-dev] Default Error Parsers was(Re: [cdt-patch] Fix for the bugzilla report #65576)

> It turns out that all the register parsers needed to have a glimpse
> at the output.  For example the DiscoveryScanner(extracts -I and -D)
> or some other parser extracting information, the current
> build directory or dependecy checking, etc ....

The rejection, and the reasons behind it, comes as a total surprise to
us at Intel.  Everything that I had seen indicated that an error parser
should return true if it handled the error.  The built-in VC++ error
parser will return true, and an error parser that we have written for
our Intel C++ integration returns true.  Are these error parsers in
error for returning true?  And, if so, how were we supposed to know
that?  Was there a CDT 2.0 design note that indicated that new
functionality was going to use the error parser mechanism for what seems
to be an unrelated purpose? 

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 11:43 AM
To: cdt-patch@xxxxxxxxxxx
Cc: cdt-core-dev@xxxxxxxxxxx
Subject: [cdt-core-dev] Default Error Parsers was(Re: [cdt-patch] Fix
for the bugzilla report #65576)

> 
> 
> The attached file 'patch.txt' contains the fix for bugzilla report
> #65576. Currently Make,GCC,GAS,GLD Error parsers do not return 'true'
> even if they parse error output successfully. This patch fixes the
> problem.
> 

We will have to reject this one 8-(

The interface is:
	boolean IErrorParser.processLine(String line)

So when the current parser returns true, we stop calling the error
parsers
and move the current parser on top for the next line.

It turns out that all the register parsers needed to have a glimpse
at the output.  For example the DiscoveryScanner(extracts -I and -D)
or some other parser extracting information, the current
build directory or dependecy checking, etc ....

It is a bit late to have this change of behaviour for the default
parsers provided by the CDT.

We'll have to clean this after 2.0 and provide more features(States,
better multi-line support, hyperlinks markers, etc ...).


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


Back to the top