Community
Participate
Working Groups
CDT GNU Make Error Parser doesn't parse a lot of common errors generated by make. I extended CDT Make Error Parser to contain the following errors, taken from http://www.gnu.org/software/make/manual/make.html#Error-Messages. Every message starts with "make" and the suffix of the message is one of the following: `[foo] Error NN' `[foo] signal description' `missing separator. Stop.' `missing separator (did you mean TAB instead of 8 spaces?). Stop.' `commands commence before first target. Stop.' `missing rule before commands. Stop.' `No rule to make target `xxx'.' `No rule to make target `xxx', needed by `yyy'.' `No targets specified and no makefile found. Stop.' `No targets. Stop.' `Makefile `xxx' was not found.' `Included makefile `xxx' was not found.' `warning: overriding commands for target `xxx'' `warning: ignoring old commands for target `xxx'' `Circular xxx <- yyy dependency dropped.' `Recursive variable `xxx' references itself (eventually). Stop.' `Unterminated variable reference. Stop.' `insufficient arguments to function `xxx'. Stop.' `missing target pattern. Stop.' `multiple target patterns. Stop.' `target pattern contains no `%'. Stop.' `mixed implicit and static pattern rules. Stop.' `warning: -jN forced in submake: disabling jobserver mode.' `warning: jobserver unavailable: using -j1. Add `+' to parent make rule.' My implementation is located in MakeErrorParser class, inside patterns initialization code, based on official CDT 4.0 RC2 sources (plugin org.eclipse.cdt.core, package org.eclipse.cdt.internal.errorparsers). Attached file with implementation.
Created attachment 71715 [details] MakeErrorParser patch
Very cool. Thanks. This is something that Makefile project users will find necessary. It's too late for CDT 4 for this kind of change, but I'd be happy to look at it for 4.0.1.
Have you tried this on very long builds (e.g. Firefox or something of that size)? I'm concerned over the performance impact of having so many patterns.
Created attachment 77621 [details] performance test program
Thanks, but the question is how much does the new patterns slow down large builds like Mozilla. We've been burned in that past by this.
(In reply to comment #5) > Thanks, but the question is how much does the new patterns slow down large > builds like Mozilla. We've been burned in that past by this. Hi, Sorry , my comment failed to commit yesterday, leaving you with test program without explanation :-( . So here it is: I didn't try to run Extended Make error parser on a huge build . However i have written a test program that helps to estimate approximately the performance of extended make error parser on builds of different length. It runs all the patterns in extended make error parser for a "line" input in a loop . Since error parsers are run on every build output line, this test program simulates the work of an error parser during the build. The estimated results for extended make error parser: 1k lines - 0.1 sec 10k lines - 0.5 sec 100k lines - 5 secs 1000k lines - 55 secs The estimated results for the current make error parser 1k lines - 0.03 sec 10k lines - 0.1 sec 100k lines - 0.5 secs 1000k lines - 5 secs So you can see that there is a tradeoff between the parsers, but for small/ average / big projects the difference is almost transparent for the user. For very big builds the difference of 50 secs for build with output of 1 million lines is also reasonable in my opinion. The test program is attached. You can try it too. It is very easy to update this test to run on Mozilla build output. You can save it in a file, read it to some array to eliminate I/O tradeoff during the test and then run the patterns on every line. In order to estimate how much the patterns slow down the build, you can run patterns from the extended / current Make Error parser and then calculate the difference. In addition, users can always turn on/of the Make Error parser depending on they needs. Hope this helps, Irit
So if I read this correctly the error parsing is 10 time slower. That's not insignificant. And you can't expect users to turn it off on big projects. I'll need to do real timings on Firefox before committing this patch.
(In reply to comment #7) > So if I read this correctly the error parsing is 10 time slower. That's not > insignificant. And you can't expect users to turn it off on big projects. > I'll need to do real timings on Firefox before committing this patch. Hi, Current Make Error Parser doesn't meet basic functional requirements. It doesn't parse most of the common errors generated by make (please refer to official GNU Make Manual: http://www.gnu.org/software/make/manual/make.html#Error-Messages). I have attached 13 simple make projects examples where make reports "common errors" which are not passed to Problems by the make error parser. This situation makes make project users work very difficult. As you have mentioned before, Makefile project users will find an extended make error parser necessary. Moreover, performance should be considered in a build context. For instance, if a build process runs for 3 hours, then additional 50 secs will not make the big difference for a user, even if the parser is 10 times slower. Irit
Created attachment 77778 [details] make project examples make error parser fails to detect errors/warnings generated by make in these projects
I timed Firefox builds and the build times went from 42 minutes to 43 minutes, not too bad. I've committed the patch. Thanks!
