When a common import has an error, ninja's output is very verbose
schveiguy opened this issue · comments
Using a basic build system, such as dub, when an error occurs, the resulting error is typically the only one that is shown.
However, when using ninja, which is running many concurrent executions of the compiler, an import containing an error that is common between all the builds will produce the same errors N times.
Not only that, but when ninja fails, it displays the failed build line. In this case for my project, the build line is humongous, meaning I get about 10 copies of the same error chain, along with 10 large build lines.
It would be nice to have common errors suppressed (along with the build line that caused it). I'm not sure if this is even possible via ninja.
You can try ninja -j1 to use only one thread, but other than that I don't know what reggae is doing specifically here.
I don't know how the thing works, if there is a way to suppress repeated errors. But the end user experience is poor, I get pages of the same error.
Does ninja drive the printing of errors or is it something reggae provides?
How would I reproduce it?
This is normal ninja behavior, nothing reggae could influence.
ninja -j1 after a previous unsuccessful build can help to deal with errors one at a time (or rather, one target at a time). But if unlucky wrt. scheduling order, it might not start with a failing target right away, but compile some other stuff (serially) before that.
What I use more commonly is -k 999, to make ninja build all it can, and see all errors at once, instead of ninja by default stopping the scheduling of new targets after the first error (but still trying to finish the already-started ones).