Date: Thu, 19 Dec 2013 09:57:38 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: Dimitry Andric <dim@FreeBSD.org>, "current@freebsd.org Current" <current@FreeBSD.org> Subject: Re: RFC: less chatty system builds Message-ID: <3843E85B-F0E9-456B-A375-599B599229F2@FreeBSD.org> In-Reply-To: <CA%2BhQ2%2Bj6xaqCCguo-TmywrYWLU7PzKv81xwuy_20yyXFiX7CLg@mail.gmail.com> References: <20131216184626.GA17125@onelab2.iet.unipi.it> <F3D8A398-5FF5-4718-B8B8-99584A8B6502@FreeBSD.org> <33B1B06B-72F7-4E8D-BB06-40CCC34006CF@FreeBSD.org> <CA%2BhQ2%2Bj6xaqCCguo-TmywrYWLU7PzKv81xwuy_20yyXFiX7CLg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 Dec 2013, at 09:40, Luigi Rizzo <rizzo@iet.unipi.it> wrote: >=20 >> 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). >>=20 >> 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. >>=20 >> 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... >>=20 > 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. =20 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. =20 David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3843E85B-F0E9-456B-A375-599B599229F2>