* 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
