3. Silent Building with Automake

The “classical” Makefiles generated by automake up to and including version 1.11 have always been very verbose, during build, printing the full command line of every stage. Albeit this is very helpful during debugging, the practise has been criticised, especially as the Linux kernel, and other build systems, defaulted to a “silent rules” approach.

To overcome this criticism, starting from version 1.11 a new option has been made available to generate Makefiles that can actually build with the new silent rules, even though, by default, the old, verbose builds are used. 

test-hellow % make V=1
make  all-am
make[1]: Entering directory `/home/flame/test-hellow'
gcc -DHAVE_CONFIG_H -I.     -g -O2 -MT hellow.o -MD -MP -MF .deps/hellow.Tpo -c -o hellow.o hellow.c
mv -f .deps/hellow.Tpo .deps/hellow.Po
gcc  -g -O2   -o hellow hellow.o
make[1]: Leaving directory `/home/flame/test-hellow'

test-hellow % make V=0
make  all-am
make[1]: Entering directory `/home/flame/test-hellow'
  CC     hellow.o
  CCLD   hellow
make[1]: Leaving directory `/home/flame/test-hellow'

For automake 1.11 and 1.12, a double opt-in is necessary, as it has to be told to generate the silent-capable Makefiles first, after which it's possible to enable said silent rules at the time of build. This has been done because the generated rules are only compatible with the GNU implementation of make, which meant that it would break portability and, for that reason, disable the portability warnings.

The first opt-in is to enable the behaviour, which is done inside configure.ac in either of two methods:

As of version 1.13, though, this opt-in is no longer necessary, as all the Makefiles are generated to support them. The silent-rules option is now a no-op, doing nothing at all, in particular not silencing the portability warnings.

In this guide, the recommended way has always been to use the explicit macro; this has two main advantages: the first is that you can easily make the call conditional to the actual presence of the macro, keeping backward compatibility with automake versions preceding 1.11; the second is that the call can also change the default behaviour of the Makefiles.

Indeed, whether you just enable the feature through either AM_SILENT_RULES, or the silent-rules option, or even if you're using automake 1.13 or later, the default built output will not be silent. The silent rules are turned off by default, and the user has to enable them when building with one of the following two methods:

As was noted above, it is possible to change the default, and make all builds silent unless otherwise requested, through either ./configure --disable-silent-rules or make V=1. To do so, you have to pass the value yes to the AM_SILENT_RULES macro. 

AM_SILENT_RULES([yes])

3.1. Silent Rules and Backward Compatibility

Since the feature of building with silent rules is only available starting from automake 1.11, enabling the feature in configure.ac, through either the macro call or the silent-rules option is going to stop all the older versions from building the project.

If this is actually a desirable situation, you can also add the 1.11 token to AM_INIT_AUTOMAKE to declare that at least version 1.11 of automake is needed for regeneration. See 1.8, 1.9, …, 1.12 .

If, instead, backward compatibility is required, for instance because there are some systems where the code is tested during development that don't have a new enough automake yet, it's quite simple to implement the silent rules support conditionally, by using explicitly the AM_SILENT_RULES macro.

Example 2.3. Using Silent Rules Without Forcing Automake 1.11

AM_INIT_AUTOMAKE([foreign])
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES])

This fragment (the actual important part is the call to m4_ifdef, but it has to go after AM_INIT_AUTOMAKE) will call the silent rules macro only if it's actually defined. On older automake versions, this will not be defined and the whole macro will be skipped.

Note

While this allows for backward compatibility, it is suggested never to keep an overly long backward compatibility, as that increases the number of workarounds and tricks needed to avoid breaking the older versions, as features are implemented and made use of.

As of today, this trick should probably be used only to keep backward compatibility with very old systems where only automake 1.10 is available.


3.2. Custom Silent Rules

While automake has support for silencing all its default rules, when using custom rules you end up outside the scope of the provided support. Adding support for silent rules to custom rules is not exceedingly difficult.

The code that hides the actual command and just replaces it with the CC string is exported in the form of the variable AM_V_CC, and so on replacing the output string. Since most custom rules are used for generating extra files, the AM_V_GEN variable is also available.

Just prefixing the correct variable expansion in front of the rule is enough to support silent rules; the same method explained above allows for selecting the verbose output or the silent one for the custom rules.

Example 2.4. Silent Custom Rule to Generate a File

%-bar.pc: %.pc
        $(AM_V_GEN)$(LN_S) $(notdir $^) $@