svn commit: r314654 - in head/cddl: lib/drti lib/libavl lib/libctf lib/libdtrace lib/libnvpair lib/libumem lib/libuutil lib/libzfs lib/libzfs_core lib/libzpool sbin/zfs sbin/zpool usr.bin/ctfconver...

[Garance A Drosehn]

On 5 Mar 2017, at 20:43, Ngie Cooper wrote:

>> On Mar 5, 2017, at 17:05, Garance A Drosehn <drosih at rpi.edu> wrote:
>>
>> FWIW, here was my method to fix the "slows down output" issue.
>> I wrote a wrapper around 'make' which I called "wcmake", and
>> it runs the output from a 'make' command through a script
>> which does a variety of analysis on that output.
>
> Hi!
>     Have you considered using make -s instead? It definitely
> abbreviates the output quite a bit...
>     I probably could do similar for my local builds. Our
> Jenkins runs don't do that, but maybe they should though..
> Thanks,
> -Ngie

Well, the scripts are doing a lot more than just abbreviating the
output sent to the console.  They save the entire output, and
compress that file to reduce the space used.  They also generate
a summary of warnings-seen at the end.  This was very helpful
when I was fixing all the compile-time warnings in 'lpr'.

My first tactic was sending the output to /dev/null, but then I
was stuck when "something weird" happened, and I had no idea
where 'make' had been before it went off the rails.  Especially
when using 'make -j', it can be important to see the last 30-50
lines of make's output to understand what really went wrong.

And sometimes what-went-wrong was that some file was being built
with the wrong parameters, and I'd lose that info with 'make -s'.

Also, I use these same 'wcmake' scripts on multiple platforms.
These scripts don't care which version of 'make' needs to be used.

-- 
Garance Alistair Drosehn                =     drosih at rpi.edu
Senior Systems Programmer               or   gad at FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA