Chapter 20. Controlling and Processing Abuild's Output

When examining the output of a large build, it is desirable to be
able to scan the output of the build to look for errors and
warnings, and even to be able to associate specific lines of
output with the build items that produced them. In versions of
abuild prior to 1.1.3, the output of a multithreaded build would
consist of outputs from the builds of multiple build items all
interleaved with each other in arbitrary ways. This would make
the output virtually impossible to parse programmatically and even
tricky for a human reader to fully understand. This chapter
introduces features that help to improve the usability of
abuild's output. They are most useful for multithreaded builds,
but in some cases, they can help with single-threaded builds as
well.

20.1. Introduction and Terminology

When abuild is used to perform a build, the overall build
process consists of several phases: a
check phase, a build phase, and a summary phase. In the check
phase, abuild reads and validates
Abuild.conf files, performs integrity
checks, and so forth. In the build phase, abuild walks through
the dependency graph and invokes backend processes to perform the
actual build steps. After the build phase is complete, the
summary phase includes a summary of any failures as well as an
indication of elapsed time.

During the build phase, abuild invokes various backend programs
to individually build each item on each of its platforms. For
purposes of discussion, we refer to those individual builds as
jobs. A job always corresponds to a
specific build item being built on a specific platform.

When abuild invokes backend processes to do the actual build
steps, it may either capture the output of the backend processes
or it may let the backend processes inherit standard input,
standard output, and standard error from abuild itself. We
refer to the way in which abuild handles the output of its
backend programs as its output mode.