yocto project terms & 深入理解 BitBake

Yocto Project Terms

Following is a list of terms 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 case:

• Append Files: Files that append build information to a recipe file. Append files are known as BitBake append files and.bbappend files. The Yocto Project build system expects every append file to have a corresponding and underlying recipe (.bb) file. Furthermore, the append file and the underlying recipe must have the same root filename. The filenames can differ only in the file type suffix used (e.g.formfactor_0.0.bb and formfactor_0.0.bbappend).

  Information in append files overrides the information in the similarly-named recipe file. For examples of.bbappend file in use, see the "Using .bbappend Files" and "Changingrecipes-kernel" sections.

• BitBake: The task executor and scheduler used by the Yocto Project to build images. For more information on BitBake, see theBitBake documentation.

• Classes: Files that provide for logic encapsulation and inheritance allowing commonly used patterns to be defined once and easily used in multiple recipes. Class files end with the.bbclass filename extension.

• Configuration File: Configuration information in various.conf files provides global definitions of variables. Theconf/local.conf configuration file in theYocto Project Build Directory contains user-defined variables that affect each build. Themeta-yocto/conf/distro/poky.conf configuration file defines Yocto ‘distro’ configuration variables used only when building with this policy. Machine configuration files, which are located throughout the Yocto Project file structure, define variables for specific hardware and are only used when building for that target (e.g. themachine/beagleboard.conf configuration file defines variables for the Texas Instruments ARM Cortex-A8 development board). Configuration files end with a.conf filename extension.

• Cross-Development Toolchain: A collection of software development tools and utilities that allow you to develop software for targeted architectures. This toolchain contains cross-compilers, linkers, and debuggers that are specific to an architecture. You can use the Yocto Project to build cross-development toolchains in tarball form that when unpacked contain the development tools you need to cross-compile and test your software. The Yocto Project ships with images that contain toolchains for supported architectures as well. Sometimes this toolchain is referred to as the meta-toolchain.

• Image: An image is the result produced when BitBake processes a given collection of recipes and related metadata. Images are the binary output that runs on specific hardware and for specific use cases. For a list of the supported image types that the Yocto Project provides, see the "Reference: Images" appendix in The Yocto Project Reference Manual.

• Layer: A collection of recipes representing the core, a BSP, or an application stack. For a discussion on BSP Layers, see the "BSP Layers" section in the Yocto Project Board Support Packages (BSP) Developer's Guide.

• Metadata: The files that BitBake parses when building an image. Metadata includes recipes, classes, and configuration files.

• OE-Core: A core set of metadata originating with OpenEmbedded (OE) that is shared between OE and the Yocto Project. This metadata is found in themeta directory of the Yocto Project files.

• Package: The packaged output from a baked recipe. A package is generally the compiled binaries produced from the recipe's sources. You ‘bake’ something by running it through BitBake.

• Poky: The build tool that the Yocto Project uses to create images.

• Recipe: A set of instructions for building packages. A recipe describes where you get source code and which patches to apply. Recipes describe dependencies for libraries or for other recipes, and they also contain configuration and compilation options. Recipes contain the logical unit of execution, the software/images to build, and use the.bb file extension.

• Tasks: Arbitrary groups of software Recipes. You simply use Tasks to hold recipes that, when built, usually accomplish a single task. For example, a task could contain the recipes for a company’s proprietary or value-add software. Or, the task could contain the recipes that enable graphics. A task is really just another recipe. Because task files are recipes, they end with the.bb filename extension.

• Upstream: A reference to source code or repositories that are not local to the development system but located in a master area that is controlled by the maintainer of the source code. For example, in order for a developer to work on a particular piece of code, they need to first get a copy of it from an "upstream" source.

