Yocto-Project

The Yocto Project is a build system for embedded Linux distributions. There are many other build systems out there, such as Buildroot, EmbToolkit, OpenEmbedded, ISAR and many more. More info about YOCTO at https://www.yoctoproject.org/.

Structure

The Structure of a build system looks complicated at first, but the more it is looked at, the easier it gets. This section features some of the ground structure.

BitBake

The most important step in understanding yocto is understanding the API that lies beneath it: Bitbake.

“BitBake is a generic task execution engine that allows shell and Python tasks to be run efficiently and in parallel while working within complex intertask dependency constaints”, so it stands in the user manual.

This means that BitBake is used in the Yocto project to build the Linux image from recipes and bbclasses, making use of parallel processing and still keeping dependency chains. BitBake classes (.bbclass files) are descriptors of different parts of the distribution. In example, there exists a “dpkg.bbclass”, which is a very fundamental class, since almost every recipe in a debian based distro uses dpkg, let it be connman, update frameworks or even the kernel. The class comes with a few base tasks, such as fetch, unpack, patch and dpkg_build.

Those just mentioned tasks are even so basic, that they aren’t even really in the dpkg.bbclass themselves, but in the dpkg-base.bbclass. Bitbake supports not only inheritance, but also appendices (.bbappend files) and include files (.inc). Each of those files has tasks, either implemented in shell:

do_dpkg_build() {
    # shell code here
}

or in python:

python do_dpkg_build() {
    # python code here
}

# or

def do_dpkg_build() {
    # python code here
}

To have a little more understanding of the dpkg task flow, here is an example chart of how it could work: dpkg_flowchart image

Note

The tasks aren’t necessarily running parallel in the parallel drawn sections, but just in an undefined order! If there are enough resources, they will however most likely run parallel.

Since there is so much more going on in Bitbake here is a lot more information about it.

Recipes

A Recipe is (as mentioned above) a description of how a package should be fetched, unpacked, built and deployed. Recipes can be appendices to existing ones (.bbappend) or completely new ones, making use of classes and inheritance.

There are several tasks in a recipe, that can be chained together, or even dependend on other recipes. The chaining is done with adding the task to the queue:

addtask my_task

This command just sets the task in an undefined slot in the queue. To make it run after or before another task, there are the “after” and “before” keyword:

addtask my_task after do_previous_task before do_later_task

Dependencies to other recipes can be set with the DEPENDS variable.

Meta-Layers

A Meta Layer is a collection of recipes, config files and scripts, that together fully implement a certain aspect. The “meta-raspberrypi” Layer for example comes with raspberrypi specific things such as the kernel, bootloader and firmware recipes, in certain cases a partition layout description and license information and documentation.

Every Layer has a “conf” folder with the “layer.conf” file and a “distro” directory, containing all necessary information about the distribution that is being built.

The layer.conf file contains information about compatibility, recipe locations and versioning.

More about implementing an own layer in Yocto can be found here.