's build logging

Logging overview
Logging is a feature whereby the output from every command that runs is saved to a file for examination later, if necessary. This is done because it is often necessary to have the output of these programs when there is a build failure, because there are so many reasons why a build can fail in the first place.

Logging directory layout
The logs are always stored under the log directory. The destination of the log directory is controlled by the log-dir option, which defaults to ${source-dir}/log (where ${source-dir} is the value of the source-dir option. The in rest of this section, this value will be referred to as ${log-dir}).
Under ${log-dir}, is a set of directories, one for every time that was run. Each directory is named with the date, and the run number. For instance, the second time that is run on May 26, 2004, it would create a directory called 2004-05-26-02, where the 2004-05-26 is for the date, and the -02 is the run number.
For your convenience, will also create a link to the logs for your latest run, called latest. So the logs for the most recent run should always be under ${log-dir}/latest.
Now, each directory for a run will itself contain a set of directories, one for every module that tries to build. Also, a file called build-status will be contained in the directory, which will allow you to determine which modules built and which failed.
If a module itself has a submodule (such as extragear/multimedia, playground/utils, or KDE/kdelibs), then there would actually be a matching layout in the log directory. For example, the logs for KDE/kdelibs after the last run would be found in ${log-dir}/latest/KDE/kdelibs, and not under ${log-dir}/latest/kdelibs.
In each module log directory, you will find a set of files for each operation that performs. If updates a module, you may see filenames such as git-checkout-update.log (for a module checkout or when updating a module that has already been checked out). If the configure command was run, then you would expect to see a configure.log in that directory.
If an error occurred, you should be able to see an explanation of why in one of the files. To help you determine which file contains the error, will create a link from the file containing the error (such as build-1.log to a file called error.log).
The upshot to all of this is that to see why a module failed to build after your last , the file you should look at first is ${log-dir}/latest/module-name/error.log.
If the file error.log is empty (especially after an installation), then perhaps there was no error. Some of the tools used by the build system will sometimes mistakenly report an error when there was none.
Also, some commands will evade 's output redirection and bypass the log file in certain circumstances (normally when performing the first checkout), and the error output in that case is not in the log file but is instead at the or terminal where you ran .