• Yocto Project Files: This term refers to the directory structure created as a result of either downloading and unpacking a Yocto Project release tarball or setting up a Git repository by cloninggit://git.yoctoproject.org/poky. Sometimes the term "the Yocto Project Files structure" is used as well.

  The Yocto Project Files contain BitBake, Documentation, metadata and other files that all support the development environment. Consequently, you must have the Yocto Project Files in place on your development system in order to do any development using the Yocto Project.

  The name of the top-level directory of the Yocto Project Files structure is derived from the Yocto Project release tarball. For example, downloading and unpackingpoky-denzil-7.0.tar.bz2 results in a Yocto Project file structure whose Yocto Project source directory is namedpoky-denzil-7.0. If you create a Git repository, then you can name the repository anything you like. Throughout much of the documentation, the name of the Git repository is used as the name for the local folder. So, for example, cloning the poky Git repository results in a local Git repository also namedpoky.

  It is important to understand the differences between Yocto Project Files created by unpacking a release tarball as compared to cloninggit://git.yoctoproject.org/poky. When you unpack a tarball, you have an exact copy of the files based on the time of release - a fixed release point. Any changes you make to your local Yocto Project Files are on top of the release. On the other hand, when you clone the Yocto Project Git repository, you have an active development repository. In this case, any local changes you make to the Yocto Project can be later applied to active development branches of the upstream Yocto Project Git repository.

  Finally, if you want to track a set of local changes while starting from the same point as a release tarball, you can create a local Git branch that reflects the exact copy of the files at the time of their release. You do this using Git tags that are part of the repository.

  For more information on concepts around Git repositories, branches, and tags, see the "Repositories, Tags, and Branches" section.

• Yocto Project Build Directory: This term refers to the area used by the Yocto Project for builds. The area is created when yousource the Yocto Project setup environment script that is found in the Yocto Project files area (i.e.oe-init-build-env). TheTOPDIR variable points to the build directory.

  You have a lot of flexibility when creating the Yocto Project Build Directory. Following are some examples that show how to create the directory:

  • Create the build directory in your current working directory and name it build. This is the default behavior.

         $ cd ~/poky     $ source oe-init-build-env                            

  • Provide a directory path and specifically name the build directory. This next example creates a build directory namedYP-7.0 in your home directory within the directorymybuilds. Ifmybuilds does not exist, the directory is created for you:

          $ source poky-denzil-7.0/oe-init-build-env $HOME/mybuilds/YP-7.0                            

  • Provide an existing directory to use as the build directory. This example uses the existingmybuilds directory as the build directory.

          $ source poky-denzil-7.0/oe-init-build-env $HOME/mybuilds/                            

Yocto Project Components

The BitBake task executor together with various types of configuration files form the Yocto Project core. This section overviews the BitBake task executor and the configuration files by describing what they are used for and how they interact.

BitBake handles the parsing and execution of the data files. The data itself is of various types:

• Recipes: Provides details about particular pieces of software

• Class Data: An abstraction of common build information (e.g. how to build a Linux kernel).

• Configuration Data: Defines machine-specific settings, policy decisions, etc. Configuration data acts as the glue to bind everything together.

bitbake 是 yocto project 最核心的工具，用于解析元数据，从元数据中生成任务清单，然后再执行任务清单中的所有任务。

3.1.1. BitBake

BitBake is the tool at the heart of the Yocto Project and is responsible for parsing the metadata, generating a list of tasks from it, and then executing those tasks.To see a list of the options BitBake supports, use the following help command:

     $ bitbake --help            

The most common usage for BitBake is bitbake <packagename>, wherepackagename is the name of the package you want to build (referred to as the "target" in this manual). The target often equates to the first part of a.bb filename. So, to run the matchbox-desktop_1.2.3.bb file, you might type the following:

     $ bitbake matchbox-desktop            

Several different versions of matchbox-desktop might exist. BitBake chooses the one selected by the distribution configuration. You can get more details about how BitBake chooses between different target versions and providers in the "Preferences and Providers" section.

BitBake also tries to execute any dependent tasks first. So for example, before buildingmatchbox-desktop, BitBake would build a cross compiler andeglibc if they had not already been built.

