Class files are used to abstract common functionality and share it amongst multiple .bb files. Any metadata usually found in a .bb file can also be placed in a class file. Class files are identified by the extension .bbclass and are usually placed in a classes/ directory beneath the meta*/ directory found in the Yocto Project file's area Class files can also be pointed to by BUILDDIR (e.g. build/)in the same way as .conf files in the conf directory. Class files are searched for in BBPATH using the same method by which .conf files are searched. In most cases inheriting the class is enough to enable its features, although for some classes you might need to set variables or override some of the default behaviour.

The base class is special in that every .bb file inherits it automatically. This class contains definitions for standard basic tasks such as fetching, unpacking, configuring (empty by default), compiling (runs any Makefile present), installing (empty by default) and packaging (empty by default). These classes are often overridden or extended by other classes such as autotools.bbclass or package.bbclass. The class also contains some commonly used functions such as oe_runmake.

Autotools (autoconf, automake, and libtool) bring standardization. This class defines a set of tasks (configure, compile etc.) that work for all Autotooled packages. It should usually be enough to define a few standard variables as documented in the Autotooled Package section and then simply inherit autotools. This class can also work with software that emulates Autotools. It's useful to have some idea of how the tasks defined by this class work and what they do behind the scenes. do_configure ‐ regenerates the configure script (using autoreconf) and then launches it with a standard set of arguments used during cross-compilation. You can pass additional parameters to configure through the EXTRA_OECONF variable. do_compile ‐ runs make with arguments that specify the compiler and linker. You can pass additional arguments through the EXTRA_OEMAKE variable. do_install ‐ runs make install and passes a DESTDIR option, which takes its value from the standard DESTDIR variable.

Several programs can fulfill the same or similar function and be installed with the same name. For example, the ar command is available from the busybox, binutils and elfutils packages. The update-alternatives.bbclass class handles renaming the binaries so that multiple packages can be installed without conflicts. The ar command still works regardless of which packages are installed or subsequently removed. The class renames the conflicting binary in each package and symlinks the highest priority binary during installation or removal of packages. Four variables control this class: ALTERNATIVE_NAME ‐ The name of the binary that is replaced (ar in this example). ALTERNATIVE_LINK ‐ The path to the resulting binary (/bin/ar in this example). ALTERNATIVE_PATH ‐ The path to the real binary (/usr/bin/ar.binutils in this example). ALTERNATIVE_PRIORITY ‐ The priority of the binary. The version with the most features should have the highest priority. Currently, the Yocto Project supports only one binary per package.

This class uses update-rc.d to safely install an initialization script on behalf of the package. The Yocto Project takes care of details such as making sure the script is stopped before a package is removed and started when the package is installed. Three variables control this class: INITSCRIPT_PACKAGES, INITSCRIPT_NAME and INITSCRIPT_PARAMS. See the variable links for details.

Before pkg-config had become widespread, libraries shipped shell scripts to give information about the libraries and include paths needed to build software (usually named LIBNAME-config). This class assists any recipe using such scripts. During staging, BitBake installs such scripts into the sysroots/ directory. BitBake also changes all paths to point into the sysroots/ directory so all builds that use the script will use the correct directories for the cross compiling layout.

