Re: [cdt-dev] Why is org.eclipse.cdt.internal.errorparsers internal?

["Andrew Gvozdev" <angvoz.dev@xxxxxxxxx>]

Hi,

On Fri, Aug 8, 2008 at 10:57 AM, Schaefer, Doug <Doug.Schaefer@xxxxxxxxxxxxx> wrote:

AFAIK, this is ancient history. I'm not sure anyone would remember why it's like that. We'd certainly accept contributions to clean this up in 5.1.

 

That sounds promising. Perhaps you can arrange review of the patch attached to bug 215492 last January? I would volunteer to make any corrections if necessary if the author is not available.

Thanks,

Andrew

Cheers,

Doug.

 I am sure Doug is very busy with all that's going on but maybe somebody else from commiters could take a look at the patch? This is as simple as moving a couple of internal but very useful classes to public package. Should not be a problem from the point of API change, should it? Last time Elena was nice to me and all of us who use make targets are very grateful.

Thanks,

Andrew

---

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev
Sent: Friday, August 08, 2008 10:53 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Why is org.eclipse.cdt.internal.errorparsers internal?

On Fri, Aug 8, 2008 at 5:51 AM, Achim Bursian <abu.aud@xxxxxxxxxxx> wrote:

Hi!
Is there any specific reason why package org.eclipse.cdt.internal.errorparsers is internal?

It would be very helpful to use the base class AbstractErrorParser and the ErrorPattern class in other error parsers.

I happen to agree with this opinion. See bug 215492 which unfortunately did not get much traction. I also think that it would be very useful to have some kind of user-configurable generic parser in CDT. We use many tools in our builds emitting various warnings and it would be nice to get errors/warnings/infos in problems view and hightlighted in the code. So far we are stuck to using perl script to reformat to GCC error parser and XLC errorparser likings (where a format is kind of weird but it allows to populate the view with Infos).

I think that this would also help expanding using of CDT as a platform to development in different languages. For example, a while ago I used it to parse PHPUnit output. Worked fine after you invest some time to set it up

Thanks,

Andrew

Why is that discouraged?

Cheers,
  Achim

_______________________________________________
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