5. Terms, Concepts, Idioms

Following is a slightly extended list of terms, concepts and definitions users new to the Yocto Project development environment might find helpful. While some of these terms are universal, the list includes them just in such case. A more or less completed version of the list can be found on the following website: Yocto Project Terms

Terms overall

  1. Git Repo (repo): The collection manager that Google has built on top of Git to help manage multiple Git repositories, does the uploads to Gerrit and automates the Android system image development workflow. The repo command is an executable Python script that you can put anywhere in your path. → https://gerrit.googlesource.com/git-repo/

  2. BitBake: The Task executor and scheduler used by the Build System to build Images. The bitbake command is part of an fancy Python and Bash environment around the BitBake project. → BitBake, or Yocto Components and Tools → BitBake, or BitBake User Manual

  3. Metadata: The files that BitBake parses when building an Images. In general, Metadata provides Recipes, Classes and Configuration Files. → Metadata, or BitBake User Manual → Overview → Introduction

  4. OE-Core: A core set of Metadata originating with OpenEmbedded that is shared between OE and the Yocto Project. → OpenEmbedded-Core (OE-Core), or Yocto Components and Tools → OE-Core, or OE Wikipedia

  5. Poky: The reference distribution of the Yocto Project. It contains the Build System (BitBake and OE-Core) as well as a set of Metadata to get you started building your own distro. → Poky, or Yocto Components and Tools → Poky, or Yocto Reference Distribution

Terms internal

  1. Layer: A collection of Recipes representing the core, a Board Support Package, an application stack, or any other 3rd party contributions. Layers are hierarchical in their ability to override previous specifications. → Layer, or in Concept

  2. Image: An artifact of the BitBake build process given a collection of Recipes and related Metadata. Images are the binary output that run on specific target architecture. → Image, or in Concept, or in Reference

  3. Package: Refers to a Recipe’s packaged output produced by BitBake (i.e. a “baked recipe”). A Package is generally the compiled binaries produced from the Recipe’s sources. You “bake” any “bin” by running it through BitBake. → Package

  4. Package Groups: Arbitrary group of software Recipes. You use Package Groups to hold Recipes that, when built, usually accomplish a single Task. For example, Package Groups could contain the Recipes for a company’s proprietary or value-add software. → Package Groups

  5. Task: A unit of execution for BitBake (e.g. do_fetch, do_patch, do_compile, and so forth). → Task, or in Reference

Metadata

  1. Classes: Files with the .bbclass file extension that provided for logic encapsulation and inheritance so that commonly used patterns can be defined once and then easily used in multiple Recipes. → Classes, or in Concept, or in Reference

  2. Recipes: Files with the .bb file extension have a set of instructions for building Packages or Package Groups or Images and describes where you get source code, which patches to apply, how to configure the source, how to compile it and so on. It also describe dependencies for libraries or for other Recipes. Recipes represent the logical unit of execution. → Recipe, or in Concept

  3. Append Files: Files with the .bbappend file extension that append build information to a Recipe. The Build System respects every Append file to have a corresponding Recipe (.bb) file. → Append Files

  4. Configuration Files: Configuration information in various → Configuration File, or in Concept

Features

Features provide a mechanism for:

  1. working out which Packages or Package Groups should be included in the generated Image, typically configured in Image Recipes and their related Classes → Image Features

  2. distributions Configuration Files can select which features they want to support → Distro Features

  3. machine Configuration Files specifies the hardware functions that will be available for a given machine → Machine Features

  4. backward and inter-layer compatibility for special (historical) cases → Feature Backfilling

../_images/features.svg

Figure 5.1 Yocto Build System Features and their interaction

Idioms

  1. Build System: The build system specific to the Yocto Project based on the project Poky, which uses BitBake as the Task executor.

  2. Source Directory: Refers to the directory structure created as a result of creating a local copy of the Poky and all other Git repositories as referred by the Git Repo manifest. It contains BitBake, Documentation, Metadata and other files that all support the Yocto Project. Consequently, you must have the Source Directory in place on your development system in order to do any development using the Yocto Project. → Source Directory

  3. Build Directory: This term refers to the area used by the Build System for downloads, builds and deployments. → Build Directory

  4. Cross-Development Toolchain: A collection of cross-compilers, linkers, debuggers, libraries and utilities that run on one architecture and allow you to develop software for a different, or targeted, architecture. → Cross-Development Toolchain

  5. Board Support Package (BSP): A group of drivers, definitions, and other components that provide support for a specific hardware configuration. → Board Support Package (BSP), or Yocto Project Board Support Package Developer’s Guide and Yocto Project Linux Kernel Development Manual

Conclusion

the following applies and is unavoidable

Git Repo: determines the code base line

Layers: are essential and able to overlay

Classes: inheritable but not extensible

Recipes: extensible but not inheritable

Features: determines the final product