6.4. The Task List

-6.4. The Task List

- 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. -

Note

- Some tasks are marked as "nostamp" tasks. - No timestamp file is created when these tasks are run. - Consequently, "nostamp" tasks are always rerun. -