Continuing the ongoing saga…
Using the --silence hackery from Jacob Berkman I found a way to finally STFU at least libtool. In your configure.ac add:
changequote(,)dnl LIBTOOL="\\$(QUIET_LT)${LIBTOOL}" changequote([,])dnl
Add a Makefile.decls file to the root of your project, containing:
QUIET_LT = @echo ' ' LIBTOOL $@;
And include it in every Makefile.am:
include $(top_srcdir)/Makefile.decls
This will silence all libtool invocations; you can make this all conditional, obviously: just sorround the QUIET_* declarations with if VARIABLE...endif and define VARIABLE using AM_CONDITIONAL in your configure template.
Now, I’ll just have to find a way to make gcc shut up ((no, you cannot redefine CC, as it will be invoked by libtool as well)), and so the saga will end with a third chapter.
(continuing) The wasted build cycle is why I am not satisfied with there being some way to turn off the output suppression, but insist that the default — no, only — behavior of the Makefile should be to print all the commands exactly as executed.
So, since I’m being all down on your perfectly reasonable desire for build logs where the actual compiler diagnostics stand out more, let me offer an alternative. What you should be doing is writing a wrapper for ‘make’ which runs its output through a filter that substitutes the short abbreviations you want for each unwieldy command you don’t like. This only affects your personal view of the build, so it doesn’t have any of the problems I am concerned with. And it also avoids having to figure out how to suppress the command lines for each tool individually.
I see I never answered your questions from last time (sorry) so let me try again to explain why this is a terrible idea…
Yes, what you’re doing leaves the compiler diagnostic messages intact, but there are failure modes, especially of automated build systems, where you must be able to see the command lines as well in order to fix the problem.
An actually-happened-to-me example: GCC used to hide the exact commands for some moderately complicated shell operations embedded in the makefile. These made … some assumption I don’t remember anymore … which was true for the typical build environment, but untrue in an automated build system used by a company I consulted for, that was (a) very slow, (b) distributed across several dozen machines in a desperate attempt to compensate for the slowness, and (c) inaccessible to the engineers, because the project managers didn’t trust them to check all their changes into ClearCase otherwise. For failed builds, all we could have was the ‘make’ output.
If I remember correctly, I wasted four or five build cycles on experiments — each taking not quite long enough to get anything else done in the meantime — before I gave up and ripped out all the @ signs in the Makefile, which made the cause of the problem obvious in the build logs and the fix straightforward.
Now you might say that this is a scenario from a dysfunctional, dying company, and one involving GCC, whose makefiles can be used to scare small children; your software won’t ever be built in such an awkward environment, and won’t have makefiles like that anyway. But the Debian build-daemon network works exactly the same way as the build system at this company. You can’t do trial builds on it, you can only make new package uploads; you can’t see how the systems are configured; if a build fails, all you get is the logs. And Automake’s compiler invocations are already bad enough to make me worry about this kind of problem —
If
$(srcdir)is wrong, or if somehow a file namedroster_delta.cchas gotten created in the build directory when it shouldn’t have, this is going to go off the rails. And if all I can see in the build logs isthen I’m hosed, aren’t I? And I get to waste at least one build cycle digging through your makefiles to find out what crazy thing you’ve done to suppress the real command lines and turn it off.
You might want to turn off smart quotes for this entry so people don’t copy and paste them by accident.