The Yocto Project builds everything from source. When you create a new project, only the configuration files are created. The build process then compiles everything from scratch, including the cross-compilation toolchain and some native tools important for the build.
This process can take a long time, and the Yocto Project implements a shared state cache mechanism that is used for incremental builds with the aim to build only the strictly necessary components for a given change.
For this to work, the build system calculates a checksum of the given input data to a task. If the input data changes, the task needs to be rebuilt. In simplistic terms, the build process generates a run script for each task that can be checksummed and compared. It also keeps track of a task's output, so that it can be reused.
A package recipe can modify the shared state caching to a task, for example, to always force a rebuild by marking it as nostamp. A more in-depth explanation of the shared state cache mechanism can be found in the Yocto Project Reference Manual at http://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html.
By default, the build system will use a shared state cache directory called sstate-cache on your build directory to store the cached data. This can be changed with the SSTATE_DIR configuration variable in your conf/local.conf file. The cached data is stored in directories named with the first two characters of the hash. Inside, the filenames contain the whole task checksum, so the cache validity can be ascertained just by looking at the filename. The build process set scene tasks will evaluate the cached data and use it to accelerate the build if valid.
When you want to start a build from a clean state, you need to remove both the sstate-cache directory and the tmp directory.
You can also instruct BitBake to ignore the shared state cache by using the --no-setscene argument when running it.
It's a good practice to keep backups of clean shared state caches (for example, from a build server), which can be used in case of shared state cache corruption.
Sharing a shared state cache is possible; however, it needs to be approached with care. Not all changes are detected by the shared state cache implementation, and when this happens, some or all of the cache needs to be invalidated. This can cause problems when the state cache is being shared.
The recommendation in this case depends on the use case. Developers working on Yocto metadata should keep the shared state cache as default, separated per project.
However, validation and testing engineers, kernel and bootloader developers, and application developers would probably benefit from a well-maintained shared state cache.
To configure an NFS share drive to be shared among the development team to speed up the builds, you can add the following to your conf/local.conf configuration file:
SSTATE_MIRRORS ?= "\
file://.* file:///nfs/local/mount/sstate/PATH"To configure shared state cache sharing via HTTP, add the following to your conf/local.conf configuration file:
SSTATE_MIRRORS ?= "file://.* http://example.com/some_path/sstate-cache/PATH"
The expression PATH in these examples will get substituted by the build system with a directory named with the hash's first two characters.