27.11 Debugging Make Rules
The rules and dependency trees generated by automake
can get rather
complex, and leave the developer head-scratching when things don’t work as
expected. Besides the debug options provided by the make
command (see
Options Summary in The GNU Make Manual ), here’s a couple of
further hints for debugging makefiles generated by automake
effectively:
- If less verbose output has been enabled in the package with the use of silent rules (see Automake Silent Rules ), you can use
make V=1
to see the commands being executed. make -n
can help show what would be done without actually doing it. Note however, that this will still execute commands prefixed with ‘ + ’, and, when using GNUmake
, commands that contain the strings ‘ $(MAKE) ’ or ‘ ${MAKE} ’ (see Instead of Execution in The GNU Make Manual ). Typically, this is helpful to show what recursive rules would do, but it means that, in your own rules, you should not mix such recursion with actions that change any files. 8 Furthermore, note that GNUmake
will update prerequisites for the Makefile file itself even with -n (see Remaking Makefiles in The GNU Make Manual ).make SHELL="/bin/bash -vx"
can help debug complex rules. See The Make Macro SHELL in The Autoconf Manual , for some portability quirks associated with this construct.echo 'print: ; @echo "$(VAR)"' | make -f Makefile -f - print
can be handy to examine the expanded value of variables. You may need to use a target other than ‘ print ’ if that is already used or a file with that name exists.- http://bashdb.sourceforge.net/remake/ provides a modified GNU
make
command calledremake
that copes with complex GNUmake
-specific Makefiles and allows to trace execution, examine variables, and call rules interactively, much like a debugger.
here are three command-line options I find most useful for debugging:
--just-print
--print-data-base
--warn-undefined-variables