On 19 Dec 2013, at 09:40, Luigi Rizzo <ri...@iet.unipi.it> wrote: > >> If a command produces warning output but exits with success, then that >> command's output is dumped to stdout (explicitly serialised by Ninja so that >> it's never interleaved with another command's output). >> >> If a command exits with a failure condition, then Ninja dumps the exact >> command line that was used, along with all of the output, and then stops. >> Another side benefit is that Ninja always uses absolute paths for invoking >> the commands and for arguments, and so you can always just re-run that >> single failing command. >> >> Oh, and when I do a build of LLVM/Clang on my laptop using Ninja, it takes >> about 3-5 minutes, whereas when I do it with our build system it takes about >> 15. When I do it on a 24-core server, it takes less than two minutes with >> Ninja and with ours it takes about 15 (no speedup over my laptop). I'd >> therefore suggest that there might be more pressing things that need fixing >> with our antiquated build infrastructure than the prettiness of the output... >> > these are orthogonal issues though, and so radically different in > complexity that it does not seem a waste of energy to apply > the patch i suggested while someone comes up with an improved build > system.
I disagree. These are the core issues. When the build works, everyone is happy with the less-verbose output. When it fails, you want the most verbose output. If a change is reducing the verbosity in the normal case, then that's fine, but it should not reduce the verbosity in the case of error. Ninja does this right. This is especially important with our build system, which can take several minutes of doing nothing to get to the point where a build fails. It is a serious productivity hit to have to wait that long to recompile a single file and see whether it's fixed. By ensuring that, in the case of failure, we have enough information in the terminal to reproduce the failing build step, we can improve this a lot. David _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
