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?=20
The Error parsers that come with the CDT by default, have always return
false.
Whether this behaviour is good/bad is another matter 8-)
changing it at this time is not a good idea, some folks may rely on
that buggy behaviour.
We hope to address this issue after 2.0, with proper API and clear
behaviour.
If you want to create a custom error parser thats take advantage of this
behaviour
for 2.0 ..go..
VC++ error is an odd one, it's not really been exercise by a lot of
people, most
folks use the GNU toolchain.
_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev
