Re: Report to stdout like Linux kernel compilation does

[Bob Proulx]

John Calcote wrote:
> I love this format because warnings and errors are obvious, and yet
> you get enough output per file to tell you that something's going
> on.

To give you a different perspective, I *hate* that format because it
hides problems and *makes debugging harder*.  I want to see exactly
the command that was executed.  I want to see the entire command.  I
don't want to see an abbreviation of the command.

> The real benefit of this output format is that WARNINGS are obvious.

Again, from my perspective the disadvantage of this is that it *hides*
the commands that produced the errors and warnings.  Hiding this
information makes the build harder to debug.

> Often, in standard GNU/Unix/Linux build processes, warnings just zip
> right by without much notice.

Using the eye to scan through build output to find problems isn't a
reliable method.  It is too easy to miss something when tired or
hurried.  If you are counting on using your eye to find these then
statistically I believe you will have missed some error or warning at
some time in the past.  (I know this from human spam filtering which
has a non-zero error rate.)  It is much better to use a tool to scan
through build output.  Tools are much more reliable than humans for
this type of tedious and repetitive task.

For me I use my editor for this.  I tell my editor to open the file
and position my cursor on the next error or warning.  Since the editor
is walking each warning and error I can't miss any.  Most programming
editors do this these days.  However even without editor assistance
these messages can be extracted using 'grep' or other process.

> My question to the list was: How can I get Autotools builds to be
> quiet, so I can see the warnings? The response that I got was that I
> should just redirect stdout to /dev/null on the make command line.

That is effectively what you would be getting if you threw away the
information of the command that produced the problem.  If you want to
throw it away then okay but please leave it there for the rest of us
who need it.

> For the next couple of years, I very was frustrated with this
> response. I thought it was a cop-out for just not wanting to provide
> the functionality.

It isn't a cop-out.  Instead it is that your requested behavior
*actively hurts* the rest of us who need that information.  If things
were reversed then I would be writing the list begging to please
provide the full build information.  It is easy to throw useful
information away.  After having been thrown away it can't be gotten
back.  It is not symmetrical.

> Then I realized that it was really the Unix way.
> You want to see everything so that you know what's going on.

Yes!

> When you want to clean up the warnings (usually something done near
> the end of a development cycle), you simply build with stdout
> redirected to /dev/null when you run make a few times, and you'll
> see the warnings appear, because they're output to STDERR, not
> STDOUT.

No!  I never build with output redirected to /dev/null.  I always
build with full warnings enabled and clean them up as I go.  Trying to
do a big cleanup at the very end is bad.  It is better to keep it
clean as it goes.

Always build with full warnings enabled.  Always clean up warnings as
they are introduced.  Always keep a warning free build.

> Now -- that said, I really see nothing wrong with my original request,
> in the form of an Automake switch. It would be nice to be able to tell
> Automake to build Makefiles that generate this sort of output.
> Unfortunately, you and I aren't going to get much agreement, I think.

As an option I think it is fine too.  But someone would need to do the
work.

> Perhaps, if you were to write a patch to Autoconf, providing a macro
> or switch that generates such Makefiles... This also the GNU way. :)

Yes.

Bob