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
Thanks, that is the level of detail I was looking for. 

> Can anyone please suggest the correct way to define or contribute a simple console parser for the build output ?
As you noted, currently there are 2 kinds of build output parsers, error parsers IErrorParser and scanner discovery BOP parsers which are being fed with the output by CDT build. To answer your question it would be supposedly clean to unify them to have one super interface and allow extension point for "generic" build output parser. However at that point I do not see that we are reaching a critical mass to do just that. Another correct solution would be to use configuration mechanism provided by build model and recently by the platform but I think it might be quite heavyweight one. FWIW I think the most practical/simple thing for you is to use error parser even if not quite "correct".

Thanks,
Andrew

On Mon, May 23, 2011 at 4:05 PM, Priyadarshan Gupta <priyadarshan.eclipse@xxxxxxxxx> wrote:
We have a separate dialog for specifying that list, very similar to what is offered by Visual Studio. For each entry (triad) in that list we generate separate Makefiles within separate folders. At runtime we just update the top level Makefile to point it to the desired Makefile, which is run through the CDT Make builder. So while building we don't have to worry since low level Makefiles are generated in such way so as to know about a particular build triad.

Now regarding the messages we are trying to parse: our tool while compiling sources gives out suggestion messages for the area within code which can be vectorized. We want to capture those messages into a file (per build triad), which can later seed a View. That is why config and build property information is required within the parser. The parser also schedules a job to write that file.

I hope this is clear.
 
Thanks


On 24 May 2011 01:04, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
On Mon, May 23, 2011 at 3:08 PM, Priyadarshan Gupta <priyadarshan.eclipse@xxxxxxxxx> wrote:
On 23 May 2011 22:29, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
On Mon, May 23, 2011 at 12:28 PM, Priyadarshan Gupta <priyadarshan.eclipse@xxxxxxxxx> wrote:
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).
You could initialize your classes on the first line of output. Currently build is always dealing with Active build configuration, so you can have configuration. Is it the same as your Hardware config?

We have a provision where user can run a batch build i.e. a list containing all permutations and combinations of a build triad without setting anything Active. In such case we would be helpless.
Active configuration is set by build itself as far as I remember. Hmm, how else would you know which permutation is current? How do you run a "batch" build? Did you implement your own on top of CDT Make builder?
 
 
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.
To handle copies of error parsers per a configuration is a huge can of worms. There is bug 289167 but not much work was done.
I see the ErrorParserExtensionManager#getErrorParserCopy(String parserId) is supposed to return the cloned copies of the loaded error parser but it happens only in the case of RegexErrorParser and ErrorParserWrapper (shallow copy) that cloning is done. What about other error parsers which are capable of providing clones ?
I don't really see how that would help you if you cannot know your current permutation. But if you do, you don't really need a clone. As I said, you can reinstantiate/reinitialize your handler classes inside error parser on the first line of your permutation output.

Can we make that type checking more flexible so that parsers which support cloning are allowed to do so.
Well, I am reluctant to do that for error parsers considering you need it for totally different purpose. If go that route - contrary to the impression I suppose I managed to make - I would consider generic Build Output Parser idea. If you can make a case that it benefits community as a whole, not only one person who won't even tell what he needs it for :)
 

Thanks
PD
 

Andrew
 
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



_______________________________________________
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



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


Back to the top