Trying to trace or to debug a build almost always incurs a performance penalty. The most important tool is included by default but only enabled when calling waf with the verbose option (waf -v). Others are present in the waflib/extras folder and are not included by default. They can be added to the waf file or downloaded by calling "waf update --files=parallel_debug,why"

The module "why" provides some more output to help understanding why files are being compiled. It requires a fresh recompilation though, and inflates the cache files significantly as it stores some data between the builds. The output will display the task signatures and the reason of the execution:

12:26:20 /comp/waf/demos/c> ./waf build --zones=task
Waf: Entering directory `/disk/comp/waf/demos/c/build'
12:26:21 task -> Task must run                      : c3490b5e8498da72aef5a9f645d72276 39da3e173d11cdbb273cda14856dbb6a
12:26:21 task -> * Source file or manual dependency : 3d3fde4f5fc0124efdba8e94e1d216f8 5e4ef70cc1618412ef9975baab0157c1
[12/15] c: program/main.c -> build/program/main.c.1.o
Waf: Leaving directory `/disk/comp/waf/demos/c/build'
'build' finished successfully (0.089s)

For performance debugging, the module parallel_debug creates pictures representing when tasks are executed during the build. The diagrams show how well the build can be distributed, and therefore how fast the build can be. Generating the diagrams incurs a minor performance penalty, which is the reason why this tool is not included by default in the waf file.

It has been updated recently to improve the layout, now tooltips are present in the svg output file. Follow the links to consult the diagrams of the Samba 4 developer build for 2 processors and for 8 processors.