From owner-freebsd-arch@FreeBSD.ORG Mon Feb 2 22:42:21 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC2C21065720; Mon, 2 Feb 2009 22:42:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6C8668FC13; Mon, 2 Feb 2009 22:42:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n12MfnSw020319; Mon, 2 Feb 2009 15:41:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 02 Feb 2009 15:42:13 -0700 (MST) Message-Id: <20090202.154213.387237162.imp@bsdimp.com> To: obrien@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090202220628.GA76833@dragon.NUXI.org> References: <20090130.085130.-4349483.imp@bsdimp.com> <20090130.093052.-2022808221.imp@bsdimp.com> <20090202220628.GA76833@dragon.NUXI.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2009 22:42:22 -0000 In message: <20090202220628.GA76833@dragon.NUXI.org> "David O'Brien" writes: : On Fri, Jan 30, 2009 at 09:30:52AM -0700, M. Warner Losh wrote: : > OMG! There's too much make output now, and the recent changes broke : > useful make features. All but one were eventually fixed. I just : > fixed the -s breakage. : : I fail to see where 'make -Q -s' is not suitable to achieve the goals : you mentioned for 'make -s'. I did make sure you could quiet things. Two points here. (1) Should this be opt-in or opt-out. Is the output really so useful that we can't live without it? I think it should be -v to get the output. This is referred to as 'a -Q world' vs 'a -v world' in other discussions, so I'll use that here. What is the use-case that shows it is a win to be opt-in? What does having it on always buy us that having to repeat a run of a build with special debugging args to debug a problem fail to achieve? (2) Since this output falls outside of posix, one must also interpret the posix standard for what different flags do more loosely. The output is clearly related to the commands run. Is this enough, in a -Q world, to suppress it? That's not an automatic 'no' or 'yes'. In a -v world, it doesn't matter: we don't need to suppress additional output. : I've tried to measure the "~10% performance improvement" in using : 'make -s' that was the technical justification for r187921. I have : been unable to achieve ~10%. The summary is: [[ benchmarks deleted showing about a 2-3% drop in performance for -s ]] I was careful to caveat that with some environments. The one I was in was NFS to a slow server on an otherwise fast machine. I think the output size arguments are weak at best since they don't take into account the semantic value added by the output. Sure, disks can handle it, but does it add value for people or scripts reading the output? However, I think that it is a moot point since (a) I've back out the change and (b) the output is currently wrong. As to (b): Consider the following Makefile: all: one two three four one two three four: @echo ${.TARGET} @echo ${.TARGET} @echo ${.TARGET} @echo ${.TARGET} Right now, we get useless output from these job markers: % make -j 3 all --- one --- --- two --- --- three --- one one one --- one --- one two two two --- two --- two three three three --- three --- three --- four --- four four four four Based on this, I'd suggest we turn them off until we can at least produce good results. I don't know if we want them on by default with good results, but we certainly want them off when they are generating bad results. Warner