[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Contributing a build output console parser
|
For error parsers, so far RegexErrorParser has been enough and we've never explored the avenue of extending IErrorParserNamed with different type. There could be issues, and this is mostly the reason that RegexErrorParser is hardcoded in these places implicitly disallowing using other classes. If you think those are a blocker for your development, I suggest to open bugzilla report and submit a patch.
Thanks,
Andrew
On Tue, May 24, 2011 at 9:45 AM, Andrew Gvozdev
<angvoz.dev@xxxxxxxxx> wrote:
On Tue, May 24, 2011 at 4:36 AM, Priyadarshan Gupta
<priyadarshan.eclipse@xxxxxxxxx> wrote:
I hope IErrorParserNamed interface is allowed to be extended and
implemented by clients. It mandates subclasses to implement clone()
method, but to my amazement that clone() will never be invoked for me because of
the following piece of code in ErrorParserExtensionManager.
public static IErrorParserNamed getErrorParserCopy(String id, boolean isExtension) {
IErrorParserNamed errorParser = isExtension ? fExtensionErrorParsers.get(id) : fAvailableErrorParsers.get(id);
try {
if (errorParser instanceof RegexErrorParser) {
return (RegexErrorParser) ((RegexErrorParser)errorParser).clone();
} else if (errorParser instanceof ErrorParserNamedWrapper) {
return (ErrorParserNamedWrapper) ((ErrorParserNamedWrapper)errorParser).clone();
}
} catch (CloneNotSupportedException e) {
CCorePlugin.log(e);
}
return errorParser;
}
Instead of hardcoded type checks shouldn't it rather be
try {
if (errorParser instanceof IErrorParserNamed) {
return (IErrorParserNamed) errorParser.clone();
}
} catch (CloneNotSupportedException e) {
CCorePlugin.log(e);
}
Did you try to compile your suggestion? It won't. Cloneable interface is different from normal ones, it actually does not define clone() method.
Andrew
Regards,
Priyadarshan
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).
This is precisely the job of platform Build Configurations. As it stands I think it's too late to make non-bugfix changes here for Indigo...
Cheers,
James
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev