Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Error Parser Issues..

> 
> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C46383.422ADE35
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> > Hi,
> > 	I have submitted three Bugzilla reports regarding error parser
> > issues. I would like to discuss these at the next CDT monthly meeting
> > with the goal of reaching closure on the desired fixes to the issues.
> > -----
> > Bugzilla #65576:=20
> > 	The GNU error parsers never return TRUE. We believe that error
> > parsers should return TRUE when they handle the error line and that
> > the remaining error parsers on the list should not be called for that
> > line. If there is functionality using the error parser list that needs
> > to always be called for each line (does anyone know of any?), it
> > should be using a different mechanism.

What other mechanism are you suggesting?  The output logs can be big
so they are not save.   Some clients need to harvest the build output
for information discovery, a few examples come to mind:

- GNU Make Error Parser:  It harvests the output to discover patterns
  that would indicate the current build directory.
- The auto discovery:  (altough not visible to the user)  Also harvest
  the output for information ("-D", "-I" for macros and includes etc ...)

... we can probaly have other usefull things.

I do not understand you prequisites in discarding the other output parsers.
But if the problem is duplication or not to confuse the other output parsers
we could mark the line to notify the other parsers that a motif was found.

Probably IErrorParser was a misnommer, it should have been:

interface IErrorParser extends IOutputParser {
};

Some other things still missing, for example a notion of state to do
better multi-line output parsing etc ...

We should make a draft/doc and submitted to the list to go through
the usual CDT design iterations.


> > Bugzilla #66762: Issue with Error Parser ordering.
> > 	  There are two things here.
> > 	  i) CDT does not invoke the error parsers in user specified
> > order.

Agreed, we would like to get rid of that fancy reordering
on the next iteration.

> > 	 ii) CDT dynamically changes the Error Parser order. CDT may be
> > doing for performance reasons. Additionally, if desired, we could add
> > an "Enable Error Parser Ordering" check box to the "generic" error
> > parser picker dialog box. When true (the default), the Up and Down
> > buttons would be active at the appropriate times (as they are today),
> > and the error parser manager would respect the specified order. When
> > false, the Up and Down buttons would be disabled and the error parser
> > manager would be free to re-order the error parsers.
> > Bugzilla #66808: "Restore Defaults" button in Error Parser window of a
> > Project property page does not work as expected.

Agreed.

> >  In error parser window, user can select/unselect the error parsers,
> > change the order of error parsers. For each "Build Target"
> > configuration, there is a default set of  Error Parsers included. For
> > example, if user wants to build his/her project with Gnu C Compiler,
> > the default error parsers are
> > 	  i) CDT GNU C/C++ Error Parser
> > 	 ii) CDT GNU Assembler Error Parser
> > 	iii) CDT GNU Linker Error Parser
> > 	 iv) CDT Make Error Parser
> > When user presses the "Restore Defaults" button in error parser window
> > of project property page, it is not restoring the default error parser
> > list, instead, it is discarding the changes and setting to previous
> > saved state that may not be default state always.

Looks like PR material.




Back to the top