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
