Date: Mon, 02 Feb 2009 15:42:13 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: obrien@FreeBSD.org Cc: arch@FreeBSD.org Subject: Re: svn commit: r187132 - head/usr.bin/make Message-ID: <20090202.154213.387237162.imp@bsdimp.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20090202220628.GA76833@dragon.NUXI.org>
"David O'Brien" <obrien@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090202.154213.387237162.imp>