Chapter 20. Controlling and Processing Abuild's Output

Table of Contents

20.1. Introduction and Terminology
20.2. Output Modes
20.3. Output Prefixes
20.4. Parsing Output
20.5. Caveats and Subtleties of Output Capture

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.