Poky contains a great amount of metadata spread over machine definition files, classes, and recipes. This metadata covers everything from simple applications to full graphical stacks and frameworks. BitBake has the ability to load metadata from multiple places, and those multiple metadata sets are known as metadata layers.

The biggest strength of using layers is the ability to split the metadata into logical units, which enables users to pick only the metadata set needed for the project. Using metadata layers improves the reuse of code and the ability to share work across different teams, communities, and vendors, increasing the code quality of the Yocto Project community as multiple entities are working together on the same metadata.

We may want to configure the system for different reasons, such as the need to enable/disable a feature or change build flags to enable architecture-specific optimizations. These are examples of customizations that can be done using layers.

In addition, when creating our own custom project environment, instead of changing recipes and configuration files, and modifying files in the Poky layer, we ought to organize the metadata in different layers. The more separated the organization is, the easier it is to reuse the layers in future projects; because of this fact, the Poky source code itself is also separated into different layers. It has three layers included by default, as we can see in the output of the following command line:

$ bitbake-layers show-layers

The result can be seen in the following screenshot:

The command-line output shows the following three important properties of any layer:

• Name: This usually starts with the meta string.
• Path: This is important when we want to add an additional layer in our project that is appended to the BBPATH variable.
• Priority: This is the value used by BitBake to decide which recipe to use and the order in which the .bbappend files should be joined. It means that if two layers include the same recipe file (.bb), the one with the highest priority is used. In the case of .bbappen, every .bbappend file is included in the original recipe, and the layer priority determines the order of inclusion, so the .bbappend files within the highest priority layers are appended first, followed by the others.

Poky is arranged in three individual layers, coincidentally the three types available. The meta layer is the OpenEmbedded Core metadata, which contains the recipes, classes, and the QEMU machine configuration files. It is a software layer.

A software layer includes only applications or configuration files for applications and can be used on any architecture. There is a huge list of software layers. To name only a few, we have meta-java, meta-qt5, and meta-browser. The meta-java layer provides Java runtime and SDK support, the meta-qt5 layer includes Qt5 support, and meta-browser supports several web browsers such as Firefox and Chrome.

The meta-yocto-bsp layer is the Poky reference board support package (BSP) layer. It contains machine configuration files and recipes to configure packages for the machines. As it is a reference BSP layer, it can be used as an example.

The meta-poky layer is the Poky reference distribution layer. It contains a distribution configuration used in Poky by default; this is an example of a distribution file. This default distribution is described in the poky.conf file, and it is widely used for testing products. However, sometimes your product may have special needs, and changes in build/conf/local.conf will need to be made as required.

We should not rely on it to set package versions, providers, and the system features for products, but use it just as a shortcut for testing purposes during development.

The most adequate and maintainable solution is to create a distribution layer to place the distribution definition file. This configuration allows any build to be reproduced afterward. We can use one distribution layer for all the distributions we have, or we can create one new layer for every new distribution; the best approach depends on your project's needs.