The description of tasks so far assumes that BitBake needs to build everything and no available prebuilt objects exist. BitBake does support skipping tasks if prebuilt objects are available. These objects are usually made available in the form of a shared state (sstate) cache.
SSTATE_DIR
and
SSTATE_MIRRORS
variables.
The idea of a setscene task (i.e
do_
taskname
_setscene
)
is a version of the task where
instead of building something, BitBake can skip to the end
result and simply place a set of files into specific
locations as needed.
In some cases, it makes sense to have a setscene task
variant (e.g. generating package files in the
do_package_write_*
task).
In other cases, it does not make sense (e.g. a
do_patch
task or a
do_unpack
task) since the work involved would be equal to or greater
than the underlying task.
In the build system, the common tasks that have setscene
variants are
do_package
,
do_package_write_*
,
do_deploy
,
do_packagedata
,
and
do_populate_sysroot
.
Notice that these tasks represent most of the tasks whose
output is an end result.
The build system has knowledge of the relationship between
these tasks and other preceding tasks.
For example, if BitBake runs
do_populate_sysroot_setscene
for
something, it does not make sense to run any of the
do_fetch
,
do_unpack
,
do_patch
,
do_configure
,
do_compile
, and
do_install
tasks.
However, if do_package
needs to be
run, BitBake needs to run those other tasks.
It becomes more complicated if everything can come
from an sstate cache because some objects are simply
not required at all.
For example, you do not need a compiler or native tools,
such as quilt, if nothing exists to compile or patch.
If the do_package_write_*
packages
are available from sstate, BitBake does not need the
do_package
task data.
To handle all these complexities, BitBake runs in two phases. The first is the "setscene" stage. During this stage, BitBake first checks the sstate cache for any targets it is planning to build. BitBake does a fast check to see if the object exists rather than a complete download. If nothing exists, the second phase, which is the setscene stage, completes and the main build proceeds.
If objects are found in the sstate cache, the build system works backwards from the end targets specified by the user. For example, if an image is being built, the build system first looks for the packages needed for that image and the tools needed to construct an image. If those are available, the compiler is not needed. Thus, the compiler is not even downloaded. If something was found to be unavailable, or the download or setscene task fails, the build system then tries to install dependencies, such as the compiler, from the cache.
The availability of objects in the sstate cache is
handled by the function specified by the
BB_HASHCHECK_FUNCTION
variable and returns a list of available objects.
The function specified by the
BB_SETSCENE_DEPVALID
variable is the function that determines whether a given
dependency needs to be followed, and whether for any given
relationship the function needs to be passed.
The function returns a True or False value.