[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 18 Jan 2007 22:13:27 +0100
* 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
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
> 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:
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.
- Re: verbosity, (continued)
- Re: verbosity, Christopher Sean Morrison, 2007/01/15