| parsing compiler error messages [message #46136] |
Mon, 21 October 2002 16:02  |
Eclipse User |
|
|
|
Originally posted by: pickens.metaware.com
We're using a different compiler than gcc to do our builds under CDT and
the error messages have a different format. Therefore, I need to be able
to override the error parsing. I noticed that the "ErrorParserManager"
is buried in an internal package, and isn't accessible from an extension
point. Is there a plan to make the error parsing more configurable in
the future?
(I noticed that ErrorParserManager maintains individual IErrorParser
class names from the preference store, but this interface has two
problems: it is an internal interface, and it apparently assumes that
each error message is just one line long.)
- David
|
|
|
|
|
|
| Re: parsing compiler error messages [message #46713 is a reply to message #46435] |
Wed, 23 October 2002 15:25  |
 David Pickens
Messages: 2
Registered: July 2009 |
Junior Member |
|
|
Dave,
Yes, I could have "processLine(String line)" track that it is actually in a
multi-line error message and to delay creating the marker until the entire
message is seen.
But it seems like it would be more in the spirit of Eclipse to make error
parsing an extension point with a well-defined interface (e.g.,
IErrorParserManager). Provide a default abstract class that defines
"generateMarker(IResource, line,...)" and "parseOutput(String)" .
parseOutput would create the <name/IFile> map of all files of the workspace
and then call "parse(String)". The default
would read lines and call the abstract method "processLine()" (which is a
protected abstract class that is defined in the abstract class only -- not
the interface). Then ErrorParserManager would be the default concrete
implementation.
This will provide the flexibility for a new plug-in to completely override
"parse(String)" altogether. (Or am I misunderstanding how extension points
work?)
-David
"Dave Inglis" <dinglis@qnx.com> wrote in message
news:3DB5A3DD.4060400@qnx.com...
> Could your error parser not consume the lines of the message and then add
the marker
> when it had received all lines?
>
> David Pickens wrote:
> > Dave,
> > Our compiler's error messages can extend for multiple lines after the
> > source/line marker. It would be nice to capture the entire message for
the
> > Tasks entry. This would require that the error parser be able to consume
> > multiple lines.
> > -David
> >
> > "Dave Inglis" <dinglis@qnx.com> wrote in message
> > news:3DB463D9.7000208@qnx.com...
> >
> >>I will soon be posting a patch which will basically make
> >
> > ErrorParserManager
> >
> >>and IErrorParser not internal with changes to the manager so that error
> >
> > parsing
> >
> >>is performed inline with the output stream writing.
> >>
> >>David Pickens wrote:
> >>
> >>>We're using a different compiler than gcc to do our builds under CDT
and
> >>>the error messages have a different format. Therefore, I need to be
able
> >>>to override the error parsing. I noticed that the "ErrorParserManager"
> >>>is buried in an internal package, and isn't accessible from an
extension
> >>>point. Is there a plan to make the error parsing more configurable in
> >>>the future?
> >>>
> >>>(I noticed that ErrorParserManager maintains individual IErrorParser
> >>>class names from the preference store, but this interface has two
> >>>problems: it is an internal interface, and it apparently assumes that
> >>>each error message is just one line long.)
> >>
> >>You can get the previous line from ErrorParserManager.getPreviousLine()
> >>
> >>Do you require more capabilities from the ErrorParserMananger?
> >>
> >
> >
> >
>
|
|
|
| Re: parsing compiler error messages [message #47386 is a reply to message #46713] |
Thu, 24 October 2002 20:02 |
David Inglis
Messages: 45
Registered: July 2009 |
Member |
|
|
David,
I guess I should have mentioned at the beginning of all this, but the entire
CBuilder will be going through a major change in the near future, at which time
we will most likely provide a means of adding\removing error parsers on a per-project
basis through an extension point, the interface used for this will most likely be
IErrorParser. I have no exact time frame for when this will all take place, but it
should be very soon.
David Pickens wrote:
> Dave,
> Yes, I could have "processLine(String line)" track that it is actually in a
> multi-line error message and to delay creating the marker until the entire
> message is seen.
>
> But it seems like it would be more in the spirit of Eclipse to make error
> parsing an extension point with a well-defined interface (e.g.,
> IErrorParserManager). Provide a default abstract class that defines
> "generateMarker(IResource, line,...)" and "parseOutput(String)" .
> parseOutput would create the <name/IFile> map of all files of the workspace
> and then call "parse(String)". The default
> would read lines and call the abstract method "processLine()" (which is a
> protected abstract class that is defined in the abstract class only -- not
> the interface). Then ErrorParserManager would be the default concrete
> implementation.
>
> This will provide the flexibility for a new plug-in to completely override
> "parse(String)" altogether. (Or am I misunderstanding how extension points
> work?)
>
> -David
>
>
> "Dave Inglis" <dinglis@qnx.com> wrote in message
> news:3DB5A3DD.4060400@qnx.com...
>
>>Could your error parser not consume the lines of the message and then add
>
> the marker
>
>>when it had received all lines?
>>
>>David Pickens wrote:
>>
>>>Dave,
>>>Our compiler's error messages can extend for multiple lines after the
>>>source/line marker. It would be nice to capture the entire message for
>>
> the
>
>>>Tasks entry. This would require that the error parser be able to consume
>>>multiple lines.
>>>-David
>>>
>>>"Dave Inglis" <dinglis@qnx.com> wrote in message
>>>news:3DB463D9.7000208@qnx.com...
>>>
>>>
>>>>I will soon be posting a patch which will basically make
>>>
>>>ErrorParserManager
>>>
>>>
>>>>and IErrorParser not internal with changes to the manager so that error
>>>
>>>parsing
>>>
>>>
>>>>is performed inline with the output stream writing.
>>>>
>>>>David Pickens wrote:
>>>>
>>>>
>>>>>We're using a different compiler than gcc to do our builds under CDT
>>>>
> and
>
>>>>>the error messages have a different format. Therefore, I need to be
>>>>
> able
>
>>>>>to override the error parsing. I noticed that the "ErrorParserManager"
>>>>>is buried in an internal package, and isn't accessible from an
>>>>
> extension
>
>>>>>point. Is there a plan to make the error parsing more configurable in
>>>>>the future?
>>>>>
>>>>>(I noticed that ErrorParserManager maintains individual IErrorParser
>>>>>class names from the preference store, but this interface has two
>>>>>problems: it is an internal interface, and it apparently assumes that
>>>>>each error message is just one line long.)
>>>>
>>>>You can get the previous line from ErrorParserManager.getPreviousLine()
>>>>
>>>>Do you require more capabilities from the ErrorParserMananger?
>>>>
>>>
>>>
>>>
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.03025 seconds
] 
Search
Help
Register
Login
Home
