From 09209eec235a35b7089db987561c12e9bd023237 Mon Sep 17 00:00:00 2001 From: Andrew Geissler Date: Sun, 13 Dec 2020 08:44:15 -0600 Subject: poky: subtree update:0ac99625bf..796be0593a Alexander Kanavin (31): netbase: upgrade 6.1 -> 6.2 meson: upgrade 0.55.1 -> 0.56.0 vulkan-samples: update to latest revision libcap: update 2.44 -> 2.45 bind: upgrade 9.16.7 -> 9.16.9 quota: upgrade 4.05 -> 4.06 pango: upgrade 1.46.2 -> 1.48.0 elfutils: upgrade 0.181 -> 0.182 ifupdown: upgrade 0.8.35 -> 0.8.36 createrepo-c: upgrade 0.16.1 -> 0.16.2 acpica: upgrade 20200925 -> 20201113 grep: upgrade 3.5 -> 3.6 man-pages: upgrade 5.08 -> 5.09 stress-ng: upgrade 0.11.23 -> 0.11.24 libhandy: upgrade 1.0.1 -> 1.0.2 piglit: upgrade to latest revision xkbcomp: upgrade 1.4.3 -> 1.4.4 lz4: upgrade 1.9.2 -> 1.9.3 bison: upgrade 3.7.3 -> 3.7.4 python3-setuptools-scm: fix upstream version check cantarell-fonts: update 0.0.25 -> 0.201 meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps llvm: fix reproducibility ruby: fix reproducibility webkitgtk: fix reproducibility ffmpeg: fix reproducibility piglit: fix reproducibility serf: do not install the static library llvm: sort the lists in generated source reproducibibly kea: fix reproducibility poky.conf: do not write current date into distro version, use git hash instead Andrej Valek (1): kernel-dummy: fix executing unexpected tasks Anuj Mittal (1): releases.rst: add gatesgarth to current releases Brett Warren (1): libffi: add patch to revert clang VFP workaround Chandana kalluri (1): populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg Changqing Li (1): buildtools-tarball: add wic dependency into extended buildtools Diego Sueiro (2): modutils-initscripts: Fix modules.dep creation when USE_DEPMOD="0" initscripts: Change execution order between checkroot and modutils Dmitry Baryshkov (2): linux-firmware: upgrade 20201022 -> 20201118 linux-firmware: package ath11k firmware Fabio Berton (1): mesa: Update 20.2.1 -> 20.2.4 Gratian Crisan (1): kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES Jack Mitchell (3): Revert "connman: set service to conflict with systemd-networkd" systemd-conf: add PACKAGECONFIG to enable/disable auto ethernet DHCP systemd-conf: match ethernet interfaces by type rather than globbing Joshua Watt (2): bitbake: hashserv: client: Fix AF_UNIX path length limits bitbake: hashserv: Fix broken AF_UNIX path length limit Kai Kang (2): systemd-systemctl-native: capable to call without argument systemd.bbclass: update command to check systemctl available Kevin Hao (1): tune-octeontx2.inc: Add tune for Marvell OCTEON TX2 core Li Wang (2): qemu: CVE-2020-29129 CVE-2020-29130 qemu: CVE-2020-25624 Luca Boccassi (1): dbus: move messagebus user to dbus-common package Michael Halstead (1): releases: conf: add link to 3.1.4, update to include 3.1.4 Nicolas Dechesne (19): sphinx: add .vscode in .gitignore {dev,kernel,sdk}-manual: replace hardcoded release version with &DISTRO; sphinx: replace bitbake labels with references to corresponding title brief-yoctoprojectqs: replace labels with references to section title dev-manual: replace labels with references to section title ref-manual: replace labels with references to section title sdk-manual: replace labels with references to section title overview-manual: remove unused labels dev-manual: remove unused labels sphinx: rename top level document in each manual sphinx: use absolute paths for :doc: references test-manual: remove 'test-manual' from filenames toaster-manual: remove 'toaster-manual' from filenames dev-manual: remove 'dev-manual' from filenames kernel-dev: remove 'kernel-dev' from filenames profile-manual: remove 'profile-manual' from filenames overview-manual: remove 'overview-manual' from filenames sdk-manual: remove 'sdk' from filenames ref-manual: remove 'ref' from filenames Paul Barker (5): documentation: Simplify yocto_wiki links documentation: Simplify yocto_git links ref-manual: Simplify oe_git links poky.conf: Add opensuseleap-15.2 and fedora-33 to tested distros poky.conf: Drop fedora-30 from tested distros Peter Kjellerstedt (2): pseudo: Simplify pseudo_client_ignore_path_chroot() bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS Richard Purdie (8): lz4: Use the new branch naming from upstream Revert "bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS" build-appliance-image: Update to master head revision bitbake: Revert "fetch2: use relative symlinks for anything pulled from PREMIRRORS" build-appliance-image: Update to master head revision metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH poky: Set SDK_VERSION explicitly build-appliance-image: Update to master head revision Ross Burton (9): oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball image_types: remove obsolete tar comment image_types: sort tarball file listings package_manager/ipk: neaten OPKGLIBDIR logic ldconfig-native: don't write auxiliary cache package_manager/ipk: improve remove_packaging_data oeqa/selftest/containerimage: update for improved cleanup coreutils: add SUSE-specific issues to CVE whitelist bitbake: msg: use safe YAML loader Sinan Kaya (1): poky-tiny: enable section removal Tomasz Dziendzielski (1): pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches sangeeta jain (1): meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell zangrc (3): libinput: upgrade 1.16.3 -> 1.16.4 lighttpd: upgrade 1.4.55 -> 1.4.56 sysstat: upgrade 12.4.0 -> 12.4.1 Signed-off-by: Andrew Geissler Change-Id: I65f2f1c9d44433f3e62609240012c42256679b51 --- poky/documentation/ref-manual/classes.rst | 2898 +++++++++++++++++++++++++++++ 1 file changed, 2898 insertions(+) create mode 100644 poky/documentation/ref-manual/classes.rst (limited to 'poky/documentation/ref-manual/classes.rst') diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst new file mode 100644 index 000000000..5a30ce379 --- /dev/null +++ b/poky/documentation/ref-manual/classes.rst @@ -0,0 +1,2898 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +******* +Classes +******* + +Class files are used to abstract common functionality and share it +amongst multiple recipe (``.bb``) files. To use a class file, you simply +make sure the recipe inherits the class. In most cases, when a recipe +inherits a class it is enough to enable its features. There are cases, +however, where in the recipe you might need to set variables or override +some default behavior. + +Any :term:`Metadata` usually found in a recipe 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 :term:`Source Directory`. +Class files can also be pointed to by +:term:`BUILDDIR` (e.g. ``build/``) in the same way as +``.conf`` files in the ``conf`` directory. Class files are searched for +in :term:`BBPATH` using the same method by which ``.conf`` +files are searched. + +This chapter discusses only the most useful and important classes. Other +classes do exist within the ``meta/classes`` directory in the Source +Directory. You can reference the ``.bbclass`` files directly for more +information. + +.. _ref-classes-allarch: + +``allarch.bbclass`` +=================== + +The ``allarch`` class is inherited by recipes that do not produce +architecture-specific output. The class disables functionality that is +normally needed for recipes that produce executable binaries (such as +building the cross-compiler and a C library as pre-requisites, and +splitting out of debug symbols during packaging). + +.. note:: + + Unlike some distro recipes (e.g. Debian), OpenEmbedded recipes that + produce packages that depend on tunings through use of the + :term:`RDEPENDS` and + :term:`TUNE_PKGARCH` variables, should never be + configured for all architectures using ``allarch``. This is the case + even if the recipes do not produce architecture-specific output. + + Configuring such recipes for all architectures causes the + ``do_package_write_*`` tasks to + have different signatures for the machines with different tunings. + Additionally, unnecessary rebuilds occur every time an image for a + different ``MACHINE`` is built even when the recipe never changes. + +By default, all recipes inherit the :ref:`base ` and +:ref:`package ` classes, which enable +functionality needed for recipes that produce executable output. If your +recipe, for example, only produces packages that contain configuration +files, media files, or scripts (e.g. Python and Perl), then it should +inherit the ``allarch`` class. + +.. _ref-classes-archiver: + +``archiver.bbclass`` +==================== + +The ``archiver`` class supports releasing source code and other +materials with the binaries. + +For more details on the source archiver, see the +":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`" +section in the Yocto Project Development Tasks Manual. You can also see +the :term:`ARCHIVER_MODE` variable for information +about the variable flags (varflags) that help control archive creation. + +.. _ref-classes-autotools: + +``autotools*.bbclass`` +====================== + +The ``autotools*`` classes support Autotooled packages. + +The ``autoconf``, ``automake``, and ``libtool`` packages bring +standardization. This class defines a set of tasks (e.g. ``configure``, +``compile`` and so forth) that work for all Autotooled packages. It +should usually be enough to define a few standard variables and then +simply ``inherit autotools``. These classes can also work with software +that emulates Autotools. For more information, see the +":ref:`dev-manual/common-tasks:autotooled package`" section +in the Yocto Project Development Tasks Manual. + +By default, the ``autotools*`` classes use out-of-tree builds (i.e. +``autotools.bbclass`` building with ``B != S``). + +If the software being built by a recipe does not support using +out-of-tree builds, you should have the recipe inherit the +``autotools-brokensep`` class. The ``autotools-brokensep`` class behaves +the same as the ``autotools`` class but builds with :term:`B` +== :term:`S`. This method is useful when out-of-tree build +support is either not present or is broken. + +.. note:: + + It is recommended that out-of-tree support be fixed and used if at + all possible. + +It's useful to have some idea of how the tasks defined by the +``autotools*`` classes work and what they do behind the scenes. + +- :ref:`ref-tasks-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`` + or :term:`PACKAGECONFIG_CONFARGS` + variables. + +- :ref:`ref-tasks-compile` - Runs ``make`` with + arguments that specify the compiler and linker. You can pass + additional arguments through the ``EXTRA_OEMAKE`` variable. + +- :ref:`ref-tasks-install` - Runs ``make install`` and + passes in ``${``\ :term:`D`\ ``}`` as ``DESTDIR``. + +.. _ref-classes-base: + +``base.bbclass`` +================ + +The ``base`` class is special in that every ``.bb`` file implicitly +inherits the class. 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 the +:ref:`autotools ` class or the +:ref:`package ` class. + +The class also contains some commonly used functions such as +``oe_runmake``, which runs ``make`` with the arguments specified in +:term:`EXTRA_OEMAKE` variable as well as the +arguments passed directly to ``oe_runmake``. + +.. _ref-classes-bash-completion: + +``bash-completion.bbclass`` +=========================== + +Sets up packaging and dependencies appropriate for recipes that build +software that includes bash-completion data. + +.. _ref-classes-bin-package: + +``bin_package.bbclass`` +======================= + +The ``bin_package`` class is a helper class for recipes that extract the +contents of a binary package (e.g. an RPM) and install those contents +rather than building the binary from source. The binary package is +extracted and new packages in the configured output package format are +created. Extraction and installation of proprietary binaries is a good +example use for this class. + +.. note:: + + For RPMs and other packages that do not contain a subdirectory, you + should specify an appropriate fetcher parameter to point to the + subdirectory. For example, if BitBake is using the Git fetcher (``git://``), + the "subpath" parameter limits the checkout to a specific subpath + of the tree. Here is an example where ``${BP}`` is used so that the files + are extracted into the subdirectory expected by the default value of + ``S``: + :: + + SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}" + + + See the ":ref:`bitbake-user-manual/bitbake-user-manual-fetching:fetchers`" section in the BitBake User Manual for + more information on supported BitBake Fetchers. + +.. _ref-classes-binconfig: + +``binconfig.bbclass`` +===================== + +The ``binconfig`` class helps to correct paths in shell scripts. + +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, the OpenEmbedded build system installs such scripts into +the ``sysroots/`` directory. Inheriting this class results in all paths +in these scripts being changed to point into the ``sysroots/`` directory +so that all builds that use the script use the correct directories for +the cross compiling layout. See the +:term:`BINCONFIG_GLOB` variable for more +information. + +.. _ref-classes-binconfig-disabled: + +``binconfig-disabled.bbclass`` +============================== + +An alternative version of the :ref:`binconfig ` +class, which disables binary configuration scripts by making them return +an error in favor of using ``pkg-config`` to query the information. The +scripts to be disabled should be specified using the +:term:`BINCONFIG` variable within the recipe inheriting +the class. + +.. _ref-classes-blacklist: + +``blacklist.bbclass`` +===================== + +The ``blacklist`` class prevents the OpenEmbedded build system from +building specific recipes (blacklists them). To use this class, inherit +the class globally and set :term:`PNBLACKLIST` for +each recipe you wish to blacklist. Specify the :term:`PN` +value as a variable flag (varflag) and provide a reason, which is +reported, if the package is requested to be built as the value. For +example, if you want to blacklist a recipe called "exoticware", you add +the following to your ``local.conf`` or distribution configuration: +:: + + INHERIT += "blacklist" + PNBLACKLIST[exoticware] = "Not supported by our organization." + +.. _ref-classes-buildhistory: + +``buildhistory.bbclass`` +======================== + +The ``buildhistory`` class records a history of build output metadata, +which can be used to detect possible regressions as well as used for +analysis of the build output. For more information on using Build +History, see the +":ref:`dev-manual/common-tasks:maintaining build output quality`" +section in the Yocto Project Development Tasks Manual. + +.. _ref-classes-buildstats: + +``buildstats.bbclass`` +====================== + +The ``buildstats`` class records performance statistics about each task +executed during the build (e.g. elapsed time, CPU usage, and I/O usage). + +When you use this class, the output goes into the +:term:`BUILDSTATS_BASE` directory, which defaults +to ``${TMPDIR}/buildstats/``. You can analyze the elapsed time using +``scripts/pybootchartgui/pybootchartgui.py``, which produces a cascading +chart of the entire build process and can be useful for highlighting +bottlenecks. + +Collecting build statistics is enabled by default through the +:term:`USER_CLASSES` variable from your +``local.conf`` file. Consequently, you do not have to do anything to +enable the class. However, if you want to disable the class, simply +remove "buildstats" from the ``USER_CLASSES`` list. + +.. _ref-classes-buildstats-summary: + +``buildstats-summary.bbclass`` +============================== + +When inherited globally, prints statistics at the end of the build on +sstate re-use. In order to function, this class requires the +:ref:`buildstats ` class be enabled. + +.. _ref-classes-ccache: + +``ccache.bbclass`` +================== + +The ``ccache`` class enables the C/C++ Compiler Cache for the build. +This class is used to give a minor performance boost during the build. +However, using the class can lead to unexpected side-effects. Thus, it +is recommended that you do not use this class. See +http://ccache.samba.org/ for information on the C/C++ Compiler +Cache. + +.. _ref-classes-chrpath: + +``chrpath.bbclass`` +=================== + +The ``chrpath`` class is a wrapper around the "chrpath" utility, which +is used during the build process for ``nativesdk``, ``cross``, and +``cross-canadian`` recipes to change ``RPATH`` records within binaries +in order to make them relocatable. + +.. _ref-classes-clutter: + +``clutter.bbclass`` +=================== + +The ``clutter`` class consolidates the major and minor version naming +and other common items used by Clutter and related recipes. + +.. note:: + + Unlike some other classes related to specific libraries, recipes + building other software that uses Clutter do not need to inherit this + class unless they use the same recipe versioning scheme that the + Clutter and related recipes do. + +.. _ref-classes-cmake: + +``cmake.bbclass`` +================= + +The ``cmake`` class allows for recipes that need to build software using +the `CMake `__ build system. You can use +the :term:`EXTRA_OECMAKE` variable to specify +additional configuration options to be passed using the ``cmake`` +command line. + +On the occasion that you would be installing custom CMake toolchain +files supplied by the application being built, you should install them +to the preferred CMake Module directory: ``${D}${datadir}/cmake/`` +Modules during +:ref:`ref-tasks-install`. + +.. _ref-classes-cml1: + +``cml1.bbclass`` +================ + +The ``cml1`` class provides basic support for the Linux kernel style +build configuration system. + +.. _ref-classes-compress_doc: + +``compress_doc.bbclass`` +======================== + +Enables compression for man pages and info pages. This class is intended +to be inherited globally. The default compression mechanism is gz (gzip) +but you can select an alternative mechanism by setting the +:term:`DOC_COMPRESS` variable. + +.. _ref-classes-copyleft_compliance: + +``copyleft_compliance.bbclass`` +=============================== + +The ``copyleft_compliance`` class preserves source code for the purposes +of license compliance. This class is an alternative to the ``archiver`` +class and is still used by some users even though it has been deprecated +in favor of the :ref:`archiver ` class. + +.. _ref-classes-copyleft_filter: + +``copyleft_filter.bbclass`` +=========================== + +A class used by the :ref:`archiver ` and +:ref:`copyleft_compliance ` classes +for filtering licenses. The ``copyleft_filter`` class is an internal +class and is not intended to be used directly. + +.. _ref-classes-core-image: + +``core-image.bbclass`` +====================== + +The ``core-image`` class provides common definitions for the +``core-image-*`` image recipes, such as support for additional +:term:`IMAGE_FEATURES`. + +.. _ref-classes-cpan: + +``cpan*.bbclass`` +================= + +The ``cpan*`` classes support Perl modules. + +Recipes for Perl modules are simple. These recipes usually only need to +point to the source's archive and then inherit the proper class 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. + +Both build methods inherit the ``cpan-base`` class for basic Perl +support. + +.. _ref-classes-cross: + +``cross.bbclass`` +================= + +The ``cross`` class provides support for the recipes that build the +cross-compilation tools. + +.. _ref-classes-cross-canadian: + +``cross-canadian.bbclass`` +========================== + +The ``cross-canadian`` class provides support for the recipes that build +the Canadian Cross-compilation tools for SDKs. See the +":ref:`overview-manual/concepts:cross-development toolchain generation`" +section in the Yocto Project Overview and Concepts Manual for more +discussion on these cross-compilation tools. + +.. _ref-classes-crosssdk: + +``crosssdk.bbclass`` +==================== + +The ``crosssdk`` class provides support for the recipes that build the +cross-compilation tools used for building SDKs. See the +":ref:`overview-manual/concepts:cross-development toolchain generation`" +section in the Yocto Project Overview and Concepts Manual for more +discussion on these cross-compilation tools. + +.. _ref-classes-debian: + +``debian.bbclass`` +================== + +The ``debian`` class renames output packages so that they follow the +Debian naming policy (i.e. ``glibc`` becomes ``libc6`` and +``glibc-devel`` becomes ``libc6-dev``.) Renaming includes the library +name and version as part of the package name. + +If a recipe creates packages for multiple libraries (shared object files +of ``.so`` type), use the :term:`LEAD_SONAME` +variable in the recipe to specify the library on which to apply the +naming scheme. + +.. _ref-classes-deploy: + +``deploy.bbclass`` +================== + +The ``deploy`` class handles deploying files to the +:term:`DEPLOY_DIR_IMAGE` directory. The main +function of this class is to allow the deploy step to be accelerated by +shared state. Recipes that inherit this class should define their own +:ref:`ref-tasks-deploy` function to copy the files to be +deployed to :term:`DEPLOYDIR`, and use ``addtask`` to +add the task at the appropriate place, which is usually after +:ref:`ref-tasks-compile` or +:ref:`ref-tasks-install`. The class then takes care of +staging the files from ``DEPLOYDIR`` to ``DEPLOY_DIR_IMAGE``. + +.. _ref-classes-devshell: + +``devshell.bbclass`` +==================== + +The ``devshell`` class adds the ``do_devshell`` task. Distribution +policy dictates whether to include this class. See the ":ref:`dev-manual/common-tasks:using a development shell`" +section in the Yocto Project Development Tasks Manual for more +information about using ``devshell``. + +.. _ref-classes-devupstream: + +``devupstream.bbclass`` +======================= + +The ``devupstream`` class uses +:term:`BBCLASSEXTEND` to add a variant of the +recipe that fetches from an alternative URI (e.g. Git) instead of a +tarball. Following is an example: +:: + + BBCLASSEXTEND = "devupstream:target" + SRC_URI_class-devupstream = "git://git.example.com/example" + SRCREV_class-devupstream = "abcd1234" + +Adding the above statements to your recipe creates a variant that has +:term:`DEFAULT_PREFERENCE` set to "-1". +Consequently, you need to select the variant of the recipe to use it. +Any development-specific adjustments can be done by using the +``class-devupstream`` override. Here is an example: +:: + + DEPENDS_append_class-devupstream = " gperf-native" + do_configure_prepend_class-devupstream() { + touch ${S}/README + } + +The class +currently only supports creating a development variant of the target +recipe, not ``native`` or ``nativesdk`` variants. + +The ``BBCLASSEXTEND`` syntax (i.e. ``devupstream:target``) provides +support for ``native`` and ``nativesdk`` variants. Consequently, this +functionality can be added in a future release. + +Support for other version control systems such as Subversion is limited +due to BitBake's automatic fetch dependencies (e.g. +``subversion-native``). + +.. _ref-classes-distutils: + +``distutils*.bbclass`` +====================== + +The ``distutils*`` classes support recipes for Python version 2.x +extensions, which are simple. These recipes usually only need to point +to the source's archive and then inherit the proper class. Building is +split into two methods depending on which method the module authors +used. + +- Extensions that use an Autotools-based build system require Autotools + and the classes based on ``distutils`` in their recipes. + +- Extensions that use build systems based on ``distutils`` require the + ``distutils`` class in their recipes. + +- Extensions that use build systems based on ``setuptools`` require the + :ref:`setuptools ` class in their recipes. + +The ``distutils-common-base`` class is required by some of the +``distutils*`` classes to provide common Python2 support. + +.. _ref-classes-distutils3: + +``distutils3*.bbclass`` +======================= + +The ``distutils3*`` classes support recipes for Python version 3.x +extensions, which are simple. These recipes usually only need to point +to the source's archive and then inherit the proper class. Building is +split into three methods depending on which method the module authors +used. + +- Extensions that use an Autotools-based build system require Autotools + and ``distutils``-based classes in their recipes. + +- Extensions that use ``distutils``-based build systems require the + ``distutils`` class in their recipes. + +- Extensions that use build systems based on ``setuptools3`` require + the :ref:`setuptools3 ` class in their + recipes. + +The ``distutils3*`` classes either inherit their corresponding +``distutils*`` class or replicate them using a Python3 version instead +(e.g. ``distutils3-base`` inherits ``distutils-common-base``, which is +the same as ``distutils-base`` but inherits ``python3native`` instead of +``pythonnative``). + +.. _ref-classes-externalsrc: + +``externalsrc.bbclass`` +======================= + +The ``externalsrc`` class supports building software from source code +that is external to the OpenEmbedded build system. Building software +from an external source tree means that the build system's normal fetch, +unpack, and patch process is not used. + +By default, the OpenEmbedded build system uses the :term:`S` +and :term:`B` variables to locate unpacked recipe source code +and to build it, respectively. When your recipe inherits the +``externalsrc`` class, you use the +:term:`EXTERNALSRC` and +:term:`EXTERNALSRC_BUILD` variables to +ultimately define ``S`` and ``B``. + +By default, this class expects the source code to support recipe builds +that use the :term:`B` variable to point to the directory in +which the OpenEmbedded build system places the generated objects built +from the recipes. By default, the ``B`` directory is set to the +following, which is separate from the source directory (``S``): +:: + + ${WORKDIR}/${BPN}/{PV}/ + +See these variables for more information: +:term:`WORKDIR`, :term:`BPN`, and +:term:`PV`, + +For more information on the ``externalsrc`` class, see the comments in +``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`. +For information on how to use the +``externalsrc`` class, see the +":ref:`dev-manual/common-tasks:building software from an external source`" +section in the Yocto Project Development Tasks Manual. + +.. _ref-classes-extrausers: + +``extrausers.bbclass`` +====================== + +The ``extrausers`` class allows additional user and group configuration +to be applied at the image level. Inheriting this class either globally +or from an image recipe allows additional user and group operations to +be performed using the +:term:`EXTRA_USERS_PARAMS` variable. + +.. note:: + + The user and group operations added using the + extrausers + class are not tied to a specific recipe outside of the recipe for the + image. Thus, the operations can be performed across the image as a + whole. Use the + useradd + class to add user and group configuration to a specific recipe. + +Here is an example that uses this class in an image recipe: +:: + + inherit extrausers + EXTRA_USERS_PARAMS = "\ + useradd -p '' tester; \ + groupadd developers; \ + userdel nobody; \ + groupdel -g video; \ + groupmod -g 1020 developers; \ + usermod -s /bin/sh tester; \ + " + +Here is an example that adds two users named "tester-jim" and "tester-sue" and assigns +passwords: +:: + + inherit extrausers + EXTRA_USERS_PARAMS = "\ + useradd -P tester01 tester-jim; \ + useradd -P tester01 tester-sue; \ + " + +Finally, here is an example that sets the root password to "1876*18": +:: + + inherit extrausers + EXTRA_USERS_PARAMS = "\ + usermod -P 1876*18 root; \ + " + +.. _ref-classes-features_check: + +``features_check.bbclass`` +================================= + +The ``features_check`` class allows individual recipes to check +for required and conflicting +:term:`DISTRO_FEATURES`, :term:`MACHINE_FEATURES` or :term:`COMBINED_FEATURES`. + +This class provides support for the following variables: + +- :term:`REQUIRED_DISTRO_FEATURES` +- :term:`CONFLICT_DISTRO_FEATURES` +- :term:`ANY_OF_DISTRO_FEATURES` +- ``REQUIRED_MACHINE_FEATURES`` +- ``CONFLICT_MACHINE_FEATURES`` +- ``ANY_OF_MACHINE_FEATURES`` +- ``REQUIRED_COMBINED_FEATURES`` +- ``CONFLICT_COMBINED_FEATURES`` +- ``ANY_OF_COMBINED_FEATURES`` + +If any conditions specified in the recipe using the above +variables are not met, the recipe will be skipped, and if the +build system attempts to build the recipe then an error will be +triggered. + +.. _ref-classes-fontcache: + +``fontcache.bbclass`` +===================== + +The ``fontcache`` class generates the proper post-install and +post-remove (postinst and postrm) scriptlets for font packages. These +scriptlets call ``fc-cache`` (part of ``Fontconfig``) to add the fonts +to the font information cache. Since the cache files are +architecture-specific, ``fc-cache`` runs using QEMU if the postinst +scriptlets need to be run on the build host during image creation. + +If the fonts being installed are in packages other than the main +package, set :term:`FONT_PACKAGES` to specify the +packages containing the fonts. + +.. _ref-classes-fs-uuid: + +``fs-uuid.bbclass`` +=================== + +The ``fs-uuid`` class extracts UUID from +``${``\ :term:`ROOTFS`\ ``}``, which must have been built +by the time that this function gets called. The ``fs-uuid`` class only +works on ``ext`` file systems and depends on ``tune2fs``. + +.. _ref-classes-gconf: + +``gconf.bbclass`` +================= + +The ``gconf`` class provides common functionality for recipes that need +to install GConf schemas. The schemas will be put into a separate +package (``${``\ :term:`PN`\ ``}-gconf``) that is created +automatically when this class is inherited. This package uses the +appropriate post-install and post-remove (postinst/postrm) scriptlets to +register and unregister the schemas in the target image. + +.. _ref-classes-gettext: + +``gettext.bbclass`` +=================== + +The ``gettext`` class provides support for building software that uses +the GNU ``gettext`` internationalization and localization system. All +recipes building software that use ``gettext`` should inherit this +class. + +.. _ref-classes-gnomebase: + +``gnomebase.bbclass`` +===================== + +The ``gnomebase`` class is the base class for recipes that build +software from the GNOME stack. This class sets +:term:`SRC_URI` to download the source from the GNOME +mirrors as well as extending :term:`FILES` with the typical +GNOME installation paths. + +.. _ref-classes-gobject-introspection: + +``gobject-introspection.bbclass`` +================================= + +Provides support for recipes building software that supports GObject +introspection. This functionality is only enabled if the +"gobject-introspection-data" feature is in +:term:`DISTRO_FEATURES` as well as +"qemu-usermode" being in +:term:`MACHINE_FEATURES`. + +.. note:: + + This functionality is backfilled by default and, if not applicable, + should be disabled through ``DISTRO_FEATURES_BACKFILL_CONSIDERED`` or + ``MACHINE_FEATURES_BACKFILL_CONSIDERED``, respectively. + +.. _ref-classes-grub-efi: + +``grub-efi.bbclass`` +==================== + +The ``grub-efi`` class provides ``grub-efi``-specific functions for +building bootable images. + +This class supports several variables: + +- :term:`INITRD`: Indicates list of filesystem images to + concatenate and use as an initial RAM disk (initrd) (optional). + +- :term:`ROOTFS`: Indicates a filesystem image to include + as the root filesystem (optional). + +- :term:`GRUB_GFXSERIAL`: Set this to "1" to have + graphics and serial in the boot menu. + +- :term:`LABELS`: A list of targets for the automatic + configuration. + +- :term:`APPEND`: An override list of append strings for + each ``LABEL``. + +- :term:`GRUB_OPTS`: Additional options to add to the + configuration (optional). Options are delimited using semi-colon + characters (``;``). + +- :term:`GRUB_TIMEOUT`: Timeout before executing + the default ``LABEL`` (optional). + +.. _ref-classes-gsettings: + +``gsettings.bbclass`` +===================== + +The ``gsettings`` class provides common functionality for recipes that +need to install GSettings (glib) schemas. The schemas are assumed to be +part of the main package. Appropriate post-install and post-remove +(postinst/postrm) scriptlets are added to register and unregister the +schemas in the target image. + +.. _ref-classes-gtk-doc: + +``gtk-doc.bbclass`` +=================== + +The ``gtk-doc`` class is a helper class to pull in the appropriate +``gtk-doc`` dependencies and disable ``gtk-doc``. + +.. _ref-classes-gtk-icon-cache: + +``gtk-icon-cache.bbclass`` +========================== + +The ``gtk-icon-cache`` class generates the proper post-install and +post-remove (postinst/postrm) scriptlets for packages that use GTK+ and +install icons. These scriptlets call ``gtk-update-icon-cache`` to add +the fonts to GTK+'s icon cache. Since the cache files are +architecture-specific, ``gtk-update-icon-cache`` is run using QEMU if +the postinst scriptlets need to be run on the build host during image +creation. + +.. _ref-classes-gtk-immodules-cache: + +``gtk-immodules-cache.bbclass`` +=============================== + +The ``gtk-immodules-cache`` class generates the proper post-install and +post-remove (postinst/postrm) scriptlets for packages that install GTK+ +input method modules for virtual keyboards. These scriptlets call +``gtk-update-icon-cache`` to add the input method modules to the cache. +Since the cache files are architecture-specific, +``gtk-update-icon-cache`` is run using QEMU if the postinst scriptlets +need to be run on the build host during image creation. + +If the input method modules being installed are in packages other than +the main package, set +:term:`GTKIMMODULES_PACKAGES` to specify +the packages containing the modules. + +.. _ref-classes-gzipnative: + +``gzipnative.bbclass`` +====================== + +The ``gzipnative`` class enables the use of different native versions of +``gzip`` and ``pigz`` rather than the versions of these tools from the +build host. + +.. _ref-classes-icecc: + +``icecc.bbclass`` +================= + +The ``icecc`` class supports +`Icecream `__, which facilitates +taking compile jobs and distributing them among remote machines. + +The class stages directories with symlinks from ``gcc`` and ``g++`` to +``icecc``, for both native and cross compilers. Depending on each +configure or compile, the OpenEmbedded build system adds the directories +at the head of the ``PATH`` list and then sets the ``ICECC_CXX`` and +``ICEC_CC`` variables, which are the paths to the ``g++`` and ``gcc`` +compilers, respectively. + +For the cross compiler, the class creates a ``tar.gz`` file that +contains the Yocto Project toolchain and sets ``ICECC_VERSION``, which +is the version of the cross-compiler used in the cross-development +toolchain, accordingly. + +The class handles all three different compile stages (i.e native +,cross-kernel and target) and creates the necessary environment +``tar.gz`` file to be used by the remote machines. The class also +supports SDK generation. + +If :term:`ICECC_PATH` is not set in your +``local.conf`` file, then the class tries to locate the ``icecc`` binary +using ``which``. If :term:`ICECC_ENV_EXEC` is set +in your ``local.conf`` file, the variable should point to the +``icecc-create-env`` script provided by the user. If you do not point to +a user-provided script, the build system uses the default script +provided by the recipe ``icecc-create-env-native.bb``. + +.. note:: + + This script is a modified version and not the one that comes with + icecc. + +If you do not want the Icecream distributed compile support to apply to +specific recipes or classes, you can effectively "blacklist" them by +listing the recipes and classes using the +:term:`ICECC_USER_PACKAGE_BL` and +:term:`ICECC_USER_CLASS_BL`, variables, +respectively, in your ``local.conf`` file. Doing so causes the +OpenEmbedded build system to handle these compilations locally. + +Additionally, you can list recipes using the +:term:`ICECC_USER_PACKAGE_WL` variable in +your ``local.conf`` file to force ``icecc`` to be enabled for recipes +using an empty :term:`PARALLEL_MAKE` variable. + +Inheriting the ``icecc`` class changes all sstate signatures. +Consequently, if a development team has a dedicated build system that +populates :term:`SSTATE_MIRRORS` and they want to +reuse sstate from ``SSTATE_MIRRORS``, then all developers and the build +system need to either inherit the ``icecc`` class or nobody should. + +At the distribution level, you can inherit the ``icecc`` class to be +sure that all builders start with the same sstate signatures. After +inheriting the class, you can then disable the feature by setting the +:term:`ICECC_DISABLED` variable to "1" as follows: +:: + + INHERIT_DISTRO_append = " icecc" + ICECC_DISABLED ??= "1" + +This practice +makes sure everyone is using the same signatures but also requires +individuals that do want to use Icecream to enable the feature +individually as follows in your ``local.conf`` file: +:: + + ICECC_DISABLED = "" + +.. _ref-classes-image: + +``image.bbclass`` +================= + +The ``image`` class helps support creating images in different formats. +First, the root filesystem is created from packages using one of the +``rootfs*.bbclass`` files (depending on the package format used) and +then one or more image files are 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. + +For information on customizing images, see the +":ref:`dev-manual/common-tasks:customizing images`" section +in the Yocto Project Development Tasks Manual. For information on how +images are created, see the +":ref:`overview-manual/concepts:images`" section in the +Yocto Project Overview and Concpets Manual. + +.. _ref-classes-image-buildinfo: + +``image-buildinfo.bbclass`` +=========================== + +The ``image-buildinfo`` class writes information to the target +filesystem on ``/etc/build``. + +.. _ref-classes-image_types: + +``image_types.bbclass`` +======================= + +The ``image_types`` class defines all of the standard image output types +that you can enable through the +:term:`IMAGE_FSTYPES` variable. You can use this +class as a reference on how to add support for custom image output +types. + +By default, the :ref:`image ` class automatically +enables the ``image_types`` class. The ``image`` class uses the +``IMGCLASSES`` variable as follows: +:: + + IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}" + IMGCLASSES += "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}" + IMGCLASSES += "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg', 'image-live', '', d)}" + IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container', '', d)}" + IMGCLASSES += "image_types_wic" + IMGCLASSES += "rootfs-postcommands" + IMGCLASSES += "image-postinst-intercepts" + inherit ${IMGCLASSES} + +The ``image_types`` class also handles conversion and compression of images. + +.. note:: + + To build a VMware VMDK image, you need to add "wic.vmdk" to + ``IMAGE_FSTYPES``. This would also be similar for Virtual Box Virtual Disk + Image ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images. + +.. _ref-classes-image-live: + +``image-live.bbclass`` +====================== + +This class controls building "live" (i.e. HDDIMG and ISO) images. Live +images contain syslinux for legacy booting, as well as the bootloader +specified by :term:`EFI_PROVIDER` if +:term:`MACHINE_FEATURES` contains "efi". + +Normally, you do not use this class directly. Instead, you add "live" to +:term:`IMAGE_FSTYPES`. + +.. _ref-classes-image-mklibs: + +``image-mklibs.bbclass`` +======================== + +The ``image-mklibs`` class enables the use of the ``mklibs`` utility +during the :ref:`ref-tasks-rootfs` task, which optimizes +the size of libraries contained in the image. + +By default, the class is enabled in the ``local.conf.template`` using +the :term:`USER_CLASSES` variable as follows: +:: + + USER_CLASSES ?= "buildstats image-mklibs image-prelink" + +.. _ref-classes-image-prelink: + +``image-prelink.bbclass`` +========================= + +The ``image-prelink`` class enables the use of the ``prelink`` utility +during the :ref:`ref-tasks-rootfs` task, which optimizes +the dynamic linking of shared libraries to reduce executable startup +time. + +By default, the class is enabled in the ``local.conf.template`` using +the :term:`USER_CLASSES` variable as follows: +:: + + USER_CLASSES ?= "buildstats image-mklibs image-prelink" + +.. _ref-classes-insane: + +``insane.bbclass`` +================== + +The ``insane`` class adds a step to the package generation process so +that output quality assurance checks are generated by the OpenEmbedded +build system. 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. + +You can configure the sanity checks so that specific test failures +either raise a warning or an error message. Typically, failures for new +tests generate a warning. Subsequent failures for the same test would +then generate an error message once the metadata is in a known and good +condition. See the ":doc:`/ref-manual/qa-checks`" Chapter for a list of all the warning +and error messages you might encounter using a default configuration. + +Use the :term:`WARN_QA` and +:term:`ERROR_QA` variables to control the behavior of +these checks at the global level (i.e. in your custom distro +configuration). However, to skip one or more checks in recipes, you +should use :term:`INSANE_SKIP`. For example, to skip +the check for symbolic link ``.so`` files in the main package of a +recipe, add the following to the recipe. You need to realize that the +package name override, in this example ``${PN}``, must be used: +:: + + INSANE_SKIP_${PN} += "dev-so" + +Please keep in mind that the QA checks +exist in order to detect real or potential problems in the packaged +output. So exercise caution when disabling these checks. + +The following list shows the tests you can list with the ``WARN_QA`` and +``ERROR_QA`` variables: + +- ``already-stripped:`` Checks that produced binaries have not + already been stripped prior to the build system extracting debug + symbols. It is common for upstream software projects to default to + stripping debug symbols for output binaries. In order for debugging + to work on the target using ``-dbg`` packages, this stripping must be + disabled. + +- ``arch:`` Checks the Executable and Linkable Format (ELF) type, bit + size, and endianness of any binaries to ensure they match the target + architecture. This test fails if any binaries do not match the type + since there would be an incompatibility. The test could indicate that + the wrong compiler or compiler options have been used. Sometimes + software, like bootloaders, might need to bypass this check. + +- ``buildpaths:`` Checks for paths to locations on the build host + inside the output files. Currently, this test triggers too many false + positives and thus is not normally enabled. + +- ``build-deps:`` Determines if a build-time dependency that is + specified through :term:`DEPENDS`, explicit + :term:`RDEPENDS`, or task-level dependencies exists + to match any runtime dependency. This determination is particularly + useful to discover where runtime dependencies are detected and added + during packaging. If no explicit dependency has been specified within + the metadata, at the packaging stage it is too late to ensure that + the dependency is built, and thus you can end up with an error when + the package is installed into the image during the + :ref:`ref-tasks-rootfs` task because the auto-detected + dependency was not satisfied. An example of this would be where the + :ref:`update-rc.d ` class automatically + adds a dependency on the ``initscripts-functions`` package to + packages that install an initscript that refers to + ``/etc/init.d/functions``. The recipe should really have an explicit + ``RDEPENDS`` for the package in question on ``initscripts-functions`` + so that the OpenEmbedded build system is able to ensure that the + ``initscripts`` recipe is actually built and thus the + ``initscripts-functions`` package is made available. + +- ``compile-host-path:`` Checks the + :ref:`ref-tasks-compile` log for indications that + paths to locations on the build host were used. Using such paths + might result in host contamination of the build output. + +- ``debug-deps:`` Checks that all packages except ``-dbg`` packages + do not depend on ``-dbg`` packages, which would cause a packaging + bug. + +- ``debug-files:`` Checks for ``.debug`` directories in anything but + the ``-dbg`` package. The debug files should all be in the ``-dbg`` + package. Thus, anything packaged elsewhere is incorrect packaging. + +- ``dep-cmp:`` Checks for invalid version comparison statements in + runtime dependency relationships between packages (i.e. in + :term:`RDEPENDS`, + :term:`RRECOMMENDS`, + :term:`RSUGGESTS`, + :term:`RPROVIDES`, + :term:`RREPLACES`, and + :term:`RCONFLICTS` variable values). Any invalid + comparisons might trigger failures or undesirable behavior when + passed to the package manager. + +- ``desktop:`` Runs the ``desktop-file-validate`` program against any + ``.desktop`` files to validate their contents against the + specification for ``.desktop`` files. + +- ``dev-deps:`` Checks that all packages except ``-dev`` or + ``-staticdev`` packages do not depend on ``-dev`` packages, which + would be a packaging bug. + +- ``dev-so:`` Checks that the ``.so`` symbolic links are in the + ``-dev`` package and not in any of the other packages. In general, + these symlinks are only useful for development purposes. Thus, the + ``-dev`` package is the correct location for them. Some very rare + cases do exist for dynamically loaded modules where these symlinks + are needed instead in the main package. + +- ``file-rdeps:`` Checks that file-level dependencies identified by + the OpenEmbedded build system at packaging time are satisfied. For + example, a shell script might start with the line ``#!/bin/bash``. + This line would translate to a file dependency on ``/bin/bash``. Of + the three package managers that the OpenEmbedded build system + supports, only RPM directly handles file-level dependencies, + resolving them automatically to packages providing the files. + However, the lack of that functionality in the other two package + managers does not mean the dependencies do not still need resolving. + This QA check attempts to ensure that explicitly declared + :term:`RDEPENDS` exist to handle any file-level + dependency detected in packaged files. + +- ``files-invalid:`` Checks for :term:`FILES` variable + values that contain "//", which is invalid. + +- ``host-user-contaminated:`` Checks that no package produced by the + recipe contains any files outside of ``/home`` with a user or group + ID that matches the user running BitBake. A match usually indicates + that the files are being installed with an incorrect UID/GID, since + target IDs are independent from host IDs. For additional information, + see the section describing the + :ref:`ref-tasks-install` task. + +- ``incompatible-license:`` Report when packages are excluded from + being created due to being marked with a license that is in + :term:`INCOMPATIBLE_LICENSE`. + +- ``install-host-path:`` Checks the + :ref:`ref-tasks-install` log for indications that + paths to locations on the build host were used. Using such paths + might result in host contamination of the build output. + +- ``installed-vs-shipped:`` Reports when files have been installed + within ``do_install`` but have not been included in any package by + way of the :term:`FILES` variable. Files that do not + appear in any package cannot be present in an image later on in the + build process. Ideally, all installed files should be packaged or not + installed at all. These files can be deleted at the end of + ``do_install`` if the files are not needed in any package. + +- ``invalid-chars:`` Checks that the recipe metadata variables + :term:`DESCRIPTION`, + :term:`SUMMARY`, :term:`LICENSE`, and + :term:`SECTION` do not contain non-UTF-8 characters. + Some package managers do not support such characters. + +- ``invalid-packageconfig:`` Checks that no undefined features are + being added to :term:`PACKAGECONFIG`. For + example, any name "foo" for which the following form does not exist: + :: + + PACKAGECONFIG[foo] = "..." + +- ``la:`` Checks ``.la`` files for any ``TMPDIR`` paths. Any ``.la`` + file containing these paths is incorrect since ``libtool`` adds the + correct sysroot prefix when using the files automatically itself. + +- ``ldflags:`` Ensures that the binaries were linked with the + :term:`LDFLAGS` options provided by the build system. + If this test fails, check that the ``LDFLAGS`` variable is being + passed to the linker command. + +- ``libdir:`` Checks for libraries being installed into incorrect + (possibly hardcoded) installation paths. For example, this test will + catch recipes that install ``/lib/bar.so`` when ``${base_libdir}`` is + "lib32". Another example is when recipes install + ``/usr/lib64/foo.so`` when ``${libdir}`` is "/usr/lib". + +- ``libexec:`` Checks if a package contains files in + ``/usr/libexec``. This check is not performed if the ``libexecdir`` + variable has been set explicitly to ``/usr/libexec``. + +- ``packages-list:`` Checks for the same package being listed + multiple times through the :term:`PACKAGES` variable + value. Installing the package in this manner can cause errors during + packaging. + +- ``perm-config:`` Reports lines in ``fs-perms.txt`` that have an + invalid format. + +- ``perm-line:`` Reports lines in ``fs-perms.txt`` that have an + invalid format. + +- ``perm-link:`` Reports lines in ``fs-perms.txt`` that specify + 'link' where the specified target already exists. + +- ``perms:`` Currently, this check is unused but reserved. + +- ``pkgconfig:`` Checks ``.pc`` files for any + :term:`TMPDIR`/:term:`WORKDIR` paths. + Any ``.pc`` file containing these paths is incorrect since + ``pkg-config`` itself adds the correct sysroot prefix when the files + are accessed. + +- ``pkgname:`` Checks that all packages in + :term:`PACKAGES` have names that do not contain + invalid characters (i.e. characters other than 0-9, a-z, ., +, and + -). + +- ``pkgv-undefined:`` Checks to see if the ``PKGV`` variable is + undefined during :ref:`ref-tasks-package`. + +- ``pkgvarcheck:`` Checks through the variables + :term:`RDEPENDS`, + :term:`RRECOMMENDS`, + :term:`RSUGGESTS`, + :term:`RCONFLICTS`, + :term:`RPROVIDES`, + :term:`RREPLACES`, :term:`FILES`, + :term:`ALLOW_EMPTY`, ``pkg_preinst``, + ``pkg_postinst``, ``pkg_prerm`` and ``pkg_postrm``, and reports if + there are variable sets that are not package-specific. Using these + variables without a package suffix is bad practice, and might + unnecessarily complicate dependencies of other packages within the + same recipe or have other unintended consequences. + +- ``pn-overrides:`` Checks that a recipe does not have a name + (:term:`PN`) value that appears in + :term:`OVERRIDES`. If a recipe is named such that + its ``PN`` value matches something already in ``OVERRIDES`` (e.g. + ``PN`` happens to be the same as :term:`MACHINE` or + :term:`DISTRO`), it can have unexpected consequences. + For example, assignments such as ``FILES_${PN} = "xyz"`` effectively + turn into ``FILES = "xyz"``. + +- ``rpaths:`` Checks for rpaths in the binaries that contain build + system paths such as ``TMPDIR``. If this test fails, bad ``-rpath`` + options are being passed to the linker commands and your binaries + have potential security issues. + +- ``split-strip:`` Reports that splitting or stripping debug symbols + from binaries has failed. + +- ``staticdev:`` Checks for static library files (``*.a``) in + non-``staticdev`` packages. + +- ``symlink-to-sysroot:`` Checks for symlinks in packages that point + into :term:`TMPDIR` on the host. Such symlinks will + work on the host, but are clearly invalid when running on the target. + +- ``textrel:`` Checks for ELF binaries that contain relocations in + their ``.text`` sections, which can result in a performance impact at + runtime. See the explanation for the ``ELF binary`` message in + ":doc:`/ref-manual/qa-checks`" for more information regarding runtime performance + issues. + +- ``unlisted-pkg-lics:`` Checks that all declared licenses applying + for a package are also declared on the recipe level (i.e. any license + in ``LICENSE_*`` should appear in :term:`LICENSE`). + +- ``useless-rpaths:`` Checks for dynamic library load paths (rpaths) + in the binaries that by default on a standard system are searched by + the linker (e.g. ``/lib`` and ``/usr/lib``). While these paths will + not cause any breakage, they do waste space and are unnecessary. + +- ``var-undefined:`` Reports when variables fundamental to packaging + (i.e. :term:`WORKDIR`, + :term:`DEPLOY_DIR`, :term:`D`, + :term:`PN`, and :term:`PKGD`) are undefined + during :ref:`ref-tasks-package`. + +- ``version-going-backwards:`` If Build History is enabled, reports + when a package being written out has a lower version than the + previously written package under the same name. If you are placing + output packages into a feed and upgrading packages on a target system + using that feed, the version of a package going backwards can result + in the target system not correctly upgrading to the "new" version of + the package. + + .. note:: + + If you are not using runtime package management on your target + system, then you do not need to worry about this situation. + +- ``xorg-driver-abi:`` Checks that all packages containing Xorg + drivers have ABI dependencies. The ``xserver-xorg`` recipe provides + driver ABI names. All drivers should depend on the ABI versions that + they have been built against. Driver recipes that include + ``xorg-driver-input.inc`` or ``xorg-driver-video.inc`` will + automatically get these versions. Consequently, you should only need + to explicitly add dependencies to binary driver recipes. + +.. _ref-classes-insserv: + +``insserv.bbclass`` +=================== + +The ``insserv`` class uses the ``insserv`` utility to update the order +of symbolic links in ``/etc/rc?.d/`` within an image based on +dependencies specified by LSB headers in the ``init.d`` scripts +themselves. + +.. _ref-classes-kernel: + +``kernel.bbclass`` +================== + +The ``kernel`` 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 the :ref:`module ` class. + +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``. + +The ``kernel`` class contains logic that allows you to embed an initial +RAM filesystem (initramfs) image when you build the kernel image. For +information on how to build an initramfs, see the +":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section in +the Yocto Project Development Tasks Manual. + +Various other classes are used by the ``kernel`` and ``module`` classes +internally including the :ref:`kernel-arch `, +:ref:`module-base `, and +:ref:`linux-kernel-base ` classes. + +.. _ref-classes-kernel-arch: + +``kernel-arch.bbclass`` +======================= + +The ``kernel-arch`` class sets the ``ARCH`` environment variable for +Linux kernel compilation (including modules). + +.. _ref-classes-kernel-devicetree: + +``kernel-devicetree.bbclass`` +============================= + +The ``kernel-devicetree`` class, which is inherited by the +:ref:`kernel ` class, supports device tree +generation. + +.. _ref-classes-kernel-fitimage: + +``kernel-fitimage.bbclass`` +=========================== + +The ``kernel-fitimage`` class provides support to pack a kernel Image, +device trees and a RAM disk into a single FIT image. In theory, a FIT +image can support any number of kernels, RAM disks and device-trees. +However, ``kernel-fitimage`` currently only supports +limited usescases: just one kernel image, an optional RAM disk, and +any number of device tree. + +To create a FIT image, it is required that :term:`KERNEL_CLASSES` +is set to "kernel-fitimage" and :term:`KERNEL_IMAGETYPE` +is set to "fitImage". + +The options for the device tree compiler passed to mkimage -D feature +when creating the FIT image are specified using the +:term:`UBOOT_MKIMAGE_DTCOPTS` variable. + +Only a single kernel can be added to the FIT image created by +``kernel-fitimage`` and the kernel image in FIT is mandatory. The +address where the kernel image is to be loaded by U-boot is +specified by :term:`UBOOT_LOADADDRESS` and the entrypoint by +:term:`UBOOT_ENTRYPOINT`. + +Multiple device trees can be added to the FIT image created by +``kernel-fitimage`` and the device tree is optional. +The address where the device tree is to be loaded by U-boot is +specified by :term:`UBOOT_DTBO_LOADADDRESS` for device tree overlays +and by :term:`UBOOT_DTB_LOADADDRESS` for device tree binaries. + +Only a single RAM disk can be added to the FIT image created by +``kernel-fitimage`` and the RAM disk in FIT is optional. +The address where the RAM disk image is to be loaded by U-boot +is specified by :term:`UBOOT_RD_LOADADDRESS` and the entrypoint by +:term:`UBOOT_RD_ENTRYPOINT`. The ramdisk is added to FIT image when +:term:`INITRAMFS_IMAGE` is specified. + +The FIT image generated by ``kernel-fitimage`` class is signed when the +variables :term:`UBOOT_SIGN_ENABLE`, :term:`UBOOT_MKIMAGE_DTCOPTS`, +:term:`UBOOT_SIGN_KEYDIR` and :term:`UBOOT_SIGN_KEYNAME` are set +appropriately. The default values used for :term:`FIT_HASH_ALG` and +:term:`FIT_SIGN_ALG` in ``kernel-fitimage`` are "sha256" and +"rsa2048" respectively. The keys for signing fitImage can be generated using +the ``kernel-fitimage`` class when both :term:`FIT_GENERATE_KEYS` and +:term:`UBOOT_SIGN_ENABLE` are set to "1". + + +.. _ref-classes-kernel-grub: + +``kernel-grub.bbclass`` +======================= + +The ``kernel-grub`` class updates the boot area and the boot menu with +the kernel as the priority boot mechanism while installing a RPM to +update the kernel on a deployed target. + +.. _ref-classes-kernel-module-split: + +``kernel-module-split.bbclass`` +=============================== + +The ``kernel-module-split`` class provides common functionality for +splitting Linux kernel modules into separate packages. + +.. _ref-classes-kernel-uboot: + +``kernel-uboot.bbclass`` +======================== + +The ``kernel-uboot`` class provides support for building from +vmlinux-style kernel sources. + +.. _ref-classes-kernel-uimage: + +``kernel-uimage.bbclass`` +========================= + +The ``kernel-uimage`` class provides support to pack uImage. + +.. _ref-classes-kernel-yocto: + +``kernel-yocto.bbclass`` +======================== + +The ``kernel-yocto`` class provides common functionality for building +from linux-yocto style kernel source repositories. + +.. _ref-classes-kernelsrc: + +``kernelsrc.bbclass`` +===================== + +The ``kernelsrc`` class sets the Linux kernel source and version. + +.. _ref-classes-lib_package: + +``lib_package.bbclass`` +======================= + +The ``lib_package`` class supports recipes that build libraries and +produce executable binaries, where those binaries should not be +installed by default along with the library. Instead, the binaries are +added to a separate ``${``\ :term:`PN`\ ``}-bin`` package to +make their installation optional. + +.. _ref-classes-libc*: + +``libc*.bbclass`` +================= + +The ``libc*`` classes support recipes that build packages with ``libc``: + +- The ``libc-common`` class provides common support for building with + ``libc``. + +- The ``libc-package`` class supports packaging up ``glibc`` and + ``eglibc``. + +.. _ref-classes-license: + +``license.bbclass`` +=================== + +The ``license`` class provides license manifest creation and license +exclusion. This class is enabled by default using the default value for +the :term:`INHERIT_DISTRO` variable. + +.. _ref-classes-linux-kernel-base: + +``linux-kernel-base.bbclass`` +============================= + +The ``linux-kernel-base`` class provides common functionality for +recipes that build out of the Linux kernel source tree. These builds +goes beyond the kernel itself. For example, the Perf recipe also +inherits this class. + +.. _ref-classes-linuxloader: + +``linuxloader.bbclass`` +======================= + +Provides the function ``linuxloader()``, which gives the value of the +dynamic loader/linker provided on the platform. This value is used by a +number of other classes. + +.. _ref-classes-logging: + +``logging.bbclass`` +=================== + +The ``logging`` class provides the standard shell functions used to log +messages for various BitBake severity levels (i.e. ``bbplain``, +``bbnote``, ``bbwarn``, ``bberror``, ``bbfatal``, and ``bbdebug``). + +This class is enabled by default since it is inherited by the ``base`` +class. + +.. _ref-classes-meta: + +``meta.bbclass`` +================ + +The ``meta`` class is inherited by recipes that do not build any output +packages themselves, but act as a "meta" target for building other +recipes. + +.. _ref-classes-metadata_scm: + +``metadata_scm.bbclass`` +======================== + +The ``metadata_scm`` class provides functionality for querying the +branch and revision of a Source Code Manager (SCM) repository. + +The :ref:`base ` class uses this class to print the +revisions of each layer before starting every build. The +``metadata_scm`` class is enabled by default because it is inherited by +the ``base`` class. + +.. _ref-classes-migrate_localcount: + +``migrate_localcount.bbclass`` +============================== + +The ``migrate_localcount`` class verifies a recipe's localcount data and +increments it appropriately. + +.. _ref-classes-mime: + +``mime.bbclass`` +================ + +The ``mime`` class generates the proper post-install and post-remove +(postinst/postrm) scriptlets for packages that install MIME type files. +These scriptlets call ``update-mime-database`` to add the MIME types to +the shared database. + +.. _ref-classes-mirrors: + +``mirrors.bbclass`` +=================== + +The ``mirrors`` class sets up some standard +:term:`MIRRORS` entries for source code mirrors. These +mirrors provide a fall-back path in case the upstream source specified +in :term:`SRC_URI` within recipes is unavailable. + +This class is enabled by default since it is inherited by the +:ref:`base ` class. + +.. _ref-classes-module: + +``module.bbclass`` +================== + +The ``module`` class provides support for building out-of-tree Linux +kernel modules. The class inherits the +:ref:`module-base ` and +:ref:`kernel-module-split ` classes, +and implements the :ref:`ref-tasks-compile` and +:ref:`ref-tasks-install` tasks. The class provides +everything needed to build and package a kernel module. + +For general information on out-of-tree Linux kernel modules, see the +":ref:`kernel-dev/common:incorporating out-of-tree modules`" +section in the Yocto Project Linux Kernel Development Manual. + +.. _ref-classes-module-base: + +``module-base.bbclass`` +======================= + +The ``module-base`` class provides the base functionality for building +Linux kernel modules. Typically, a recipe that builds software that +includes one or more kernel modules and has its own means of building +the module inherits this class as opposed to inheriting the +:ref:`module ` class. + +.. _ref-classes-multilib*: + +``multilib*.bbclass`` +===================== + +The ``multilib*`` classes provide support for building libraries with +different target optimizations or target architectures and installing +them side-by-side in the same image. + +For more information on using the Multilib feature, see the +":ref:`dev-manual/common-tasks:combining multiple versions of library files into one image`" +section in the Yocto Project Development Tasks Manual. + +.. _ref-classes-native: + +``native.bbclass`` +================== + +The ``native`` class provides common functionality for recipes that +build tools to run on the :term:`Build Host` (i.e. tools that use the compiler +or other tools from the build host). + +You can create a recipe that builds tools that run natively on the host +a couple different ways: + +- Create a myrecipe\ ``-native.bb`` recipe that inherits the ``native`` + class. If you use this method, you must order the inherit statement + in the recipe after all other inherit statements so that the + ``native`` class is inherited last. + + .. note:: + + When creating a recipe this way, the recipe name must follow this + naming convention: + :: + + myrecipe-native.bb + + + Not using this naming convention can lead to subtle problems + caused by existing code that depends on that naming convention. + +- Create or modify a target recipe that contains the following: + :: + + BBCLASSEXTEND = "native" + + Inside the + recipe, use ``_class-native`` and ``_class-target`` overrides to + specify any functionality specific to the respective native or target + case. + +Although applied differently, the ``native`` class is used with both +methods. The advantage of the second method is that you do not need to +have two separate recipes (assuming you need both) for native and +target. All common parts of the recipe are automatically shared. + +.. _ref-classes-nativesdk: + +``nativesdk.bbclass`` +===================== + +The ``nativesdk`` class provides common functionality for recipes that +wish to build tools to run as part of an SDK (i.e. tools that run on +:term:`SDKMACHINE`). + +You can create a recipe that builds tools that run on the SDK machine a +couple different ways: + +- Create a ``nativesdk-``\ myrecipe\ ``.bb`` recipe that inherits the + ``nativesdk`` class. If you use this method, you must order the + inherit statement in the recipe after all other inherit statements so + that the ``nativesdk`` class is inherited last. + +- Create a ``nativesdk`` variant of any recipe by adding the following: + :: + + BBCLASSEXTEND = "nativesdk" + + Inside the + recipe, use ``_class-nativesdk`` and ``_class-target`` overrides to + specify any functionality specific to the respective SDK machine or + target case. + +.. note:: + + When creating a recipe, you must follow this naming convention: + :: + + nativesdk-myrecipe.bb + + + Not doing so can lead to subtle problems because code exists that + depends on the naming convention. + +Although applied differently, the ``nativesdk`` class is used with both +methods. The advantage of the second method is that you do not need to +have two separate recipes (assuming you need both) for the SDK machine +and the target. All common parts of the recipe are automatically shared. + +.. _ref-classes-nopackages: + +``nopackages.bbclass`` +====================== + +Disables packaging tasks for those recipes and classes where packaging +is not needed. + +.. _ref-classes-npm: + +``npm.bbclass`` +=============== + +Provides support for building Node.js software fetched using the `node +package manager (NPM) `__. + +.. note:: + + Currently, recipes inheriting this class must use the ``npm://`` + fetcher to have dependencies fetched and packaged automatically. + +For information on how to create NPM packages, see the +":ref:`dev-manual/common-tasks:creating node package manager (npm) packages`" +section in the Yocto Project Development Tasks Manual. + +.. _ref-classes-oelint: + +``oelint.bbclass`` +================== + +The ``oelint`` class is an obsolete lint checking tool that exists in +``meta/classes`` in the :term:`Source Directory`. + +A number of classes exist that could be generally useful in OE-Core but +are never actually used within OE-Core itself. The ``oelint`` class is +one such example. However, being aware of this class can reduce the +proliferation of different versions of similar classes across multiple +layers. + +.. _ref-classes-own-mirrors: + +``own-mirrors.bbclass`` +======================= + +The ``own-mirrors`` class makes it easier to set up your own +:term:`PREMIRRORS` from which to first fetch source +before attempting to fetch it from the upstream specified in +:term:`SRC_URI` within each recipe. + +To use this class, inherit it globally and specify +:term:`SOURCE_MIRROR_URL`. Here is an example: +:: + + INHERIT += "own-mirrors" + SOURCE_MIRROR_URL = "http://example.com/my-source-mirror" + +You can specify only a single URL +in ``SOURCE_MIRROR_URL``. + +.. _ref-classes-package: + +``package.bbclass`` +=================== + +The ``package`` class supports generating packages from a build's +output. The core generic functionality is in ``package.bbclass``. The +code specific to particular package types resides in these +package-specific classes: +:ref:`package_deb `, +:ref:`package_rpm `, +:ref:`package_ipk `, and +:ref:`package_tar `. + +.. note:: + + The + package_tar + class is broken and not supported. It is recommended that you do not + use this class. + +You can control the list of resulting package formats by using the +``PACKAGE_CLASSES`` variable defined in your ``conf/local.conf`` +configuration file, which is located in the :term:`Build 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. + +If you take the optional step to set up a repository (package feed) on +the development host that can be used by DNF, you can install packages +from the feed while you are running the image on the target (i.e. +runtime installation of packages). For more information, see the +":ref:`dev-manual/common-tasks:using runtime package management`" +section in the Yocto Project Development Tasks Manual. + +The package-specific class you choose can affect build-time performance +and has space ramifications. In general, building a package with IPK +takes about thirty percent less time as compared to using RPM 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 :term:`Metadata` than the IPK package +manager. Consequently, you might consider setting ``PACKAGE_CLASSES`` to +"package_ipk" if you are building smaller systems. + +Before making your package manager decision, however, you should +consider some further things about using RPM: + +- 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. + +- For smaller systems, the extra space used for the Berkeley Database + and the amount of metadata when using RPM can affect your ability to + perform on-device upgrades. + +You can find additional information on the effects of the package class +at these two Yocto Project mailing list links: + +- :yocto_lists:`/pipermail/poky/2011-May/006362.html` + +- :yocto_lists:`/pipermail/poky/2011-May/006363.html` + +.. _ref-classes-package_deb: + +``package_deb.bbclass`` +======================= + +The ``package_deb`` class provides support for creating packages that +use the Debian (i.e. ``.deb``) file format. The class ensures the +packages are written out in a ``.deb`` file format to the +``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory. + +This class inherits the :ref:`package ` class and +is enabled through the :term:`PACKAGE_CLASSES` +variable in the ``local.conf`` file. + +.. _ref-classes-package_ipk: + +``package_ipk.bbclass`` +======================= + +The ``package_ipk`` class provides support for creating packages that +use the IPK (i.e. ``.ipk``) file format. The class ensures the packages +are written out in a ``.ipk`` file format to the +``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory. + +This class inherits the :ref:`package ` class and +is enabled through the :term:`PACKAGE_CLASSES` +variable in the ``local.conf`` file. + +.. _ref-classes-package_rpm: + +``package_rpm.bbclass`` +======================= + +The ``package_rpm`` class provides support for creating packages that +use the RPM (i.e. ``.rpm``) file format. The class ensures the packages +are written out in a ``.rpm`` file format to the +``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory. + +This class inherits the :ref:`package ` class and +is enabled through the :term:`PACKAGE_CLASSES` +variable in the ``local.conf`` file. + +.. _ref-classes-package_tar: + +``package_tar.bbclass`` +======================= + +The ``package_tar`` class provides support for creating tarballs. The +class ensures the packages are written out in a tarball format to the +``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory. + +This class inherits the :ref:`package ` class and +is enabled through the :term:`PACKAGE_CLASSES` +variable in the ``local.conf`` file. + +.. note:: + + You cannot specify the ``package_tar`` class first using the + ``PACKAGE_CLASSES`` variable. You must use ``.deb``, ``.ipk``, or ``.rpm`` + file formats for your image or SDK. + +.. _ref-classes-packagedata: + +``packagedata.bbclass`` +======================= + +The ``packagedata`` class provides common functionality for reading +``pkgdata`` files found in :term:`PKGDATA_DIR`. These +files contain information about each output package produced by the +OpenEmbedded build system. + +This class is enabled by default because it is inherited by the +:ref:`package ` class. + +.. _ref-classes-packagegroup: + +``packagegroup.bbclass`` +======================== + +The ``packagegroup`` class sets default values appropriate for package +group recipes (e.g. ``PACKAGES``, ``PACKAGE_ARCH``, ``ALLOW_EMPTY``, and +so forth). It is highly recommended that all package group recipes +inherit this class. + +For information on how to use this class, see the +":ref:`dev-manual/common-tasks:customizing images using custom package groups`" +section in the Yocto Project Development Tasks Manual. + +Previously, this class was called the ``task`` class. + +.. _ref-classes-patch: + +``patch.bbclass`` +================= + +The ``patch`` class provides all functionality for applying patches +during the :ref:`ref-tasks-patch` task. + +This class is enabled by default because it is inherited by the +:ref:`base ` class. + +.. _ref-classes-perlnative: + +``perlnative.bbclass`` +====================== + +When inherited by a recipe, the ``perlnative`` class supports using the +native version of Perl built by the build system rather than using the +version provided by the build host. + +.. _ref-classes-pixbufcache: + +``pixbufcache.bbclass`` +======================= + +The ``pixbufcache`` class generates the proper post-install and +post-remove (postinst/postrm) scriptlets for packages that install +pixbuf loaders, which are used with ``gdk-pixbuf``. These scriptlets +call ``update_pixbuf_cache`` to add the pixbuf loaders to the cache. +Since the cache files are architecture-specific, ``update_pixbuf_cache`` +is run using QEMU if the postinst scriptlets need to be run on the build +host during image creation. + +If the pixbuf loaders being installed are in packages other than the +recipe's main package, set +:term:`PIXBUF_PACKAGES` to specify the packages +containing the loaders. + +.. _ref-classes-pkgconfig: + +``pkgconfig.bbclass`` +===================== + +The ``pkgconfig`` class provides a standard way to get header and +library information by using ``pkg-config``. This class aims to smooth +integration of ``pkg-config`` into libraries that use it. + +During staging, BitBake installs ``pkg-config`` data into the +``sysroots/`` directory. By making use of sysroot functionality within +``pkg-config``, the ``pkgconfig`` class no longer has to manipulate the +files. + +.. _ref-classes-populate-sdk: + +``populate_sdk.bbclass`` +======================== + +The ``populate_sdk`` class provides support for SDK-only recipes. For +information on advantages gained when building a cross-development +toolchain using the :ref:`ref-tasks-populate_sdk` +task, see the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" +section in the Yocto Project Application Development and the Extensible +Software Development Kit (eSDK) manual. + +.. _ref-classes-populate-sdk-*: + +``populate_sdk_*.bbclass`` +========================== + +The ``populate_sdk_*`` classes support SDK creation and consist of the +following classes: + +- ``populate_sdk_base``: The base class supporting SDK creation under + all package managers (i.e. DEB, RPM, and opkg). + +- ``populate_sdk_deb``: Supports creation of the SDK given the Debian + package manager. + +- ``populate_sdk_rpm``: Supports creation of the SDK given the RPM + package manager. + +- ``populate_sdk_ipk``: Supports creation of the SDK given the opkg + (IPK format) package manager. + +- ``populate_sdk_ext``: Supports extensible SDK creation under all + package managers. + +The ``populate_sdk_base`` class inherits the appropriate +``populate_sdk_*`` (i.e. ``deb``, ``rpm``, and ``ipk``) based on +:term:`IMAGE_PKGTYPE`. + +The base class ensures all source and destination directories are +established and then populates the SDK. After populating the SDK, the +``populate_sdk_base`` class constructs two sysroots: +``${``\ :term:`SDK_ARCH`\ ``}-nativesdk``, which +contains the cross-compiler and associated tooling, and the target, +which contains a target root filesystem that is configured for the SDK +usage. These two images reside in :term:`SDK_OUTPUT`, +which consists of the following: +:: + + ${SDK_OUTPUT}/${SDK_ARCH}-nativesdk-pkgs + ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/target-pkgs + +Finally, the base populate SDK class creates the toolchain environment +setup script, the tarball of the SDK, and the installer. + +The respective ``populate_sdk_deb``, ``populate_sdk_rpm``, and +``populate_sdk_ipk`` classes each support the specific type of SDK. +These classes are inherited by and used with the ``populate_sdk_base`` +class. + +For more information on the cross-development toolchain generation, see +the ":ref:`overview-manual/concepts:cross-development toolchain generation`" +section in the Yocto Project Overview and Concepts Manual. For +information on advantages gained when building a cross-development +toolchain using the :ref:`ref-tasks-populate_sdk` +task, see the +":ref:`sdk-manual/appendix-obtain:building an sdk installer`" +section in the Yocto Project Application Development and the Extensible +Software Development Kit (eSDK) manual. + +.. _ref-classes-prexport: + +``prexport.bbclass`` +==================== + +The ``prexport`` class provides functionality for exporting +:term:`PR` values. + +.. note:: + + This class is not intended to be used directly. Rather, it is enabled + when using "``bitbake-prserv-tool export``". + +.. _ref-classes-primport: + +``primport.bbclass`` +==================== + +The ``primport`` class provides functionality for importing +:term:`PR` values. + +.. note:: + + This class is not intended to be used directly. Rather, it is enabled + when using "``bitbake-prserv-tool import``". + +.. _ref-classes-prserv: + +``prserv.bbclass`` +================== + +The ``prserv`` class provides functionality for using a :ref:`PR +service ` in order to +automatically manage the incrementing of the :term:`PR` +variable for each recipe. + +This class is enabled by default because it is inherited by the +:ref:`package ` class. However, the OpenEmbedded +build system will not enable the functionality of this class unless +:term:`PRSERV_HOST` has been set. + +.. _ref-classes-ptest: + +``ptest.bbclass`` +================= + +The ``ptest`` class provides functionality for packaging and installing +runtime tests for recipes that build software that provides these tests. + +This class is intended to be inherited by individual recipes. However, +the class' functionality is largely disabled unless "ptest" appears in +:term:`DISTRO_FEATURES`. See the +":ref:`dev-manual/common-tasks:testing packages with ptest`" +section in the Yocto Project Development Tasks Manual for more information +on ptest. + +.. _ref-classes-ptest-gnome: + +``ptest-gnome.bbclass`` +======================= + +Enables package tests (ptests) specifically for GNOME packages, which +have tests intended to be executed with ``gnome-desktop-testing``. + +For information on setting up and running ptests, see the +":ref:`dev-manual/common-tasks:testing packages with ptest`" +section in the Yocto Project Development Tasks Manual. + +.. _ref-classes-python-dir: + +``python-dir.bbclass`` +====================== + +The ``python-dir`` class provides the base version, location, and site +package location for Python. + +.. _ref-classes-python3native: + +``python3native.bbclass`` +========================= + +The ``python3native`` class supports using the native version of Python +3 built by the build system rather than support of the version provided +by the build host. + +.. _ref-classes-pythonnative: + +``pythonnative.bbclass`` +======================== + +When inherited by a recipe, the ``pythonnative`` class supports using +the native version of Python built by the build system rather than using +the version provided by the build host. + +.. _ref-classes-qemu: + +``qemu.bbclass`` +================ + +The ``qemu`` class provides functionality for recipes that either need +QEMU or test for the existence of QEMU. Typically, this class is used to +run programs for a target system on the build host using QEMU's +application emulation mode. + +.. _ref-classes-recipe_sanity: + +``recipe_sanity.bbclass`` +========================= + +The ``recipe_sanity`` class checks for the presence of any host system +recipe prerequisites that might affect the build (e.g. variables that +are set or software that is present). + +.. _ref-classes-relocatable: + +``relocatable.bbclass`` +======================= + +The ``relocatable`` class enables relocation of binaries when they are +installed into the sysroot. + +This class makes use of the :ref:`chrpath ` class +and is used by both the :ref:`cross ` and +:ref:`native ` classes. + +.. _ref-classes-remove-libtool: + +``remove-libtool.bbclass`` +========================== + +The ``remove-libtool`` class adds a post function to the +:ref:`ref-tasks-install` task to remove all ``.la`` files +installed by ``libtool``. Removing these files results in them being +absent from both the sysroot and target packages. + +If a recipe needs the ``.la`` files to be installed, then the recipe can +override the removal by setting ``REMOVE_LIBTOOL_LA`` to "0" as follows: +:: + + REMOVE_LIBTOOL_LA = "0" + +.. note:: + + The ``remove-libtool`` class is not enabled by default. + +.. _ref-classes-report-error: + +``report-error.bbclass`` +======================== + +The ``report-error`` class supports enabling the :ref:`error reporting +tool `", +which allows you to submit build error information to a central database. + +The class collects debug information for recipe, recipe version, task, +machine, distro, build system, target system, host distro, branch, +commit, and log. From the information, report files using a JSON format +are created and stored in +``${``\ :term:`LOG_DIR`\ ``}/error-report``. + +.. _ref-classes-rm-work: + +``rm_work.bbclass`` +=================== + +The ``rm_work`` class supports deletion of temporary workspace, which +can ease your hard drive demands during builds. + +The OpenEmbedded build system can use a substantial amount of disk space +during the build process. A portion of this space is the work files +under the ``${TMPDIR}/work`` directory for each recipe. Once the build +system generates the packages for a recipe, the work files for that +recipe are no longer needed. However, by default, the build system +preserves these files for inspection and possible debugging purposes. If +you would rather have these files deleted to save disk space as the +build progresses, you can enable ``rm_work`` by adding the following to +your ``local.conf`` file, which is found in the :term:`Build Directory`. +:: + + INHERIT += "rm_work" + +If you are +modifying and building source code out of the work directory for a +recipe, enabling ``rm_work`` will potentially result in your changes to +the source being lost. To exclude some recipes from having their work +directories deleted by ``rm_work``, you can add the names of the recipe +or recipes you are working on to the ``RM_WORK_EXCLUDE`` variable, which +can also be set in your ``local.conf`` file. Here is an example: +:: + + RM_WORK_EXCLUDE += "busybox glibc" + +.. _ref-classes-rootfs*: + +``rootfs*.bbclass`` +=================== + +The ``rootfs*`` classes support creating the root filesystem for an +image and consist of the following classes: + +- The ``rootfs-postcommands`` class, which defines filesystem + post-processing functions for image recipes. + +- The ``rootfs_deb`` class, which supports creation of root filesystems + for images built using ``.deb`` packages. + +- The ``rootfs_rpm`` class, which supports creation of root filesystems + for images built using ``.rpm`` packages. + +- The ``rootfs_ipk`` class, which supports creation of root filesystems + for images built using ``.ipk`` packages. + +- The ``rootfsdebugfiles`` class, which installs additional files found + on the build host directly into the root filesystem. + +The root filesystem is created from packages using one of the +``rootfs*.bbclass`` files as determined by the +:term:`PACKAGE_CLASSES` variable. + +For information on how root filesystem images are created, see the +":ref:`overview-manual/concepts:image generation`" +section in the Yocto Project Overview and Concepts Manual. + +.. _ref-classes-sanity: + +``sanity.bbclass`` +================== + +The ``sanity`` class checks to see if prerequisite software is present +on the host system 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 determines whether to include this class. + +.. _ref-classes-scons: + +``scons.bbclass`` +================= + +The ``scons`` class supports recipes that need to build software that +uses the SCons build system. You can use the +:term:`EXTRA_OESCONS` variable to specify +additional configuration options you want to pass SCons command line. + +.. _ref-classes-sdl: + +``sdl.bbclass`` +=============== + +The ``sdl`` class supports recipes that need to build software that uses +the Simple DirectMedia Layer (SDL) library. + +.. _ref-classes-setuptools: + +``setuptools.bbclass`` +====================== + +The ``setuptools`` class supports Python version 2.x extensions that use +build systems based on ``setuptools``. If your recipe uses these build +systems, the recipe needs to inherit the ``setuptools`` class. + +.. _ref-classes-setuptools3: + +``setuptools3.bbclass`` +======================= + +The ``setuptools3`` class supports Python version 3.x extensions that +use build systems based on ``setuptools3``. If your recipe uses these +build systems, the recipe needs to inherit the ``setuptools3`` class. + +.. _ref-classes-sign_rpm: + +``sign_rpm.bbclass`` +==================== + +The ``sign_rpm`` class supports generating signed RPM packages. + +.. _ref-classes-sip: + +``sip.bbclass`` +=============== + +The ``sip`` class supports recipes that build or package SIP-based +Python bindings. + +.. _ref-classes-siteconfig: + +``siteconfig.bbclass`` +====================== + +The ``siteconfig`` class provides functionality for handling site +configuration. The class is used by the +:ref:`autotools ` class to accelerate the +:ref:`ref-tasks-configure` task. + +.. _ref-classes-siteinfo: + +``siteinfo.bbclass`` +==================== + +The ``siteinfo`` class provides information about the targets that might +be needed by other classes or recipes. + +As an example, consider Autotools, which 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. + +.. _ref-classes-sstate: + +``sstate.bbclass`` +================== + +The ``sstate`` class provides support for Shared State (sstate). By +default, the class is enabled through the +:term:`INHERIT_DISTRO` variable's default value. + +For more information on sstate, see the +":ref:`overview-manual/concepts:shared state cache`" +section in the Yocto Project Overview and Concepts Manual. + +.. _ref-classes-staging: + +``staging.bbclass`` +=================== + +The ``staging`` class installs files into individual recipe work +directories for sysroots. The class contains the following key tasks: + +- The :ref:`ref-tasks-populate_sysroot` task, + which is responsible for handing the files that end up in the recipe + sysroots. + +- The + :ref:`ref-tasks-prepare_recipe_sysroot` + task (a "partner" task to the ``populate_sysroot`` task), which + installs the files into the individual recipe work directories (i.e. + :term:`WORKDIR`). + +The code in the ``staging`` class is complex and basically works in two +stages: + +- *Stage One:* The first stage addresses recipes that have files they + want to share with other recipes that have dependencies on the + originating recipe. Normally these dependencies are installed through + the :ref:`ref-tasks-install` task into + ``${``\ :term:`D`\ ``}``. The ``do_populate_sysroot`` task + copies a subset of these files into ``${SYSROOT_DESTDIR}``. This + subset of files is controlled by the + :term:`SYSROOT_DIRS`, + :term:`SYSROOT_DIRS_NATIVE`, and + :term:`SYSROOT_DIRS_BLACKLIST` + variables. + + .. note:: + + Additionally, a recipe can customize the files further by + declaring a processing function in the ``SYSROOT_PREPROCESS_FUNCS`` + variable. + + A shared state (sstate) object is built from these files and the + files are placed into a subdirectory of + :ref:`structure-build-tmp-sysroots-components`. + The files are scanned for hardcoded paths to the original + installation location. If the location is found in text files, the + hardcoded locations are replaced by tokens and a list of the files + needing such replacements is created. These adjustments are referred + to as "FIXMEs". The list of files that are scanned for paths is + controlled by the :term:`SSTATE_SCAN_FILES` + variable. + +- *Stage Two:* The second stage addresses recipes that want to use + something from another recipe and declare a dependency on that recipe + through the :term:`DEPENDS` variable. The recipe will + have a + :ref:`ref-tasks-prepare_recipe_sysroot` + task and when this task executes, it creates the ``recipe-sysroot`` + and ``recipe-sysroot-native`` in the recipe work directory (i.e. + :term:`WORKDIR`). The OpenEmbedded build system + creates hard links to copies of the relevant files from + ``sysroots-components`` into the recipe work directory. + + .. note:: + + If hard links are not possible, the build system uses actual + copies. + + The build system then addresses any "FIXMEs" to paths as defined from + the list created in the first stage. + + Finally, any files in ``${bindir}`` within the sysroot that have the + prefix "``postinst-``" are executed. + + .. note:: + + Although such sysroot post installation scripts are not + recommended for general use, the files do allow some issues such + as user creation and module indexes to be addressed. + + Because recipes can have other dependencies outside of ``DEPENDS`` + (e.g. ``do_unpack[depends] += "tar-native:do_populate_sysroot"``), + the sysroot creation function ``extend_recipe_sysroot`` is also added + as a pre-function for those tasks whose dependencies are not through + ``DEPENDS`` but operate similarly. + + When installing dependencies into the sysroot, the code traverses the + dependency graph and processes dependencies in exactly the same way + as the dependencies would or would not be when installed from sstate. + This processing means, for example, a native tool would have its + native dependencies added but a target library would not have its + dependencies traversed or installed. The same sstate dependency code + is used so that builds should be identical regardless of whether + sstate was used or not. For a closer look, see the + ``setscene_depvalid()`` function in the + :ref:`sstate ` class. + + The build system is careful to maintain manifests of the files it + installs so that any given dependency can be installed as needed. The + sstate hash of the installed item is also stored so that if it + changes, the build system can reinstall it. + +.. _ref-classes-syslinux: + +``syslinux.bbclass`` +==================== + +The ``syslinux`` class provides syslinux-specific functions for building +bootable images. + +The class supports the following variables: + +- :term:`INITRD`: Indicates list of filesystem images to + concatenate and use as an initial RAM disk (initrd). This variable is + optional. + +- :term:`ROOTFS`: Indicates a filesystem image to include + as the root filesystem. This variable is optional. + +- :term:`AUTO_SYSLINUXMENU`: Enables creating + an automatic menu when set to "1". + +- :term:`LABELS`: Lists targets for automatic + configuration. + +- :term:`APPEND`: Lists append string overrides for each + label. + +- :term:`SYSLINUX_OPTS`: Lists additional options + to add to the syslinux file. Semicolon characters separate multiple + options. + +- :term:`SYSLINUX_SPLASH`: Lists a background + for the VGA boot menu when you are using the boot menu. + +- :term:`SYSLINUX_DEFAULT_CONSOLE`: Set + to "console=ttyX" to change kernel boot default console. + +- :term:`SYSLINUX_SERIAL`: Sets an alternate + serial port. Or, turns off serial when the variable is set with an + empty string. + +- :term:`SYSLINUX_SERIAL_TTY`: Sets an + alternate "console=tty..." kernel boot argument. + +.. _ref-classes-systemd: + +``systemd.bbclass`` +=================== + +The ``systemd`` class provides support for recipes that install systemd +unit files. + +The functionality for this class is disabled unless you have "systemd" +in :term:`DISTRO_FEATURES`. + +Under this class, the recipe or Makefile (i.e. whatever the recipe is +calling during the :ref:`ref-tasks-install` task) +installs unit files into +``${``\ :term:`D`\ ``}${systemd_unitdir}/system``. If the unit +files being installed go into packages other than the main package, you +need to set :term:`SYSTEMD_PACKAGES` in your +recipe to identify the packages in which the files will be installed. + +You should set :term:`SYSTEMD_SERVICE` to the +name of the service file. You should also use a package name override to +indicate the package to which the value applies. If the value applies to +the recipe's main package, use ``${``\ :term:`PN`\ ``}``. Here +is an example from the connman recipe: +:: + + SYSTEMD_SERVICE_${PN} = "connman.service" + +Services are set up to start on boot automatically +unless you have set +:term:`SYSTEMD_AUTO_ENABLE` to "disable". + +For more information on ``systemd``, see the +":ref:`dev-manual/common-tasks:selecting an initialization manager`" +section in the Yocto Project Development Tasks Manual. + +.. _ref-classes-systemd-boot: + +``systemd-boot.bbclass`` +======================== + +The ``systemd-boot`` class provides functions specific to the +systemd-boot bootloader for building bootable images. This is an +internal class and is not intended to be used directly. + +.. note:: + + The ``systemd-boot`` class is a result from merging the ``gummiboot`` class + used in previous Yocto Project releases with the ``systemd`` project. + +Set the :term:`EFI_PROVIDER` variable to +"systemd-boot" to use this class. Doing so creates a standalone EFI +bootloader that is not dependent on systemd. + +For information on more variables used and supported in this class, see +the :term:`SYSTEMD_BOOT_CFG`, +:term:`SYSTEMD_BOOT_ENTRIES`, and +:term:`SYSTEMD_BOOT_TIMEOUT` variables. + +You can also see the `Systemd-boot +documentation `__ +for more information. + +.. _ref-classes-terminal: + +``terminal.bbclass`` +==================== + +The ``terminal`` class provides support for starting a terminal session. +The :term:`OE_TERMINAL` variable controls which +terminal emulator is used for the session. + +Other classes use the ``terminal`` class anywhere a separate terminal +session needs to be started. For example, the +:ref:`patch ` class assuming +:term:`PATCHRESOLVE` is set to "user", the +:ref:`cml1 ` class, and the +:ref:`devshell ` class all use the ``terminal`` +class. + +.. _ref-classes-testimage*: + +``testimage*.bbclass`` +====================== + +The ``testimage*`` classes support running automated tests against +images using QEMU and on actual hardware. The classes handle loading the +tests and starting the image. To use the classes, you need to perform +steps to set up the environment. + +.. note:: + + Best practices include using :term:`IMAGE_CLASSES` rather than + :term:`INHERIT` to inherit the ``testimage`` class for automated image + testing. + +The tests are commands that run on the target system over ``ssh``. Each +test is written in Python and makes use of the ``unittest`` module. + +The ``testimage.bbclass`` runs tests on an image when called using the +following: +:: + + $ bitbake -c testimage image + +The ``testimage-auto`` class +runs tests on an image after the image is constructed (i.e. +:term:`TESTIMAGE_AUTO` must be set to "1"). + +For information on how to enable, run, and create new tests, see the +":ref:`dev-manual/common-tasks:performing automated runtime testing`" +section in the Yocto Project Development Tasks Manual. + +.. _ref-classes-testsdk: + +``testsdk.bbclass`` +=================== + +This class supports running automated tests against software development +kits (SDKs). The ``testsdk`` class runs tests on an SDK when called +using the following: +:: + + $ bitbake -c testsdk image + +.. note:: + + Best practices include using :term:`IMAGE_CLASSES` rather than + :term:`INHERIT` to inherit the ``testsdk`` class for automated SDK + testing. + +.. _ref-classes-texinfo: + +``texinfo.bbclass`` +=================== + +This class should be inherited by recipes whose upstream packages invoke +the ``texinfo`` utilities at build-time. Native and cross recipes are +made to use the dummy scripts provided by ``texinfo-dummy-native``, for +improved performance. Target architecture recipes use the genuine +Texinfo utilities. By default, they use the Texinfo utilities on the +host system. + +.. note:: + + If you want to use the Texinfo recipe shipped with the build system, + you can remove "texinfo-native" from :term:`ASSUME_PROVIDED` and makeinfo + from :term:`SANITY_REQUIRED_UTILITIES`. + +.. _ref-classes-toaster: + +``toaster.bbclass`` +=================== + +The ``toaster`` class collects information about packages and images and +sends them as events that the BitBake user interface can receive. The +class is enabled when the Toaster user interface is running. + +This class is not intended to be used directly. + +.. _ref-classes-toolchain-scripts: + +``toolchain-scripts.bbclass`` +============================= + +The ``toolchain-scripts`` class provides the scripts used for setting up +the environment for installed SDKs. + +.. _ref-classes-typecheck: + +``typecheck.bbclass`` +===================== + +The ``typecheck`` class provides support for validating the values of +variables set at the configuration level against their defined types. +The OpenEmbedded build system allows you to define the type of a +variable using the "type" varflag. Here is an example: +:: + + IMAGE_FEATURES[type] = "list" + +.. _ref-classes-uboot-config: + +``uboot-config.bbclass`` +======================== + +The ``uboot-config`` class provides support for U-Boot configuration for +a machine. Specify the machine in your recipe as follows: +:: + + UBOOT_CONFIG ??= + UBOOT_CONFIG[foo] = "config,images" + +You can also specify the machine using this method: +:: + + UBOOT_MACHINE = "config" + +See the :term:`UBOOT_CONFIG` and :term:`UBOOT_MACHINE` variables for additional +information. + +.. _ref-classes-uninative: + +``uninative.bbclass`` +===================== + +Attempts to isolate the build system from the host distribution's C +library in order to make re-use of native shared state artifacts across +different host distributions practical. With this class enabled, a +tarball containing a pre-built C library is downloaded at the start of +the build. In the Poky reference distribution this is enabled by default +through ``meta/conf/distro/include/yocto-uninative.inc``. Other +distributions that do not derive from poky can also +"``require conf/distro/include/yocto-uninative.inc``" to use this. +Alternatively if you prefer, you can build the uninative-tarball recipe +yourself, publish the resulting tarball (e.g. via HTTP) and set +``UNINATIVE_URL`` and ``UNINATIVE_CHECKSUM`` appropriately. For an +example, see the ``meta/conf/distro/include/yocto-uninative.inc``. + +The ``uninative`` class is also used unconditionally by the extensible +SDK. When building the extensible SDK, ``uninative-tarball`` is built +and the resulting tarball is included within the SDK. + +.. _ref-classes-update-alternatives: + +``update-alternatives.bbclass`` +=============================== + +The ``update-alternatives`` class helps the alternatives system when +multiple sources provide the same command. This situation occurs when +several programs that have the same or similar function are installed +with the same name. For example, the ``ar`` command is available from +the ``busybox``, ``binutils`` and ``elfutils`` packages. The +``update-alternatives`` 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. + +To use this class, you need to define a number of variables: + +- :term:`ALTERNATIVE` + +- :term:`ALTERNATIVE_LINK_NAME` + +- :term:`ALTERNATIVE_TARGET` + +- :term:`ALTERNATIVE_PRIORITY` + +These variables list alternative commands needed by a package, provide +pathnames for links, default links for targets, and so forth. For +details on how to use this class, see the comments in the +:yocto_git:`update-alternatives.bbclass ` +file. + +.. note:: + + You can use the ``update-alternatives`` command directly in your recipes. + However, this class simplifies things in most cases. + +.. _ref-classes-update-rc.d: + +``update-rc.d.bbclass`` +======================= + +The ``update-rc.d`` class uses ``update-rc.d`` to safely install an +initialization script on behalf of the package. The OpenEmbedded build +system 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. + +.. _ref-classes-useradd: + +``useradd*.bbclass`` +==================== + +The ``useradd*`` classes support the addition of users or groups for +usage by the package on the target. For example, if you have packages +that contain system services that should be run under their own user or +group, you can use these classes to enable creation of the user or +group. The ``meta-skeleton/recipes-skeleton/useradd/useradd-example.bb`` +recipe in the :term:`Source Directory` provides a simple +example that shows how to add three users and groups to two packages. +See the ``useradd-example.bb`` recipe for more information on how to use +these classes. + +The ``useradd_base`` class provides basic functionality for user or +groups settings. + +The ``useradd*`` classes support the +:term:`USERADD_PACKAGES`, +:term:`USERADD_PARAM`, +:term:`GROUPADD_PARAM`, and +:term:`GROUPMEMS_PARAM` variables. + +The ``useradd-staticids`` class supports the addition of users or groups +that have static user identification (``uid``) and group identification +(``gid``) values. + +The default behavior of the OpenEmbedded build system for assigning +``uid`` and ``gid`` values when packages add users and groups during +package install time is to add them dynamically. This works fine for +programs that do not care what the values of the resulting users and +groups become. In these cases, the order of the installation determines +the final ``uid`` and ``gid`` values. However, if non-deterministic +``uid`` and ``gid`` values are a problem, you can override the default, +dynamic application of these values by setting static values. When you +set static values, the OpenEmbedded build system looks in +:term:`BBPATH` for ``files/passwd`` and ``files/group`` +files for the values. + +To use static ``uid`` and ``gid`` values, you need to set some +variables. See the :term:`USERADDEXTENSION`, +:term:`USERADD_UID_TABLES`, +:term:`USERADD_GID_TABLES`, and +:term:`USERADD_ERROR_DYNAMIC` variables. +You can also see the :ref:`useradd ` class for +additional information. + +.. note:: + + You do not use the ``useradd-staticids`` class directly. You either enable + or disable the class by setting the ``USERADDEXTENSION`` variable. If you + enable or disable the class in a configured system, :term:`TMPDIR` might + contain incorrect ``uid`` and ``gid`` values. Deleting the ``TMPDIR`` + directory will correct this condition. + +.. _ref-classes-utility-tasks: + +``utility-tasks.bbclass`` +========================= + +The ``utility-tasks`` class provides support for various "utility" type +tasks that are applicable to all recipes, such as +:ref:`ref-tasks-clean` and +:ref:`ref-tasks-listtasks`. + +This class is enabled by default because it is inherited by the +:ref:`base ` class. + +.. _ref-classes-utils: + +``utils.bbclass`` +================= + +The ``utils`` class provides some useful Python functions that are +typically used in inline Python expressions (e.g. ``${@...}``). One +example use is for ``bb.utils.contains()``. + +This class is enabled by default because it is inherited by the +:ref:`base ` class. + +.. _ref-classes-vala: + +``vala.bbclass`` +================ + +The ``vala`` class supports recipes that need to build software written +using the Vala programming language. + +.. _ref-classes-waf: + +``waf.bbclass`` +=============== + +The ``waf`` class supports recipes that need to build software that uses +the Waf build system. You can use the +:term:`EXTRA_OECONF` or +:term:`PACKAGECONFIG_CONFARGS` variables +to specify additional configuration options to be passed on the Waf +command line. -- cgit v1.2.3