The tricks and idioms for silencing make described in the
previous section can be useful from time to time, but we’ve seen that
they all have their serious drawbacks and limitations. That’s why
automake provides support for a more advanced and flexible way of
obtaining quieter output from make (for most rules at least).
To give the gist of what Automake can do in this respect, here is a simple
comparison between a typical make output (where silent rules
are disabled) and one with silent rules enabled:
% cat Makefile.am
bin_PROGRAMS = foo
foo_SOURCES = main.c func.c
% cat main.c
int main (void) { return func (); } /* func used undeclared */
% cat func.c
int func (void) { int i; return i; } /* i used uninitialized */
The make output is by default very verbose. This causes warnings
from the compiler to be somewhat hidden, and not immediate to spot.
% make CFLAGS=-Wall
gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\" ...
-DPACKAGE_STRING=\"foo\ 1.0\" -DPACKAGE_BUGREPORT=\"\" ...
-DPACKAGE=\"foo\" -DVERSION=\"1.0\" -I. -Wall -MT main.o
-MD -MP -MF .deps/main.Tpo -c -o main.o main.c
main.c: In function ‘main’:
main.c:3:3: warning: implicit declaration of function ‘func’
mv -f .deps/main.Tpo .deps/main.Po
gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\" ...
-DPACKAGE_STRING=\"foo\ 1.0\" -DPACKAGE_BUGREPORT=\"\" ...
-DPACKAGE=\"foo\" -DVERSION=\"1.0\" -I. -Wall -MT func.o
-MD -MP -MF .deps/func.Tpo -c -o func.o func.c
func.c: In function ‘func’:
func.c:4:3: warning: ‘i’ used uninitialized in this function
mv -f .deps/func.Tpo .deps/func.Po
gcc -Wall -o foo main.o func.o
Clean up, so that we can rebuild everything from scratch.
% make clean
test -z "foo" || rm -f foo
rm -f *.o
Silent rules enabled: the output is minimal but informative.
The warnings from the compiler stick out very clearly.
% make V=0 CFLAGS=-Wall
CC main.o
main.c: In function ‘main’:
main.c:3:3: warning: implicit declaration of function ‘func’
CC func.o
func.c: In function ‘func’:
func.c:4:3: warning: ‘i’ used uninitialized in this function
CCLD foo
Also, in projects using Libtool, the use of silent rules can
automatically enable libtool’s --silent option:
% cat Makefile.am lib_LTLIBRARIES = libx.la % make # Both make and libtool are verbose by default. ... libtool: compile: gcc -DPACKAGE_NAME=\"foo\" ... -DLT_OBJDIR=\".libs/\" -I. -g -O2 -MT libx.lo -MD -MP -MF .deps/libx.Tpo -c libx.c -fPIC -DPIC -o .libs/libx.o mv -f .deps/libx.Tpo .deps/libx.Plo /bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -o libx.la -rpath /usr/local/lib libx.lo libtool: link: gcc -shared .libs/libx.o -Wl,-soname -Wl,libx.so.0 -o .libs/libx.so.0.0.0 libtool: link: cd .libs && rm -f libx.so && ln -s libx.so.0.0.0 libx.so ... % make V=0 CC libx.lo CCLD libx.la
For Automake-generated Makefiles, the user may influence the
verbosity at configure run time as well as at make
run time:
configure will cause
build rules to be less verbose; the option --disable-silent-rules
will cause normal verbose output.
make run time, the default chosen at configure
time may be overridden: make V=1 will produce verbose output,
make V=0 less verbose output.
Unfortunately, if V is assigned a value other than 0 or 1,
errors will result. This is problematic when a third-party program or
library is built in the same tree and also uses the make variable
V, with different values. The best workaround is probably to
set AM_V_P=true (or similar), either on the make command line
or in the V-using project’s Makefile.am. (For more
discussion, see https://bugs.gnu.org/20077.)
Silent rules are disabled by default; the user must enable them
explicitly at either configure run time or at make
run time. We think that this is a good policy, since it provides the
casual user with enough information to prepare a good bug report in
case anything breaks.
Notwithstanding those rationales, developers who want to enable silent
rules by default in their own packages can do so by calling
AM_SILENT_RULES([yes]) in configure.ac.
Analogously, users who prefer to have silent rules enabled by default
for everything on their system can edit their config.site file
to make the variable enable_silent_rules default to ‘yes’.
This still allows disabling silent rules at configure time
and at make time.
To work best, the current implementation of this feature normally uses
nested variable expansion ‘$(var1$(V))’, a Makefile
feature that is not required by POSIX 2008 but is widely supported in
practice. On the rare make implementations that do not
support nested variable expansion, whether rules are silent is always
determined at configure time, and cannot be overridden at make time.
Future versions of POSIX are likely to require nested variable
expansion, so this minor limitation should go away with time.
To extend the silent mode to your own rules, you have a few choices:
AM_V_GEN as a prefix to
commands that should output a status line in silent mode, and
AM_V_at as a prefix to commands that should not output anything
in silent mode. When output is to be verbose, both of these variables
will expand to the empty string.
@, and then use
the predefined variable AM_V_P to know whether make is being run
in silent or verbose mode; adjust the verbose information your recipe
displays accordingly. For example:
generate-headers:
@set -e; \
... [commands defining shell variable '$headers'] ...; \
if $(AM_V_P); then set -x; else echo " GEN [headers]"; fi; \
rm -f $$headers && generate-header --flags $$headers
AM_V_P is (must be) always set to a simple command, not needing
shell quoting, typically either : or true or
false.
AM_V_GEN, say a string ‘PKG-GEN’:
pkg_verbose = $(pkg_verbose_@AM_V@)
pkg_verbose_ = $(pkg_verbose_@AM_DEFAULT_V@)
pkg_verbose_0 = @echo PKG-GEN $@;
foo: foo.in
$(pkg_verbose)cp $(srcdir)/foo.in $@
Even when silent rules are enabled, the --no-print-directory
option is still required with GNU make if the
“Entering/Leaving directory …” messages are to be elided.