Table of Contents
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.
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.