When abuild invokes a backend, anything that the backend writes to its standard error will ultimately be written to abuild's standard error, and likewise, anything the backend writes to standard output will end up on abuild's standard output. This makes it possible to use shell redirection for standard output and standard error even when using interleaved or buffered output modes. However, separation of standard output from standard error removes needed context from error messages, so it's very useful to be able to distinguish output lines from error lines when looking at the complete output of a build.

This can be achieved by setting a specific prefix to be prepended to all normal output lines and/or all error output lines. To specify a prefix to be prepended to non-error output lines, use the --output-prefix=prefix option. To specify a prefix to be prefix to error lines, use --error-prefix=prefix. If either of these options is specified and no output mode has been explicitly selected, abuild will use interleaved output mode, even for single-threaded builds. If raw output mode is explicitly selected, then any output or error prefix specifications will be ignored.

To make programmatic distinction of output lines from error lines in abuild's output, it is recommended that you specify output and error prefixes of the same length. To make error messages stand out, you could run abuild with --error-prefix='E   ' --output-prefix='    ' (setting the output prefix to a number of spaces equal in length to the size of the error prefix). This way, you could be sure that all lines as originally created by abuild or its backends would start in the same column of the prefixed output, and that the first column of the prefixed output would contain E for any error or warning. Another way to make error messages stand out would be to omit the error prefix entirely and to specify an output prefix consisting of several space characters. This would cause all output lines to be indented, making it easy to visually scan the build output for error messages. Note that this approach is not unambiguous because you can't tell output lines from error lines that happen to start with several spaces. But for a human reader, it may be more to your preference.