svn commit: r187132 - head/usr.bin/make

[David O'Brien]

On Mon, Feb 02, 2009 at 03:42:13PM -0700, M. Warner Losh wrote:
> 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?

It can be hard to get users to repeat something as-is. 

Enabling the job markers by default gives the information needed to
understand issues is present.  Much like Robert Watson's desire for
textdumps - you want enough information to understand the problem when
it occurred.  Its hard to get users to go back and get the needed
information.  Maybe I'm the only one that has found it hard to pin point
the reason for a build break with 'make -j<LARGE>'; but I do know over
the years we've told folks that report build breaks while using 'make -j'
to do the build again with no -j - one reason being its hard to figure
out what happened in the build.

As if, the way to get support is ``make -j8 buildworld || make buildworld''


> : 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.

Actually the commit message said "many environments", but I think
we've both added more details and folks can investigate for their
own environment.


> 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.

Once (b) is fixed, I do think it adds value for people and some scripts
reading the output.  Scripts can unwind the output and present the
complete part of the build for a particular target.

-- 
-- David  (obrien at FreeBSD.org)