The default behavior of Poky is to build everything from scratch unless BitBake determines that a recipe does not need to be rebuilt. The main advantage of building everything from scratch is that the final result is fresh and there is no risk of previous data causing problems. However, rebuilding everything requires computational time and resources.

The strategy to determine whether a recipe must be rebuilt is complex. Basically, BitBake tries to track as much information as possible about every task, variable, and code used in the build process. BitBake then generates a checksum for all the involved information for every task.

Poky uses all this information provided by BitBake to store snapshots of those tasks as a set of packaged data generated in a cache, which is called the shared state cache (sstate-cache). This cache wraps the contents of each task output in packages stored in the SSTATE_DIR directory. Whenever BitBake prepares to run a task, it first checks the existence of an sstate-cache package that matches. If the package is present, BitBake uses the prebuilt built package.

This is a very simple view of the whole shared state mechanism, which is quite a complex piece of code. For an advanced overview, it is advised that the Shared State Cache section of the Yocto Project Reference Manual is read. Please visit the following link for more information: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html.

When using Poky for several builds, we must bear in mind that sstate-cache needs to be cleaned from time to time since it keeps growing as more and more cached data is added for every build. There is an easy way of cleaning it, as follows:

$ ./scripts/sstate-cache-management.sh --remove-duplicated -d --cache-dir=<path to sstate-cached>

This removes the duplicated and old data from the cache.