From 43d07a285181e64c30d98d10ff93ef50391efe59 Mon Sep 17 00:00:00 2001 From: Nicolas Dechesne Date: Mon, 5 Oct 2020 16:30:32 +0200 Subject: sphinx: remove DocBook files The Yocto Project documentation was migrated to Sphinx. Let's remove the deprecated DocBook files. (From yocto-docs rev: 28fb0e63b2fbfd6426b00498bf2682bb53fdd862) Signed-off-by: Nicolas Dechesne Signed-off-by: Richard Purdie --- documentation/ref-manual/ref-classes.xml | 3974 ------------------------------ 1 file changed, 3974 deletions(-) delete mode 100644 documentation/ref-manual/ref-classes.xml (limited to 'documentation/ref-manual/ref-classes.xml') diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml deleted file mode 100644 index 1dcd5fdd03..0000000000 --- a/documentation/ref-manual/ref-classes.xml +++ /dev/null @@ -1,3974 +0,0 @@ - %poky; ] > - - - -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 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 - Source Directory. - Class files can also be pointed to by - BUILDDIR - (e.g. build/) in the same way as - .conf files in the conf directory. - Class files are searched for in - BBPATH - using the same method by which .conf files are - searched. - - - - 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. - - -
- <filename>allarch.bbclass</filename> - - - 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). - - Unlike some distro recipes (e.g. Debian), OpenEmbedded recipes - that produce packages that depend on tunings through use of the - RDEPENDS - and - 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 - base and - 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. - -
- -
- <filename>archiver.bbclass</filename> - - - The archiver class supports releasing - source code and other materials with the binaries. - - - - For more details on the source archiver, see the - "Maintaining Open Source License Compliance During Your Product's Lifecycle" - section in the Yocto Project Development Tasks Manual. - You can also see the - ARCHIVER_MODE - variable for information about the variable flags (varflags) - that help control archive creation. - -
- -
- <filename>autotools*.bbclass</filename> - - - 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 - "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 - B == - S. - This method is useful when out-of-tree build support is either not - present or is broken. - - 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. - - do_configure - - Regenerates the - configure script (using autoreconf) and - then launches it with a standard set of arguments used during - cross-compilation. - You can pass additional parameters to - configure through the - EXTRA_OECONF - or - PACKAGECONFIG_CONFARGS - variables. - - do_compile - - Runs make with arguments that specify the - compiler and linker. - You can pass additional arguments through - the EXTRA_OEMAKE - variable. - - do_install - - Runs make install and passes in - ${D} - as DESTDIR. - - - -
- -
- <filename>base.bbclass</filename> - - - 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 - autotools - class or the - package - class. - - - - The class also contains some commonly used functions such as - oe_runmake, which runs - make with the arguments specified in - EXTRA_OEMAKE - variable as well as the arguments passed directly to - oe_runmake. - -
- -
- <filename>bash-completion.bbclass</filename> - - - Sets up packaging and dependencies appropriate for recipes that - build software that includes bash-completion data. - -
- -
- <filename>bin_package.bbclass</filename> - - - 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. - - 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 - "Fetchers" - section in the BitBake User Manual for more information on - supported BitBake Fetchers. - - -
- -
- <filename>binconfig.bbclass</filename> - - - 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 - BINCONFIG_GLOB - variable for more information. - -
- -
- <filename>binconfig-disabled.bbclass</filename> - - - An alternative version of the - 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 - BINCONFIG - variable within the recipe inheriting the class. - -
- -
- <filename>blacklist.bbclass</filename> - - - The blacklist class prevents - the OpenEmbedded build system from building specific recipes - (blacklists them). - To use this class, inherit the class globally and set - PNBLACKLIST - for each recipe you wish to blacklist. - Specify the 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." - - -
- -
- <filename>buildhistory.bbclass</filename> - - - 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 - "Maintaining Build Output Quality" - section in the Yocto Project Development Tasks Manual. - -
- -
- <filename>buildstats.bbclass</filename> - - - 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 - 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 - 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. - -
- -
- <filename>buildstats-summary.bbclass</filename> - - - When inherited globally, prints statistics at the end of the build - on sstate re-use. - In order to function, this class requires the - buildstats - class be enabled. - -
- -
- <filename>ccache.bbclass</filename> - - - 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 for information on - the C/C++ Compiler Cache. - -
- -
- <filename>chrpath.bbclass</filename> - - - 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. - -
- -
- <filename>clutter.bbclass</filename> - - - The clutter class consolidates the - major and minor version naming and other common items used by Clutter - and related recipes. - - 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. - - -
- -
- <filename>cmake.bbclass</filename> - - - The cmake class allows for recipes that need to - build software using the - CMake build system. - You can use the - 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 - do_install. - -
- -
- <filename>cml1.bbclass</filename> - - - The cml1 class provides basic support for the - Linux kernel style build configuration system. - -
- -
- <filename>compress_doc.bbclass</filename> - - - 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 - DOC_COMPRESS - variable. - -
- -
- <filename>copyleft_compliance.bbclass</filename> - - - 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 - archiver - class. - -
- -
- <filename>copyleft_filter.bbclass</filename> - - - A class used by the - archiver - and - copyleft_compliance - classes for filtering licenses. - The copyleft_filter class is an internal class - and is not intended to be used directly. - -
- -
- <filename>core-image.bbclass</filename> - - - The core-image class - provides common definitions for the - core-image-* image recipes, such as support for - additional - IMAGE_FEATURES. - -
- -
- <filename>cpan*.bbclass</filename> - - - 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. - -
- -
- <filename>cross.bbclass</filename> - - - The cross class provides support for the recipes - that build the cross-compilation tools. - -
- -
- <filename>cross-canadian.bbclass</filename> - - - The cross-canadian class - provides support for the recipes that build the Canadian - Cross-compilation tools for SDKs. - See the - "Cross-Development Toolchain Generation" - section in the Yocto Project Overview and Concepts Manual for more - discussion on these cross-compilation tools. - -
- -
- <filename>crosssdk.bbclass</filename> - - - The crosssdk class - provides support for the recipes that build the cross-compilation - tools used for building SDKs. - See the - "Cross-Development Toolchain Generation" - section in the Yocto Project Overview and Concepts Manual for more - discussion on these cross-compilation tools. - -
- -
- <filename>debian.bbclass</filename> - - - 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 - LEAD_SONAME - variable in the recipe to specify the library on which to apply the - naming scheme. - -
- -
- <filename>deploy.bbclass</filename> - - - The deploy class handles deploying files - to the - 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 - do_deploy - function to copy the files to be deployed to - DEPLOYDIR, - and use addtask to add the task at the appropriate - place, which is usually after - do_compile - or - do_install. - The class then takes care of staging the files from - DEPLOYDIR to - DEPLOY_DIR_IMAGE. - -
- -
- <filename>devshell.bbclass</filename> - - - The devshell class adds the - do_devshell task. - Distribution policy dictates whether to include this class. - See the - "Using a Development Shell" section - in the Yocto Project Development Tasks Manual for more information about - using devshell. - -
- -
- <filename>devupstream.bbclass</filename> - - - The devupstream class uses - 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 - 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). - -
- -
- <filename>distro_features_check.bbclass</filename> - - - The distro_features_check class - allows individual recipes to check for required and conflicting - DISTRO_FEATURES. - - - - This class provides support for the - REQUIRED_DISTRO_FEATURES - and - CONFLICT_DISTRO_FEATURES - variables. - If any conditions specified in the recipe using the above variables are - not met, the recipe will be skipped. - -
- -
- <filename>distutils*.bbclass</filename> - - - 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 - setuptools - class in their recipes. - - - The distutils-common-base class is required by - some of the distutils* classes to provide common - Python2 support. - -
- -
- <filename>distutils3*.bbclass</filename> - - - 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 - 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). - -
- -
- <filename>externalsrc.bbclass</filename> - - - 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 - S and - B variables to - locate unpacked recipe source code and to build it, respectively. - When your recipe inherits the externalsrc class, - you use the - EXTERNALSRC - and - EXTERNALSRC_BUILD - variables to ultimately define S and - B. - - - - By default, this class expects the source code to support recipe builds - that use the 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: - WORKDIR, - BPN, and - PV, - - - - For more information on the - externalsrc class, see the comments in - meta/classes/externalsrc.bbclass in the - Source Directory. - For information on how to use the externalsrc - class, see the - "Building Software from an External Source" - section in the Yocto Project Development Tasks Manual. - -
- -
- <filename>extrausers.bbclass</filename> - - - 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 - EXTRA_USERS_PARAMS - variable. - - 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; \ - " - - -
- -
- <filename>fontcache.bbclass</filename> - - - 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 - FONT_PACKAGES - to specify the packages containing the fonts. - -
- -
- <filename>fs-uuid.bbclass</filename> - - - The fs-uuid class extracts UUID from - ${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. - -
- -
- <filename>gconf.bbclass</filename> - - - The gconf class provides common - functionality for recipes that need to install GConf schemas. - The schemas will be put into a separate package - (${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. - -
- -
- <filename>gettext.bbclass</filename> - - - 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. - -
- -
- <filename>gnomebase.bbclass</filename> - - - The gnomebase class is the base - class for recipes that build software from the GNOME stack. - This class sets - SRC_URI to - download the source from the GNOME mirrors as well as extending - FILES - with the typical GNOME installation paths. - -
- -
- <filename>gobject-introspection.bbclass</filename> - - - Provides support for recipes building software that - supports GObject introspection. - This functionality is only enabled if the - "gobject-introspection-data" feature is in - DISTRO_FEATURES - as well as "qemu-usermode" being in - MACHINE_FEATURES. - - This functionality is backfilled by default and, - if not applicable, should be disabled through - DISTRO_FEATURES_BACKFILL_CONSIDERED - or - MACHINE_FEATURES_BACKFILL_CONSIDERED, - respectively. - - -
- -
- <filename>grub-efi.bbclass</filename> - - - The grub-efi - class provides grub-efi-specific functions for - building bootable images. - - - - This class supports several variables: - - - INITRD: - Indicates list of filesystem images to concatenate and use - as an initial RAM disk (initrd) (optional). - - - ROOTFS: - Indicates a filesystem image to include as the root filesystem - (optional). - - GRUB_GFXSERIAL: - Set this to "1" to have graphics and serial in the boot menu. - - - LABELS: - A list of targets for the automatic configuration. - - - APPEND: - An override list of append strings for each - LABEL. - - - GRUB_OPTS: - Additional options to add to the configuration (optional). - Options are delimited using semi-colon characters - (;). - - GRUB_TIMEOUT: - Timeout before executing the default LABEL - (optional). - - - -
- -
- <filename>gsettings.bbclass</filename> - - - 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. - -
- -
- <filename>gtk-doc.bbclass</filename> - - - The gtk-doc class - is a helper class to pull in the appropriate - gtk-doc dependencies and disable - gtk-doc. - -
- -
- <filename>gtk-icon-cache.bbclass</filename> - - - 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. - -
- -
- <filename>gtk-immodules-cache.bbclass</filename> - - - 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 - GTKIMMODULES_PACKAGES - to specify the packages containing the modules. - -
- -
- <filename>gzipnative.bbclass</filename> - - - 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. - -
- -
- <filename>icecc.bbclass</filename> - - - 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 ICECC_PATH - is not set in your local.conf file, then the - class tries to locate the icecc binary - using which. - - If - 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. - - 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 - ICECC_USER_PACKAGE_BL - and - 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 - ICECC_USER_PACKAGE_WL - variable in your local.conf file to force - icecc to be enabled for recipes using an empty - PARALLEL_MAKE - variable. - - - - Inheriting the icecc class changes all sstate - signatures. - Consequently, if a development team has a dedicated build system - that populates - STATE_MIRRORS - and they want to reuse sstate from - STATE_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 - 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 = "" - - -
- -
- <filename>image.bbclass</filename> - - - 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 - "Customizing Images" - section in the Yocto Project Development Tasks Manual. - For information on how images are created, see the - "Images" - section in the Yocto Project Overview and Concpets Manual. - -
- -
- <filename>image-buildinfo.bbclass</filename> - - - The image-buildinfo class writes information - to the target filesystem on /etc/build. - -
- -
- <filename>image_types.bbclass</filename> - - - The image_types class defines all of the - standard image output types that you can enable through the - IMAGE_FSTYPES - variable. - You can use this class as a reference on how to add support for - custom image output types. - - - - By default, the - 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. - - 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. - - -
- -
- <filename>image-live.bbclass</filename> - - - 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 - EFI_PROVIDER - if - MACHINE_FEATURES - contains "efi". - - - - Normally, you do not use this class directly. - Instead, you add "live" to - IMAGE_FSTYPES. - -
- -
- <filename>image-mklibs.bbclass</filename> - - - The image-mklibs class - enables the use of the mklibs utility during the - do_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 - USER_CLASSES - variable as follows: - - USER_CLASSES ?= "buildstats image-mklibs image-prelink" - - -
- - - -
- <filename>insane.bbclass</filename> - - - 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 - "QA Error and Warning Messages" - Chapter for a list of all the warning and error messages - you might encounter using a default configuration. - - - - Use the - WARN_QA and - 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 - 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 - DEPENDS, - explicit - 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 - do_rootfs - task because the auto-detected dependency was not satisfied. - An example of this would be where the - 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 - do_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 - RDEPENDS, - RRECOMMENDS, - RSUGGESTS, - RPROVIDES, - RREPLACES, - and - 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 - RDEPENDS - exist to handle any file-level dependency detected in - packaged files. - - files-invalid: - Checks for - 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 - do_install - task. - - incompatible-license: - Report when packages are excluded from being created due to - being marked with a license that is in - INCOMPATIBLE_LICENSE. - - install-host-path: - Checks the - do_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 - 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 - DESCRIPTION, - SUMMARY, - LICENSE, - and - 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 - 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 - 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 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 - TMPDIR/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 - 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 - do_package. - - pkgvarcheck: - Checks through the variables - RDEPENDS, - RRECOMMENDS, - RSUGGESTS, - RCONFLICTS, - RPROVIDES, - RREPLACES, - FILES, - 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 - (PN) value - that appears in - 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 - MACHINE - or - 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 - 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 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 - 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. - WORKDIR, - DEPLOY_DIR, - D, - PN, and - PKGD) are - undefined during - do_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. - - 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. - - - -
- -
- <filename>insserv.bbclass</filename> - - - 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. - -
- -
- <filename>kernel.bbclass</filename> - - - 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 - 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 - "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 - kernel-arch, - module-base, - and - linux-kernel-base - classes. - -
- -
- <filename>kernel-arch.bbclass</filename> - - - The kernel-arch class - sets the ARCH environment variable for Linux - kernel compilation (including modules). - -
- -
- <filename>kernel-devicetree.bbclass</filename> - - - The kernel-devicetree class, which is inherited by - the - kernel - class, supports device tree generation. - -
- -
- <filename>kernel-fitimage.bbclass</filename> - - - 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 - KERNEL_CLASSES - is set to "kernel-fitimage" and - 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 - 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 - UBOOT_LOADADDRESS - and the entrypoint by - 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 - UBOOT_DTBO_LOADADDRESS - for device tree overlays and by - 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 - UBOOT_RD_LOADADDRESS - and the entrypoint by - UBOOT_RD_ENTRYPOINT. - The ramdisk is added to FIT image when - INITRAMFS_IMAGE - is specified. - - - - The FIT image generated by kernel-fitimage class - is signed when the variables - UBOOT_SIGN_ENABLE, - UBOOT_MKIMAGE_DTCOPTS, - UBOOT_SIGN_KEYDIR - and - UBOOT_SIGN_KEYNAME - are set appropriately. - The default values used for - FIT_HASH_ALG - and - FIT_SIGN_ALG - in kernel-fitimage are "sha256" and "rsa2048" - respectively. - - -
- -
- <filename>kernel-grub.bbclass</filename> - - - 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. - -
- -
- <filename>kernel-module-split.bbclass</filename> - - - The kernel-module-split class - provides common functionality for splitting Linux kernel modules into - separate packages. - -
- -
- <filename>kernel-uboot.bbclass</filename> - - - The kernel-uboot class provides support for - building from vmlinux-style kernel sources. - -
- -
- <filename>kernel-uimage.bbclass</filename> - - - The kernel-uimage class provides support to - pack uImage. - -
- -
- <filename>kernel-yocto.bbclass</filename> - - - The kernel-yocto class - provides common functionality for building from linux-yocto style - kernel source repositories. - -
- -
- <filename>kernelsrc.bbclass</filename> - - - The kernelsrc class sets the Linux kernel - source and version. - -
- -
- <filename>lib_package.bbclass</filename> - - - 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 - ${PN}-bin - package to make their installation optional. - -
- -
- <filename>libc*.bbclass</filename> - - - 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. - - - -
- -
- <filename>license.bbclass</filename> - - - The license class provides license - manifest creation and license exclusion. - This class is enabled by default using the default value for the - INHERIT_DISTRO - variable. - -
- -
- <filename>linux-kernel-base.bbclass</filename> - - - 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. - -
- -
- <filename>linuxloader.bbclass</filename> - - - 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. - -
- -
- <filename>logging.bbclass</filename> - - - 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. - -
- -
- <filename>meta.bbclass</filename> - - - 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. - -
- -
- <filename>metadata_scm.bbclass</filename> - - - The metadata_scm class provides functionality for - querying the branch and revision of a Source Code Manager (SCM) - repository. - - - - The 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. - -
- -
- <filename>migrate_localcount.bbclass</filename> - - - The migrate_localcount class verifies a recipe's - localcount data and increments it appropriately. - -
- -
- <filename>mime.bbclass</filename> - - - 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. - -
- -
- <filename>mirrors.bbclass</filename> - - - The mirrors class sets up some standard - MIRRORS entries - for source code mirrors. - These mirrors provide a fall-back path in case the upstream source - specified in - SRC_URI - within recipes is unavailable. - - - - This class is enabled by default since it is inherited by the - base class. - -
- -
- <filename>module.bbclass</filename> - - - The module class provides support for building - out-of-tree Linux kernel modules. - The class inherits the - module-base - and - kernel-module-split - classes, and implements the - do_compile - and - do_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 - "Incorporating Out-of-Tree Modules" - section in the Yocto Project Linux Kernel Development Manual. - -
- -
- <filename>module-base.bbclass</filename> - - - 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 - module - class. - -
- -
- <filename>multilib*.bbclass</filename> - - - 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 - "Combining Multiple Versions of Library Files into One Image" - section in the Yocto Project Development Tasks Manual. - -
- -
- <filename>native.bbclass</filename> - - - The native class provides common - functionality for recipes that build tools to run on the - 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. - Warning - 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. - -
- -
- <filename>nativesdk.bbclass</filename> - - - 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 - 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. - - Warning - 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. - -
- -
- <filename>nopackages.bbclass</filename> - - - Disables packaging tasks for those recipes and classes where - packaging is not needed. - -
- -
- <filename>npm.bbclass</filename> - - - Provides support for building Node.js software fetched using the - node package manager (NPM). - - 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 - "Creating Node Package Manager (NPM) Packages" - section in the Yocto Project Development Tasks Manual. - -
- -
- <filename>oelint.bbclass</filename> - - - The oelint class is an - obsolete lint checking tool that exists in - meta/classes in the - 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. - -
- -
- <filename>own-mirrors.bbclass</filename> - - - The own-mirrors class makes it - easier to set up your own - PREMIRRORS - from which to first fetch source before attempting to fetch it from the - upstream specified in - SRC_URI - within each recipe. - - - - To use this class, inherit it globally and specify - 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. - -
- -
- <filename>package.bbclass</filename> - - - 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: - package_deb, - package_rpm, - package_ipk, - and - package_tar. - Warning - 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 - 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 - "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 - 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: - - - https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html - - https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html - - -
- -
- <filename>package_deb.bbclass</filename> - - - 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 - ${DEPLOY_DIR_DEB} - directory. - - - - This class inherits the - package - class and is enabled through the - PACKAGE_CLASSES - variable in the local.conf file. - -
- -
- <filename>package_ipk.bbclass</filename> - - - 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 - ${DEPLOY_DIR_IPK} - directory. - - - - This class inherits the - package - class and is enabled through the - PACKAGE_CLASSES - variable in the local.conf file. - -
- -
- <filename>package_rpm.bbclass</filename> - - - 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 - ${DEPLOY_DIR_RPM} - directory. - - - - This class inherits the - package - class and is enabled through the - PACKAGE_CLASSES - variable in the local.conf file. - -
- -
- <filename>package_tar.bbclass</filename> - - - The package_tar class - provides support for creating tarballs. - The class ensures the packages are written out in a - tarball format to the - ${DEPLOY_DIR_TAR} - directory. - - - - This class inherits the - package - class and is enabled through the - PACKAGE_CLASSES - variable in the local.conf file. - - 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. - - -
- -
- <filename>packagedata.bbclass</filename> - - - The packagedata class provides - common functionality for reading pkgdata files - found in - 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 - package - class. - -
- -
- <filename>packagegroup.bbclass</filename> - - - 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 - "Customizing Images Using Custom Package Groups" - section in the Yocto Project Development Tasks Manual. - - - - Previously, this class was called the task class. - -
- -
- <filename>patch.bbclass</filename> - - - The patch class provides all functionality for - applying patches during the - do_patch - task. - - - - This class is enabled by default because it is inherited by the - base - class. - -
- -
- <filename>perlnative.bbclass</filename> - - - 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. - -
- -
- <filename>pixbufcache.bbclass</filename> - - - 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 - PIXBUF_PACKAGES - to specify the packages containing the loaders. - -
- -
- <filename>pkgconfig.bbclass</filename> - - - 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. - -
- -
- <filename>populate_sdk.bbclass</filename> - - - The populate_sdk class provides support for - SDK-only recipes. - For information on advantages gained when building a cross-development - toolchain using the - do_populate_sdk - task, see the - "Building an SDK Installer" - section in the Yocto Project Application Development and the - Extensible Software Development Kit (eSDK) manual. - -
- -
- <filename>populate_sdk_*.bbclass</filename> - - - 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 - 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: - ${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 - 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 - "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 - do_populate_sdk - task, see the - "Building an SDK Installer" - section in the Yocto Project Application Development and the - Extensible Software Development Kit (eSDK) manual. - -
- -
- <filename>prexport.bbclass</filename> - - - The prexport class provides functionality for - exporting - PR values. - - This class is not intended to be used directly. - Rather, it is enabled when using - "bitbake-prserv-tool export". - - -
- -
- <filename>primport.bbclass</filename> - - - The primport class provides functionality for - importing - PR values. - - This class is not intended to be used directly. - Rather, it is enabled when using - "bitbake-prserv-tool import". - - -
- -
- <filename>prserv.bbclass</filename> - - - The prserv class provides functionality for - using a - PR service - in order to automatically manage the incrementing of the - PR variable for - each recipe. - - - - This class is enabled by default because it is inherited by the - package - class. - However, the OpenEmbedded build system will not enable the - functionality of this class unless - PRSERV_HOST - has been set. - -
- -
- <filename>ptest.bbclass</filename> - - - 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 - DISTRO_FEATURES. - See the - "Testing Packages With ptest" - section in the Yocto Project Development Tasks Manual for more - information on ptest. - -
- -
- <filename>ptest-gnome.bbclass</filename> - - - 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 - "Testing Packages With ptest" - section in the Yocto Project Development Tasks Manual. - -
- -
- <filename>python-dir.bbclass</filename> - - - The python-dir class provides the base version, - location, and site package location for Python. - -
- -
- <filename>python3native.bbclass</filename> - - - 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. - -
- -
- <filename>pythonnative.bbclass</filename> - - - 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. - -
- -
- <filename>qemu.bbclass</filename> - - - 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. - -
- -
- <filename>recipe_sanity.bbclass</filename> - - - 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). - -
- -
- <filename>relocatable.bbclass</filename> - - - The relocatable class enables relocation of - binaries when they are installed into the sysroot. - - - - This class makes use of the - chrpath - class and is used by both the - cross - and - native - classes. - -
- -
- <filename>remove-libtool.bbclass</filename> - - - The remove-libtool class adds a post function - to the - do_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" - - - The remove-libtool class is not enabled by - default. - - -
- -
- <filename>report-error.bbclass</filename> - - - The report-error class supports enabling the - 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 - ${LOG_DIR}/error-report. - -
- -
- <filename>rm_work.bbclass</filename> - - - 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 - 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" - - -
- -
- <filename>rootfs*.bbclass</filename> - - - 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 - PACKAGE_CLASSES - variable. - - - - For information on how root filesystem images are created, see the - "Image Generation" - section in the Yocto Project Overview and Concepts Manual. - -
- -
- <filename>sanity.bbclass</filename> - - - 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. - -
- -
- <filename>scons.bbclass</filename> - - - The scons class supports recipes that need to - build software that uses the SCons build system. - You can use the - EXTRA_OESCONS - variable to specify additional configuration options you want to pass - SCons command line. - -
- -
- <filename>sdl.bbclass</filename> - - - The sdl class supports recipes that need to build - software that uses the Simple DirectMedia Layer (SDL) library. - -
- -
- <filename>setuptools.bbclass</filename> - - - 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. - -
- -
- <filename>setuptools3.bbclass</filename> - - - 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. - -
- -
- <filename>sign_rpm.bbclass</filename> - - - The sign_rpm class supports generating signed - RPM packages. - -
- -
- <filename>sip.bbclass</filename> - - - The sip class - supports recipes that build or package SIP-based Python bindings. - -
- -
- <filename>siteconfig.bbclass</filename> - - - The siteconfig class - provides functionality for handling site configuration. - The class is used by the - autotools - class to accelerate the - do_configure - task. - -
- -
- <filename>siteinfo.bbclass</filename> - - - 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. - -
- -
- <filename>spdx.bbclass</filename> - - - The spdx class integrates real-time license - scanning, generation of SPDX standard output, and verification - of license information during the build. - - This class is currently at the prototype stage in the 1.6 - release. - - -
- -
- <filename>sstate.bbclass</filename> - - - The sstate class provides support for Shared - State (sstate). - By default, the class is enabled through the - INHERIT_DISTRO - variable's default value. - - - - For more information on sstate, see the - "Shared State Cache" - section in the Yocto Project Overview and Concepts Manual. - -
- -
- <filename>staging.bbclass</filename> - - - The staging class installs files into individual - recipe work directories for sysroots. - The class contains the following key tasks: - - - The - do_populate_sysroot - task, which is responsible for handing the files that end up - in the recipe sysroots. - - - The - do_prepare_recipe_sysroot - task (a "partner" task to the - populate_sysroot task), which installs - the files into the individual recipe work directories (i.e. - 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 - do_install - task into - ${D}. - The do_populate_sysroot task copies - a subset of these files into - ${SYSROOT_DESTDIR}. - This subset of files is controlled by the - SYSROOT_DIRS, - SYSROOT_DIRS_NATIVE, - and - SYSROOT_DIRS_BLACKLIST - variables. - - 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 - 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 - 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 - DEPENDS - variable. - The recipe will have a - do_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. - WORKDIR). - The OpenEmbedded build system creates hard links to copies of the - relevant files from sysroots-components - into the recipe work directory. - - 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. - - 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 - 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. - - - -
- -
- <filename>syslinux.bbclass</filename> - - - The syslinux class provides syslinux-specific - functions for building bootable images. - - - - The class supports the following variables: - - INITRD: - Indicates list of filesystem images to concatenate and use as - an initial RAM disk (initrd). - This variable is optional. - ROOTFS: - Indicates a filesystem image to include as the root filesystem. - This variable is optional. - AUTO_SYSLINUXMENU: - Enables creating an automatic menu when set to "1". - - LABELS: - Lists targets for automatic configuration. - - APPEND: - Lists append string overrides for each label. - - SYSLINUX_OPTS: - Lists additional options to add to the syslinux file. - Semicolon characters separate multiple options. - - SYSLINUX_SPLASH: - Lists a background for the VGA boot menu when you are using the - boot menu. - SYSLINUX_DEFAULT_CONSOLE: - Set to "console=ttyX" to change kernel boot default console. - - SYSLINUX_SERIAL: - Sets an alternate serial port. - Or, turns off serial when the variable is set with an - empty string. - SYSLINUX_SERIAL_TTY: - Sets an alternate "console=tty..." kernel boot argument. - - - -
- -
- <filename>systemd.bbclass</filename> - - - The systemd class provides support for recipes - that install systemd unit files. - - - - The functionality for this class is disabled unless you have "systemd" - in - DISTRO_FEATURES. - - - - Under this class, the recipe or Makefile (i.e. whatever the recipe is - calling during the - do_install - task) installs unit files into - ${D}${systemd_unitdir}/system. - If the unit files being installed go into packages other than the - main package, you need to set - SYSTEMD_PACKAGES - in your recipe to identify the packages in which the files will be - installed. - - - - You should set - 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 - ${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 - SYSTEMD_AUTO_ENABLE - to "disable". - - - - For more information on systemd, see the - "Selecting an Initialization Manager" - section in the Yocto Project Development Tasks Manual. - -
- -
- <filename>systemd-boot.bbclass</filename> - - - 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. - - The systemd-boot class is a result from - merging the gummiboot class used in previous - Yocto Project releases with the systemd - project. - - Set the - 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 - SYSTEMD_BOOT_CFG, - SYSTEMD_BOOT_ENTRIES, - and - SYSTEMD_BOOT_TIMEOUT - variables. - - - - You can also see the - Systemd-boot documentation - for more information. - -
- -
- <filename>terminal.bbclass</filename> - - - The terminal class provides support for starting - a terminal session. - The - 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 - patch - class assuming - PATCHRESOLVE - is set to "user", the - cml1 - class, and the - devshell - class all use the terminal class. - -
- -
- <filename>testimage*.bbclass</filename> - - - 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. - Tip - Best practices include using - IMAGE_CLASSES - rather than - 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. - TESTIMAGE_AUTO - must be set to "1"). - - - - For information on how to enable, run, and create new tests, see the - "Performing Automated Runtime Testing" - section in the Yocto Project Development Tasks Manual. - -
- -
- <filename>testsdk.bbclass</filename> - - - 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 - - Tip - Best practices include using - IMAGE_CLASSES - rather than - INHERIT to - inherit the testsdk class for automated - SDK testing. - - -
- -
- <filename>texinfo.bbclass</filename> - - - 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. - - If you want to use the Texinfo recipe shipped with the build - system, you can remove "texinfo-native" from - ASSUME_PROVIDED - and makeinfo from - SANITY_REQUIRED_UTILITIES. - - -
- -
- <filename>tinderclient.bbclass</filename> - - - The tinderclient class submits build results to - an external Tinderbox instance. - - This class is currently unmaintained. - - -
- -
- <filename>toaster.bbclass</filename> - - - 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. - -
- -
- <filename>toolchain-scripts.bbclass</filename> - - - The toolchain-scripts class provides the scripts - used for setting up the environment for installed SDKs. - -
- -
- <filename>typecheck.bbclass</filename> - - - 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" - - -
- -
- <filename>uboot-config.bbclass</filename> - - - The uboot-config class provides support for - U-Boot configuration for a machine. - Specify the machine in your recipe as follows: - - UBOOT_CONFIG ??= <default> - UBOOT_CONFIG[foo] = "config,images" - - You can also specify the machine using this method: - - UBOOT_MACHINE = "config" - - See the - UBOOT_CONFIG - and - UBOOT_MACHINE - variables for additional information. - -
- -
- <filename>uninative.bbclass</filename> - - - 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. - -
- -
- <filename>update-alternatives.bbclass</filename> - - - 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: - - ALTERNATIVE - - ALTERNATIVE_LINK_NAME - - ALTERNATIVE_TARGET - - 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 - update-alternatives.bbclass - file. - - - - You can use the update-alternatives command - directly in your recipes. - However, this class simplifies things in most cases. - -
- -
- <filename>update-rc.d.bbclass</filename> - - - 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. - -
- -
- <filename>useradd*.bbclass</filename> - - - 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 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 - USERADD_PACKAGES, - USERADD_PARAM, - GROUPADD_PARAM, - and - 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 - 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 - USERADDEXTENSION, - USERADD_UID_TABLES, - USERADD_GID_TABLES, - and - USERADD_ERROR_DYNAMIC - variables. - You can also see the - useradd - class for additional information. - - - Notes - 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, - TMPDIR - might contain incorrect uid and - gid values. - Deleting the TMPDIR directory - will correct this condition. - -
- -
- <filename>utility-tasks.bbclass</filename> - - - The utility-tasks class provides support for - various "utility" type tasks that are applicable to all recipes, - such as - do_clean and - do_listtasks. - - - - This class is enabled by default because it is inherited by - the - base - class. - -
- -
- <filename>utils.bbclass</filename> - - - 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 - base - class. - -
- -
- <filename>vala.bbclass</filename> - - - The vala class supports recipes that need to - build software written using the Vala programming language. - -
- -
- <filename>waf.bbclass</filename> - - - The waf class supports recipes that need to build - software that uses the Waf build system. - You can use the - EXTRA_OECONF - or - PACKAGECONFIG_CONFARGS - variables to specify additional configuration options to be passed on - the Waf command line. - -
- - - - - - -- cgit v1.2.3-54-g00ecf