Re: Remove debug echo

On Wed, Nov 30, 2011 at 5:59 PM, Garrett Cooper <yanegomi_at_gmail.com> wrote:
> On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best <arundel_at_freebsd.org> wrote:
>> On Wed Nov 30 11, Garrett Cooper wrote:
>>> On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best <arundel_at_freebsd.org> wrote:
>>> > On Tue Nov 29 11, Warner Losh wrote:
>>> >> kill it.
>>> >>
>>> >> Warner
>>> >> On Nov 29, 2011, at 2:07 PM, John Baldwin wrote:
>>> >>
>>> >> > Any objections to this?  It removes a weird line during 'make -s buildworld'
>>> >> > output and I think it was debugging accidentally left in in 213077 by Warner:
>>> >> >
>>> >> > Index: newvers.sh
>>> >> > ===================================================================
>>> >> > --- newvers.sh      (revision 228074)
>>> >> > +++ newvers.sh      (working copy)
>>> >> > _at__at_ -99,7 +99,6 _at__at_ for dir in /bin /usr/bin /usr/local/bin; do
>>> >> > done
>>> >> >
>>> >> > if [ -n "$svnversion" ] ; then
>>> >> > -   echo "$svnversion"
>>> >> >     svn=`cd ${SYSDIR} && $svnversion`
>>> >> >     case "$svn" in
>>> >> >     [0-9]*) svn=" r${svn}" ;;
>>> >
>>> > also...
>>> >
>>> > when running buildkernel via 'make -s', do we really need all those module
>>> > printfs? i see messages for "cleandir", "obj", "depend" and "all". i think for
>>> > 'make -s', that's pure overkill!
>>> >
>>> > for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4 and
>>> > you'll get 2680 lines of output. not really *silent*, is it? ;)
>>>
>>>     pmake sucks as far as diagnostic output is concerned when compared
>>> with gmake. I'd rather not have to fish through with -j1 (if I'm lucky
>>> and it's not a race) to determine what directory created the "Error
>>> Code" output. With the printouts discussed here, at least you have a
>>> chance at determining what the issue was.
>>>     Maybe it's just me, but I like noisy builds -- otherwise the
>>> amount of time I have to spend root-causing the issue becomes
>>> expensive.
>>
>> ehmmm...a noisy silent flag? i totally agree, if we're talking about 'make' in
>> its default mode, but what's the point of a silent flag, if it produces > 2500
>> lines of output? nobody uses the -s flag for diagnostics. its purpose is to
>> build a kernel without producing a lot of output and also not fiddling with
>> stdout/stderr to achieve that goal.
>
> What I really want is this:
>
> $ cat Makefile
> all: foo bar baz yadda
>
> foo bar yadda:
>
> baz:
>        false
> $ gmake
> false
> gmake: *** [baz] Error 1
>             ^^^^
> $ make all
> false
> *** Error code 1
>
> Stop in /tmp.
>
> Otherwise diagnosing issues becomes a PITA with -j > 1 (with pmake I
> have to start using some serious grep'ing, and if I'm lucky I can find
> the source of error). If I get a few spare cycles I might just
> implement it and post a patch somewhere (the entering and leaving
> directory feature of gmake is really nice too, but it's less
> important.. unless you have the same target in multiple directories)..

I've attached a patch that makes make do what I would like it to do;
there are some other items that require cleanup to achieve the `argv0'
prefixing that's available in gmake, but this is good enough for a
meaningful traceback when things fail. Pastebin available here, just
in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv

$ cat ~/Makefile
all:
        cd $$HOME/foo; ${MAKE} $_at_
$ cat ~/foo/Makefile
all: foo bar barf yadda

foo bar yadda:
        _at_true

baz:
        _at_false

barf: baz
$ $PWD/make -j4 -f ~/Makefile all
cd $HOME/foo; /usr/src/usr.bin/make/make all
*** [baz] Error code 1
1 error
*** [all] Error code 2
1 error
$

If someone would please, PLEASE commit this.. I will give you beer, or
wine, or a copy of Skyrim, or a few months subscription to WoW, or
something else of value to you that we could negotiate :)... I'm quite
frankly tired of having to playing guessing games fishing through logs
trying to determine build errors on FreeBSD if and when they do occur
with pmake, and I'm sure that a number of developers and build/release
engineers out there are in the same boat as I am.

Thanks,
-Garrett