Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Contributing a build output console parser

On 23 May 2011 20:31, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
On Mon, May 23, 2011 at 10:35 AM, Priyadarshan Gupta <priyadarshan.eclipse@xxxxxxxxx> wrote:
It parses tool specific messages from the console which will be processed along with some project build specific data and later written onto a file.
That is too general a description to give a good advise. Error parser should be able handle that. That sounds like something very specific to your build and does not give good justification for a new extension point.
  
The problem in implementing the same as IErrorParser is that an error parser is instantiated once and for all by the ErrorParserExtensionManager. I want a new parser instance for each project build and also I am not creating any problem markers.
You can instantiate your own classes handling output from your error parser every build easily.

In our product every build is actually represented by a set/combination of [Project - Hardware config. - Build property]. The problem is we do not know when the build combination has switched and when to initialize our classes because all we get inside an error parser is the current line and ErrorParserManager (instantiated per build but contains only project information).

We are looking for parser being instantiated per build combination so that the files being written corresponds to different build combinations (even if the project was same always). The ErrorParserManager does not allow any build specific data (in our case HW config and build property) to be passed onto the parser. If somehow ErrorParserManager could have fetched copies of error parsers rather than original ones this problem would be solved. I think prior to CDT 6.0 there was no ErrorParserExtensionManager so this problem didn't exist.


PS: One thing which can be done is to parse the Entering directory messages to get a hint about Hw config and build property but again that is not reliable since the build output directory can be anything.

Thanks,
Priyadarshan

 

Thanks,
Andrew
 

Regards,
Priyadarshan


On 23 May 2011 18:54, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
Hi Priyadarshan,
What does your console parser do?

Thanks,
Andrew

On Mon, May 23, 2011 at 9:04 AM, Priyadarshan Gupta <priyadarshan.eclipse@xxxxxxxxx> wrote:
We are extending the CDT builder for our tool chain and using almost all functionality of CDT Make builder except a few things and that "Scanner Configuration Builder" is not required. The requirement of our builder is that it must allow clients/other plugins to contribute a console parser to the builder so as to parse the build output from the console. This parsing is however not followed by marker generation.

There are two relevant parser interfaces viz. org.eclipse.cdt.core.IErrorParser and org.eclipse.cdt.core.IConsoleParser. Considering that IErrorParser is implemented by parsers looking for build errors and therefore are also responsible for creating problem markers, we should keep the API implementation for our parsers as IConsoleParser.

But as can be seen IConsoleParser contains javadoc annotations - @noextend and @noimplement and contrary to it this interface has been extended by org.eclipse.cdt.make.core.scannerconfig.IScannerInfoConsoleParser, which is a part of Scanner Configuration Builder, we are now in facing a dilemma of whether to use that interface or not.


One plausible way is to define an extension point org.eclipse.cdt.core.BuildOutputConsoleParser with interface for contributed extension classes as org.eclipse.cdt.core.IBuildOutputConsoleParser. IBuildOutputConsoleParser will extend IConsoleParser. There will be a ConsoleParserManager to load and initialize the console parsers within the builder at runtime. The extension point can have configuration elements for inclusion or exclusion of specific builder ids as well.

Can anyone please suggest the correct way to define or contribute a simple console parser for the build output ?

Thank you
Priyadarshan
Tensilica India, Pune

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



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



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



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


Back to the top