The bitbake command is the primary interface to the BitBake tool. This chapter presents the bitbake command syntax and provides several execution examples.
For example, if you want to build a specific recipe, run the following command:
$ bitbake <recipe>
BitBake runs a set of scheduled tasks. When we wish to run a specific task, we can use the following command:
$ bitbake <recipe> -c <task>
If you want to clean a specific package (spitools
, for example), you just have to run this:
$ bitbake spitools -c clean
To list the tasks defined for a recipe, we can use the following command:
$ bitbake <recipe> -c listtasks
Here is a description of BitBake tasks:
- do_fetch: The first step when building a recipe is fetching the required source. This is done using the fetching backend feature we discussed previously. It is important to point out that fetching source or a file does not mean it is a remote source. In fact, every file required during the recipe build must be fetched so that it is made available in the
WORKDIRdirectory.All downloaded content is stored in the download folder (the
DL_DIRvariable), so all external source code is cached to avoid redownloading it every time we need the same source.
- do_unpack: The natural subsequent task after the
do_fetchtask isdo_unpack. It is responsible for unpacking source code or checking the requested revision or branch in case the referenced source uses an SCM system.
- do_patch: Once the source code has been properly unpacked, BitBake initiates the process of adapting it. This is done by the
do_patchtask. Every file fetched bydo_fetchthat has the.patchextension is assumed to be a patch to be applied. This task applies the list of required patches.The process of applying a patch uses the
Svariable, which points to the source code. The default value used forSis ${WORKDIR}/${PN}-${PV}, and it is used for thedo_patch,do_configure,do_compile, anddo_installtasks.
- do_configure, do_compile, and do_install: The
do_configure,do_compile, anddo_installtasks are performed in this order. Some recipes may omit one task or another. It is important to note that the environment variables defined in the tasks are different from one task to another.Tasks vary a lot from one recipe to another. Poky provides a rich collection of predefined tasks in the classes, which ought to be used when possible. For example, when the
Autotoolsclass is inherited by a recipe, it provides a known implementation for thedo_configure,do_compile, anddo_installtasks.
- do_package: The
do_packagetask splits the files installed by the recipe into logical components, such as debugging symbols, documentation, and libraries. Thedo_packagetask ensures that files are split up and packaged correctly.
One of the most common uses of Poky is the generation of the root filesystem. The rootfs image should be seen as a ready-to-use root filesystem for a target. The rootfs is basically a directory with the desired packages installed. The list of packages to be installed into rootfs is defined by a union of packages listed by IMAGE_INSTALL and the packages included by IMAGE_FEATURES.
We will learn more about the process and its contents in Chapter 5 , Creating, Developing, and Deploying on the Raspberry Pi.