Re: verbosity

[Jason Kraftcheck]

Ralf Wildenhues wrote:
> * Jason Kraftcheck wrote on Thu, Jan 18, 2007 at 07:10:19PM CET:
>> Ralf Wildenhues wrote:
>>> <http://lists.gnu.org/archive/html/automake-patches/2006-08/msg00024.html>
>> I don't understand why this is such a controversial issue.
> 
> Then
> - you must not have had to deal with Makefile.in files several megabytes
>   in size,

No, I haven't.  The largest I've had was about half a megabyte.  I still
don't think prefixing a few commands in rules would make a significant
difference.  In the 236k Makefile that I have right now, it would add less
than 1.3k (0.5%).  If a shorter variable name was chosen, such as $X, it
would be more like 0.3k (0.1%).

> - maybe you haven't had to deal much with bad user bug reports that
>   provide far too little information to be valuable.
> 

Certainly, I have.  Any issues regarding failures to build my package
would come to me, not you, so why would it bother you (or any automake
developer) if I got more incomplete bug reports because I reduced the
amount of make output?  Anyway, it was my intention to have a configure
option to reduce the output that would not be enabled by default, so users
of my package will, by default, see the verbose make output.

If you are referring to bug reports from users of automake, I think such
bug reports that are due to the suppression of make output would be
curtailed by having the default be the current verbose output and making
changing that behavior require some minimal understanding of what's going
on (e.g. redefining a variable as I described.)

> I don't know how many times I've been wanting to stand in front of bug
> reporters and literally slap them with
> <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
> until it comes out of their nose, after the second mail of mine only
> asking for more details.
> 
> But then again, most if not all developers I know have an editor that
> does near-perfect postprocessing of compiler warning/error messages.
> Heck, where missing, I've even sent patches to the Vim maintainer.
> 

Well, I don't use such an editor.  Requiring a separate tool to process
what should be human-readable output implies that there's room for
improvement in said output.  And wouldn't using a filter on the output
potentially allow for the same bad bug reports you suggest might result
from less verbose make output?

I am currently tasked with fixing a hand-rolled build system that has a
plethora of deficiencies.  Re-writing the build system to use GNU
autotools seems to address all the deficiencies.  However, I still have to
'sell' this solution to other developers on the project.  Passing on your
suggestion of 'use emacs to build' won't fly.

> (Yes, some of this reasoning is about this controversy in general, not
> applicable in the above case; but it's not me you should convince about
> Tommy's patch.)
> 

I know.  But your opinion certainly carries more weight than mine.
Anyway, I've been CC'ing the automake list with the hope that whoever is
responsible for such decisions sees the discussion.

>> Just have
>> automake prefix all commands in rules that are not already prefixed with @
>> or - with $(PREFIX) (or some other variable.)  Have default for PREFIX be
>> empty so the current behavior is unchanged.  If someone wants to change
>> the output, they can redefine it with something like PREFIX="@echo
>> 'building $@ ...'; ".  Minimal makefile 'bloat', no change to the default
>> behavior, and the flexibility for the output to be whatever is desired.
> 
> I think the patch Tommy suggested was pretty similar to this
> description, but it did not address the concerns raised.

Perhaps I'll try putting together a less invasive patch (just add the
PREFIX stuff) and post it to the -patches list.

thanks,

- jason