Re: verbosity

[Ralf Wildenhues]

* Jason Kraftcheck wrote on Thu, Jan 18, 2007 at 09:50:31PM CET:
> Ralf Wildenhues wrote:

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

Thank you for providing these numbers.  That should help.
However very short variable names are out of the question; Automake must
respect namespace; see automake/HACKING:Naming in the CVS tree.

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

Because sometimes Automake developers are also Automake users while
being developers of something completely different?  ;-)
(Also you'd be surprised at some package bugs that get reported to
bug-auto*.)

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

Ahh, redefining a variable portably that was already initialized in the
Makefile is not easy in portable make:
<http://www.gnu.org/software/autoconf/manual/html_node/Macros-and-Submakes.html>
Requiring 'make -e' in all projects is infeasible, says experience.

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

FWIW, I don't think it should be human-readable output.  It should be
parseable and also human-readable.  But I digress...

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

Agreed; point well taken.

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

OK.  Maybe Tommy's patch will then.

> Anyway, I've been CC'ing the automake list with the hope that whoever is
> responsible for such decisions sees the discussion.

I hope Alexandre will eventually have some more time for Automake again.

Cheers,
Ralf