Date: Thu, 19 Dec 2013 01:40:54 -0800 From: Luigi Rizzo <rizzo@iet.unipi.it> To: David Chisnall <theraven@freebsd.org> Cc: Dimitry Andric <dim@freebsd.org>, "current@freebsd.org Current" <current@freebsd.org> Subject: Re: RFC: less chatty system builds Message-ID: <CA%2BhQ2%2Bj6xaqCCguo-TmywrYWLU7PzKv81xwuy_20yyXFiX7CLg@mail.gmail.com> In-Reply-To: <33B1B06B-72F7-4E8D-BB06-40CCC34006CF@FreeBSD.org> References: <20131216184626.GA17125@onelab2.iet.unipi.it> <F3D8A398-5FF5-4718-B8B8-99584A8B6502@FreeBSD.org> <33B1B06B-72F7-4E8D-BB06-40CCC34006CF@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 19, 2013 at 1:18 AM, David Chisnall <theraven@freebsd.org>wrote: > On 16 Dec 2013, at 21:35, Dimitry Andric <dim@FreeBSD.org> wrote: > > > In any case, if anything like this is implemented, I would really prefer > > something like CMake does, e.g. give you a percentage counter that > > provides some information about how 'far' the build is progressing. > > I haven't seen this for a while, because I now use ninja exclusively for > building any projects that use CMake. The output of Ninja is pretty close > to my ideal for a build system, and so I'd recommend that anyone hacking on > this look at it. It looks something like this while building: > > $ ninja > [1/22] Building CXX object > lib/Target/Mips/AsmParser/CMakeFiles/LLVMMipsAsmParser.dir/MipsAsmParser.cpp.o > > The [1/22] part is a counter of the number of build steps done and updates > in place. The 'Building CXX object ...' part tells you what the current > rule is and what it's being applied to. This is only approximate, as it > usually does parallel builds, but it gives you some idea of what's > happening. > > the "Building CXX ... " is basically the same type of output that I was proposing. I am still unclear on how one can implement useful counters (see my other email) since the times of "build step" vary by 2-3 orders of magnitude. Anyways, maybe just counting the number of targets in the first 2-3 levels of the tree can give an idea. 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. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2Bj6xaqCCguo-TmywrYWLU7PzKv81xwuy_20yyXFiX7CLg>