From owner-freebsd-current@FreeBSD.ORG Thu Dec 19 09:57:54 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F321A6B0; Thu, 19 Dec 2013 09:57:53 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A3D1B1FCD; Thu, 19 Dec 2013 09:57:53 +0000 (UTC) Received: from [192.168.0.89] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginm.net [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id rBJ9vhWI025473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Dec 2013 09:57:45 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: RFC: less chatty system builds From: David Chisnall In-Reply-To: Date: Thu, 19 Dec 2013 09:57:38 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3843E85B-F0E9-456B-A375-599B599229F2@FreeBSD.org> References: <20131216184626.GA17125@onelab2.iet.unipi.it> <33B1B06B-72F7-4E8D-BB06-40CCC34006CF@FreeBSD.org> To: Luigi Rizzo X-Mailer: Apple Mail (2.1822) Cc: Dimitry Andric , "current@freebsd.org Current" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 09:57:54 -0000 On 19 Dec 2013, at 09:40, Luigi Rizzo 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