Chapter 4. Understanding BitBake

In this chapter, we will initially explore the metadata (the basic concept) and recipes that are used by Poky (the dependencies among them). We will then look at the different ways in which BitBake downloads source code. We will end this chapter by presenting the tasks used by BitBake to get to the creation of the root filesystem image.

BitBake

As presented in Chapter 1, Meeting the Yocto Project, BitBake is a task scheduler (like GNU Make) that parses shell and Python scripts. The code parsed generates and runs tasks (configure, compile, and so on), which are basically sets of steps ordered according to the code's dependencies.

Here are some points taken directly from the BitBake user manual:

• BitBake executes tasks according to the provided metadata, which builds up the tasks. Metadata is stored in recipe (.bb), configuration (.conf), and class (.bbclass) files and provides BitBake with instructions on what tasks to run and the dependencies between those tasks.

• BitBake includes a fetcher library for obtaining source code from various places, such as source control systems or websites.

• The instructions for each unit to be built (such as a piece of software) are known as recipe files and contain all the information about the unit (dependencies, source file locations, checksums, description, and so on).

• BitBake includes a client...

Metadata

The metadata used by BitBake can be in several distinct forms; they are as follows:

• Configuration (.conf) files

• Recipes (.bb and .bbappend files)

• Classes (.bbclass files)

• Include (.inc) files

Configuration

Configuration files, which are denoted by the .conf extension, define various configuration variables that govern the project's build process. These files fall into several areas that define machine configuration options, distribution configuration options, compiler tuning options, general common configuration options, and user configuration options.

Classes

Class files, which are denoted by the .bbclass extension, contain information that is useful to share between metadata files. The BitBake source tree currently comes with one class metadata file called base.bbclass. You can find this file in the classes directory. The base.bbclass file is special since it is always included automatically for all recipes and classes. This class contains definitions for standard basic tasks such as...

Parsing metadata

The first thing BitBake does is parse base configuration metadata (.conf files). Base configuration metadata consists of the bblayers.conf file to determine what layers BitBake needs to recognize, all necessary layer.conf files (one from each layer), and bitbake.conf. The data itself is of various types:

• Recipes: These contain details about particular pieces of software.

• Class data: This provides an abstraction of common build information (for example, how to build a Linux kernel).

• Configuration data: This provides machine-specific settings, policy decisions, and so forth. Configuration data acts as the glue that binds everything together.

The layer.conf files are used to construct key variables such as BBPATH and BBFILES. BBPATH is used to search for configuration and class files under the conf/ and class/ directories, respectively. BBFILES is used to find recipe files (.bb and .bbappend). If there is no bblayers.conf file, it is assumed that the user has set the BBPATH and...

Preferences and providers

Once BitBake has realized the "parsing" step (analyzing all the recipes), it must know how to build the target. It starts by looking through the PROVIDES variable set in the recipe files. The default PROVIDES value for a recipe is its name ( PN ).

Note

PN represents the name of the recipe; PR, the revision of the recipe; and PV, the version of the recipe. For example, when using the recipe rpio-gpio_0.5.9.bb, here is what the values will be:

${PN} = rpi-gpio

${PV} = 0.5.9

Sometimes, a target might have multiple providers. A common example is virtual/kernel, which is provided by each kernel recipe (check out meta-raspberrypi/tree/master/recipes-kernel/linux for further information). Each machine often selects the best kernel provider by using a line similar to the following in the machine configuration file. If we look into this following file (meta-raspberrypi / conf / machine / include /rpi-default-providers.inc), we can see some variables:

# RaspberryPi...

Dependencies

In order to satisfy dependencies, the recipes must declare what they need to have available during the build process.

BitBake use a special mechanism that allows us to list the build-time dependencies and then checks whether all of the rules are satisfied before the build step. For example, if you work with canutils ( http://pengutronix.de/software/socket- can/download/canutils/ ), you have to set this following variable:

DEPENDS = "libsocketcan" 

In this example, CANUTILS needs libsocketcan; therefore, BitBake will start by building the libsocketcan package (and installing the headers into rootfs) before building canutils and linking.

When an application depends on something to run, it is called a runtime dependency (these are packages necessary on the target in order to guarantee proper functioning). In this case, we don't need to set the DEPENDS variable but the RDEPENDS variable in a recipe in order to inform BitBake.

Fetching

The mechanism used by BitBake to fetch source code is internally called the fetcher backend. There are several fetcher backends supported, which can be configured to align user requirements and optimize source code fetching.

BitBake supports several protocols for remote file downloads. The most commonly used are http://, https://, and git://. When BitBake executes the do_fetch task in a recipe, it checks the contents of SRC_URI. We will discover, through the various fetchers, how to proceed based on our need.

The local file fetcher

The local file fetcher submodule handles URLs that begin with file://. The filename you specify within the URL can either be an absolute or relative path to a file. For example, with a file called my_source_file.c, we must write the SRC_URI attribute's content like this:

SRC_URI = "file://my_source_file.c" 

The HTTP fetcher

The HTTP fetcher obtains files from web servers. Internally, the fetcher uses the wget utility.

In this example, we will use the...

Understanding BitBake's tasks

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

Summary

In this chapter, we discovered most of BitBake's functionalities. We also learned how BitBake works in order for us to generate some packages for our Raspberry Pi.

In the next chapter, we will learn how to develop within the Yocto Project. We will write recipes, create SDKs, and more.