Based on the generated list of providers and the dependency information,
BitBake can now calculate exactly what tasks it needs to run and in what
order it needs to run them.
The build now starts with BitBake forking off threads up to the limit set in the
BB_NUMBER_THREADS
variable.
BitBake continues to fork threads as long as there are tasks ready to run,
those tasks have all their dependencies met, and the thread threshold has not been
exceeded.
It is worth noting that you can greatly speed up the build time by properly setting
the BB_NUMBER_THREADS
variable.
See the
"Building an Image"
section in the Yocto Project Quick Start for more information.
As each task completes, a timestamp is written to the directory specified by the
STAMP
variable (usually
build/tmp/stamps/*/
).
On subsequent runs, BitBake looks at the /build/tmp/stamps
directory and does not rerun
tasks that are already completed unless a timestamp is found to be invalid.
Currently, invalid timestamps are only considered on a per
.bb
file basis.
So, for example, if the configure stamp has a timestamp greater than the
compile timestamp for a given target, then the compile task would rerun.
Running the compile task again, however, has no effect on other providers
that depend on that target.
This behavior could change or become configurable in future versions of BitBake.