Note

This release of the Yocto Project does not support the glibc GNU version of the Unix standard C library. By default, the Yocto Project builds witheglibc.

A useful BitBake option to consider is the -k or--continue option. This option instructs BitBake to try and continue processing the job as much as possible even after encountering an error. When an error occurs, the target that failed and those that depend on it cannot be remade. However, when you use this option other dependencies can still be processed.

3.1.2. Metadata (Recipes)

The .bb files are usually referred to as "recipes." In general, a recipe contains information about a single piece of software. The information includes the location from which to download the source patches (if any are needed), which special configuration options to apply, how to compile the source files, and how to package the compiled output.

The term "package" can also be used to describe recipes. However, since the same word is used for the packaged output from the Yocto Project (i.e..ipk or.deb files), this document avoids using the term "package" when referring to recipes.

3.1.3. Classes

Class files (.bbclass) contain information that is useful to share between metadata files. An example is the Autotools class, which contains common settings for any application that Autotools uses. The "Reference: Classes" appendix provides details about common classes and how to use them.

3.1.4. Configuration

The configuration files (.conf) define various configuration variables that govern the Yocto Project 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 (local.conf, which is found in the Yocto Project files build directory).

BitBake working flow - Parsing

BitBake parses configuration files, classes, and .bb files.

The first thing BitBake does is look for the bitbake.conf file. The Yocto Project keeps this file in the Yocto Project file'smeta/conf/ directory. BitBake finds it by examining itsBBPATH environment variable and looking for themeta/conf/ directory.

In the Yocto Project, bitbake.conf lists other configuration files to include from aconf/ directory below the directories listed inBBPATH. In general, the most important configuration file from a user's perspective islocal.conf, which contains a user's customized settings for the Yocto Project build environment. Other notable configuration files are the distribution configuration file (set by theDISTRO variable) and the machine configuration file (set by theMACHINE variable). TheDISTRO andMACHINE BitBake environment variables are both usually set in thelocal.conf file. Valid distribution configuration files are available in themeta/conf/distro/ directory and valid machine configuration files in themeta/conf/machine/ directory. Within themeta/conf/machine/include/ directory are varioustune-*.inc configuration files that provide common "tuning" settings specific to and shared between particular architectures and machines.

After the parsing of the configuration files, some standard classes are included. Thebase.bbclass file is always included. Other classes that are specified in the configuration using theINHERIT variable are also included. Class files are searched for in aclasses subdirectory under the paths inBBPATH in the same way as configuration files.

After classes are included, the variable BBFILES is set, usually inlocal.conf, and defines the list of places to search for.bb files. By default, the BBFILES variable specifies themeta/recipes-*/ directory within Poky. Adding extra content toBBFILES is best achieved through the use of BitBake layers as described in the "Understanding and Creating Layers" section of the Yocto Project Development Manual.

BitBake parses each .bb file inBBFILES and stores the values of various variables. In summary, for each.bb file the configuration plus the base class of variables are set, followed by the data in the.bb file itself, followed by any inherit commands that.bb file might contain.

Because parsing .bb files is a time consuming process, a cache is kept to speed up subsequent parsing. This cache is invalid if the timestamp of the.bb file itself changes, or if the timestamps of any of the include, configuration or class files the.bb file depends on changes.

BitBake

BitBake is a simple tool for the execution of tasks. It is derived from Portage, which is the package management system used by the Gentoo Linux distribution. It is most commonly used to build packages, and is used as the basis of the OpenEmbedded project.

BitBake is now managed using the Git source control system which can be obtained from git://git.openembedded.org/bitbake.git. Releases can be downloaded from http://downloads.yoctoproject.org/releases/bitbake/ and the developer mailing list, bitbake-devel can be found at http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel.

The user manual is found in the docmentation directory within the source code.

BitBake User Manual

http://docs.openembedded.org/bitbake/html/