This class renames packages so that they follow the Debian naming policy (i.e. eglibc becomes libc6 and eglibc-devel becomes libc6-dev.

pkg-config brought standardization and this class aims to make its integration smooth for all libraries that make use of it. During staging, BitBake installs pkg-config data into the sysroots/ directory. By making use of sysroot functionality within pkg-config, this class no longer has to manipulate the files.

Many software licenses require that source files be provided along with the binaries. To simplify this process, two classes were created: src_distribute.bbclass and src_distribute_local.bbclass. The results of these classes are tmp/deploy/source/ subdirs with sources sorted by LICENSE field. If recipes list few licenses (or have entries like "Bitstream Vera"), the source archive is placed in each license directory. This class operates using three modes: copy: Copies the files to the distribute directory. symlink: Symlinks the files to the distribute directory. move+symlink: Moves the files into the distribute directory and then symlinks them back.

Recipes for Perl modules are simple. These recipes usually only need to point to the source's archive and then inherit the proper .bbclass file. Building is split into two methods depending on which method the module authors used. Modules that use old Makefile.PL-based build system require cpan.bbclass in their recipes. Modules that use Build.PL-based build system require using cpan_build.bbclass in their recipes.

Recipes for Python extensions are simple. These recipes usually only need to point to the source's archive and then inherit the proper .bbclass file. Building is split into two methods dependling on which method the module authors used. Extensions that use an Autotools-based build system require Autotools and distutils-based .bbclasse files in their recipes. Extensions that use distutils-based build systems require distutils.bbclass in their recipes.

This class adds the devshell task. Distribution policy dictates whether to include this class as the Yocto Project does. See the Development Within a Development Shell section for more information about using devshell.

The packaging classes add support for generating packages from a build's output. The core generic functionality is in package.bbclass. The code specific to particular package types is contained in various sub-classes such as package_deb.bbclass, package_ipk.bbclass, and package_rpm.bbclass. Most users will want one or more of these classes. You can control the list of resulting package formats by using the PACKAGE_CLASSES variable defined in the local.conf configuration file found in the Yocto Project file's conf directory. When defining the variable, you can specify one or more package types. Since images are generated from packages, a packaging class is needed to enable image generation. The first class listed in this variable is used for image generation. The package class you choose can affect build-time performance and has space ramifications. In general, building a package with RPM takes about thirty percent more time as compared to using IPK to build the same or similar package. This comparison takes into account a complete build of the package with all dependencies previously built. The reason for this discrepancy is because the RPM package manager creates and processes more metadata than the IPK package manager. Consequently, you might consider setting PACKAGE_CLASSES to "package_ipk" if you are building smaller systems. Keep in mind, however, that RPM starts to provide more abilities than IPK due to the fact that it processes more metadata. For example, this information includes individual file types, file checksum generation and evaluation on install, sparse file support, conflict detection and resolution for multilib systems, ACID style upgrade, and repackaging abilities for rollbacks. Another consideration for packages built using the RPM package manager is space. For smaller systems, the extra space used for the Berkley Database and the amount of metadata can affect your ability to do on-device upgrades. You can find additional information on the effects of the package class at these two Yocto Project mailing list links: https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html

This class handles building Linux kernels. The class contains code to build all kernel trees. All needed headers are staged into the STAGING_KERNEL_DIR directory to allow out-of-tree module builds using module.bbclass. This means that each built kernel module is packaged separately and inter-module dependencies are created by parsing the modinfo output. If all modules are required, then installing the kernel-modules package installs all packages with modules and various other kernel packages such as kernel-vmlinux. Various other classes are used by the kernel and module classes internally including kernel-arch.bbclass, module_strip.bbclass, module-base.bbclass, and linux-kernel-base.bbclass.

These classes add support for creating images in several formats. First, the root filesystem is created from packages using one of the rootfs_*.bbclass files (depending on the package format used) and then the image is created. The IMAGE_FSTYPES variable controls the types of images to generate. The IMAGE_INSTALL variable controls the list of packages to install into the image.

This class checks to see if prerequisite software is present so that users can be notified of potential problems that might affect their build. The class also performs basic user configuration checks from the local.conf configuration file to prevent common mistakes that cause build failures. Distribution policy usually whether to include this class as the Yocto Project does.

This class adds a step to the package generation process that sanity checks the packages generated by the Yocto Project. A range of checks are performed that check the build's output for common problems that show up during runtime. Distribution policy usually dictates whether to include this class as the Yocto Project does.

Autotools can require tests that must execute on the target hardware. Since this is not possible in general when cross compiling, site information is used to provide cached test results so these tests can be skipped over but still make the correct values available. The meta/site directory contains test results sorted into different categories such as architecture, endianness, and the libc used. Site information provides a list of files containing data relevant to the current build in the CONFIG_SITE variable that Autotools automatically picks up. The class also provides variables like SITEINFO_ENDIANNESS and SITEINFO_BITS that can be used elsewhere in the metadata. Because this class is included from base.bbclass, it is always active.

If you have packages that install files that are owned by custom users or groups, you can use this class to specify those packages and associate the users and groups with those packages. The meta-skeleton/recipes-skeleton/useradd/useradd-example.bb recipe in the Yocto Project Files provides a simple exmample that shows how to add three users and groups to two packages. See the useradd-example.bb for more information on how to use this class.

Thus far, this appendix has discussed only the most useful and important classes. However, other classes exist within the meta/classes directory in the Yocto Project file's directory structure. You can examine the .bbclass files directly for more information.