From c527fd1f14c27855a37f2e8ac5346ce8d940ced2 Mon Sep 17 00:00:00 2001 From: Tudor Florea Date: Thu, 16 Oct 2014 03:05:19 +0200 Subject: initial commit for Enea Linux 4.0-140929 Migrated from the internal git server on the daisy-enea-point-release branch Signed-off-by: Tudor Florea --- documentation/ref-manual/ref-classes.xml | 3255 ++++++++++++++++++++++++++++++ 1 file changed, 3255 insertions(+) create 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 new file mode 100644 index 0000000000..da546080a3 --- /dev/null +++ b/documentation/ref-manual/ref-classes.xml @@ -0,0 +1,3255 @@ + %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). + + + + 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 Manual. + +
+ +
+ <filename>autotools.bbclass</filename> + + + The autotools class supports Autotooled + packages. + + + + The autoconf, automake, + and libtool bring standardization. + This class defines a set of tasks (configure, compile etc.) that + work for all Autotooled packages. + It should usually be enough to define a few standard variables + and then simply inherit autotools. + This class can also work with software that emulates Autotools. + For more information, see the + "Autotooled Package" + section in the Yocto Project Development Manual. + + + + It's useful to have some idea of how the tasks defined by this class work + and what they do behind the scenes. + + do_configure ‐ Regenerates the + configure script (using autoreconf) and then launches it + with a standard set of arguments used during cross-compilation. + You can pass additional parameters to configure through the + EXTRA_OECONF variable. + + do_compile ‐ Runs make with + arguments that specify the compiler and linker. + You can pass additional arguments through + the EXTRA_OEMAKE variable. + + do_install ‐ Runs make install + and passes in + ${D} + as DESTDIR. + + + + + + It is planned for future Yocto Project releases that by default, the + autotools class supports out-of-tree builds + (B != + S). + If your recipes do not support out-of-tree builds, you should + have them inherit the + autotools-brokensep + class. + +
+ +
+ <filename>autotools-brokensep.bbclass</filename> + + + 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. + + +
+ +
+ <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. + +
+ +
+ <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. + + For RPMs and other packages that do not contain a subdirectory, + you should specify a "subdir" parameter. + 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 = "http://example.com/downloads/somepackage.rpm;subdir=${BP}" + + + +
+ +
+ <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>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>boot-directdisk.bbclass</filename> + + + The boot-directdisk class + creates an image that can be placed directly onto a hard disk using + dd and then booted. + The image uses SYSLINUX. + + + + The end result is a 512 boot sector populated with a + Master Boot Record (MBR) and partition table followed by an MSDOS + FAT16 partition containing SYSLINUX and a Linux kernel completed by + the ext2 and ext3 + root filesystems. + +
+ +
+ <filename>bootimg.bbclass</filename> + + + The bootimg class creates a bootable + image using SYSLINUX, your kernel, and an optional initial RAM disk + (initrd). + + + + When you use this class, two things happen: + + + A .hddimg file is created. + This file is an MSDOS filesystem that contains SYSLINUX, + a kernel, an initrd, and a root filesystem + image. + All three of these can be written to hard drives directly and + also booted on a USB flash disks using dd. + + + A CD .iso image is created. + When this file is booted, the initrd + boots and processes the label selected in SYSLINUX. + Actions based on the label are then performed (e.g. installing + to a hard drive). + + + + + The bootimg class supports the + INITRD, + NOISO, + NOHDD, and + ROOTFS + variables. + +
+ +
+ <filename>bugzilla.bbclass</filename> + + + The bugzilla class supports setting up an + instance of Bugzilla in which you can automatically files bug reports + in response to build failures. + For this class to work, you need to enable the XML-RPC interface in + the instance of Bugzilla. + +
+ +
+ <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. + +
+ +
+ <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>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 on + the cmake command line. + +
+ +
+ <filename>cml1.bbclass</filename> + + + The cml1 class provides basic support for the + Linux kernel style build configuration system. + +
+ +
+ <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>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 class supports 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. + + + +
+ +
+ <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 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 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. eglibc + becomes libc6 and eglibc-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 + devshell task. + Distribution policy dictates whether to include this class. + See the + "Using a Development Shell" section + in the Yocto Project Development Manual for more information about + using devshell. + +
+ +
+ <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>distrodata.bbclass</filename> + + + The distrodata class + provides for automatic checking for upstream recipe updates. + The class creates a comma-separated value (CSV) spreadsheet that + contains information about the recipes. + The information provides the distrodata and + distro_check tasks, which do upstream checking + and also verify if a package is used in multiple major distributions. + + + + The class is not included by default. + To use it, you must include the following files and set the + INHERIT + variable: + + include conf/distro/include/distro_alias.inc + include conf/distro/include/recipe_color.inc + include conf/distro/include/maintainers.inc + include conf/distro/include/upstream_tracking.inc + include conf/distro/include/package_regex.inc + INHERIT+= "distrodata" + + +
+ +
+ <filename>distutils.bbclass</filename> + + + The distutils class supports 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 + distutils-based classes 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. + + + +
+ +
+ <filename>distutils3.bbclass</filename> + + + The distutils3 class supports 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 two 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. + + + +
+ +
+ <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 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; \ + " + + +
+ +
+ <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>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>gnome.bbclass</filename> + + + The gnome class supports recipes that + build software from the GNOME stack. + This class inherits the + gnomebase, + gtk-icon-cache, + gconf and + mime classes. + The class also disables GObject introspection where applicable. + +
+ +
+ <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>grub-efi.bbclass</filename> + + + The grub-efi + class provides grub-efi-specific functions for + building bootable images. + + + + This class supports several variables: + + + INITRD: + Indicates a filesystem image to use as an 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 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 += "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 Manual. + For information on how images are created, see the + "Images" section elsewhere + in this manual. + +
+ +
+ <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, this class is enabled through the + IMAGE_CLASSES + variable in + image.bbclass. + If you define your own image types using a custom BitBake class and + then use IMAGE_CLASSES to enable it, the custom + class must either inherit image_types or + image_types must also appear in + IMAGE_CLASSES. + +
+ +
+ <filename>image_types_uboot.bbclass</filename> + + + The image_types_uboot class + defines additional image types specifically for the U-Boot bootloader. + +
+ +
+ <filename>image-live.bbclass</filename> + + + The image-live class supports building "live" + images. + + + + Normally, you do not use this class directly. + Instead, you add "live" to + IMAGE_FSTYPES. + For example, if you were building an ISO image, you would add "live" + to IMAGE_FSTYPES, set the + NOISO variable to + "0" and the build system would use the image-live + class to build the ISO image. + +
+ +
+ <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>image-swab.bbclass</filename> + + + The image-swab class enables the + Swabber + tool in order to detect and log accesses to the host system during + the OpenEmbedded build process. + + This class is currently unmaintained. + + +
+ +
+ <filename>image-vmdk.bbclass</filename> + + + The image-vmdk class supports building VMware + VMDK images. + Normally, you do not use this class directly. + Instead, you add "vmdk" to + IMAGE_FSTYPES. + +
+ +
+ <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. + + + + 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. + + 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 -dbg packages only depend on other + -dbg packages and not on any other types of 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 -dev packages only depend on other + -dev packages and not on any other types of 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. + + files-invalid: + Checks for + FILES + variable values that contain "//", which is invalid. + + 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. + + 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. + unsafe-references-in-binaries: + Reports when a binary installed in + ${base_libdir}, + ${base_bindir}, or + ${base_sbindir}, depends on another + binary installed under ${exec_prefix}. + This dependency is a concern if you want the system to remain + basically operable if /usr is mounted + separately and is not mounted. + + Defaults for binaries installed in + ${base_libdir}, + ${base_bindir}, and + ${base_sbindir} are + /lib, /bin, and + /sbin, respectively. + The default for a binary installed + under ${exec_prefix} is + /usr. + + + unsafe-references-in-scripts: + Reports when a script file installed in + ${base_libdir}, + ${base_bindir}, or + ${base_sbindir}, depends on files + installed under ${exec_prefix}. + This dependency is a concern if you want the system to remain + basically operable if /usr is mounted + separately and is not mounted. + + Defaults for binaries installed in + ${base_libdir}, + ${base_bindir}, and + ${base_sbindir} are + /lib, /bin, and + /sbin, respectively. + The default for a binary installed + under ${exec_prefix} is + /usr. + + + 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. + + + + 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-module-split.bbclass</filename> + + + The kernel-module-split class + provides common functionality for splitting Linux kernel modules into + separate packages. + +
+ +
+ <filename>kernel-yocto.bbclass</filename> + + + The kernel-yocto class + provides common functionality for building from linux-yocto style + kernel source repositories. + +
+ +
+ <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>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>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>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 do_compile and + do_install functions. + 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 Manual. + +
+ +
+ <filename>native.bbclass</filename> + + + The native class provides common + functionality for recipes that wish to 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 + 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. + + Create or modify a target recipe that has adds + 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 myrecipe-nativesdk.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. + + + + + 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>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 are 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. + + + + 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 Smart, 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 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 + .deb file format. + The class ensures the packages are written out to the + ${DEPLOY_DIR}/deb + directory in a .deb file format. + + + + 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 file format. + The class ensures the packages are written out to the + ${DEPLOY_DIR}/ipk + directory in a .ipk file format. + + + + 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_deb class + provides support for creating packages that use the + .rpm file format. + The class ensures the packages are written out to the + ${DEPLOY_DIR}/rpm + directory in a .rpm file format. + + + + 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 packages that use the + .tar file format. + The class ensures the packages are written out to the + ${DEPLOY_DIR}/tar + directory in a .tar file format. + + + + 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 Manual. + + + + Previously, this class was called the task class. + +
+ +
+ <filename>packageinfo.bbclass</filename> + + + The packageinfo class + gives a BitBake user interface the ability to retrieve information + about output packages from the pkgdata files. + + + + This class is enabled automatically when using the + Hob + user interface. + +
+ +
+ <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 pkg-config class provides a standard way to get + header and library information. + 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, + this 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 + "Optionally Building a Toolchain Installer" + section in the Yocto Project Application Developer's Guide. + +
+ +
+ <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 IPK). + 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 IPK package manager. + + + + + + The populate_sdk_base package 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 images: + 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. + For information on advantages gained when building a + cross-development toolchain using the + do_populate_sdk task, see the + "Optionally Building a Toolchain Installer" + section in the Yocto Project Application Developer's Guide. + +
+ +
+ <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 Manual for more information + on ptest. + +
+ +
+ <filename>python-dir.bbclass</filename> + + + The python-dir class provides the base version, + location, and site package location for Python. + +
+ +
+ <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>qmake*.bbclass</filename> + + + The qmake* classes support recipes that + need to build software that uses Qt's qmake + build system and are comprised of the following: + + qmake_base: + Provides base functionality for all versions of + qmake. + qmake2: + Extends base functionality for qmake 2.x as + used by Qt 4.x. + + + + + If you need to set any configuration variables or pass any options to + qmake, you can add these to the + EXTRA_QMAKEVARS_PRE + or + EXTRA_QMAKEVARS_POST + variables, depending on whether the arguments need to be before or + after the .pro file list on the command line, + respectively. + + + + By default, all .pro files are built. + If you want to specify your own subset of .pro + files to be built, specify them in the + QMAKE_PROFILES + variable. + +
+ +
+ <filename>qt4*.bbclass</filename> + + + The qt4* classes support recipes that need to + build software that uses the Qt development framework version 4.x + and consist of the following: + + qt4e: + Supports building against Qt/Embedded, which uses the + framebuffer for graphical output. + qt4x11: + Supports building against Qt/X11. + + + + + The classes inherit the + qmake2 + class. + +
+ +
+ <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>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 eglibc" + + +
+ +
+ <filename>rootfs*.bbclass</filename> + + + The rootfs* classes support creating + the root filesystem for an image and consist of the following classes: + + + 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 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. + +
+ +
+ <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>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. + + + + Because the + base class + includes the siteinfo class, it is always active. + +
+ +
+ <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.5 + 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. + +
+ +
+ <filename>staging.bbclass</filename> + + + The staging class provides support for staging + files into the sysroot during the + do_populate_sysroot task. + The class is enabled by default because it is inherited by the + base + class. + +
+ +
+ <filename>syslinux.bbclass</filename> + + + The syslinux class provides syslinux-specific + functions for building bootable images. + + + + The class supports the following variables: + + INITRD: + Indicates a filesystem image to 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 Manual. + +
+ +
+ <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 class supports running automated + tests against images using QEMU and on actual hardware. + The class handles loading the tests and starting the image. + + + + To use the class, you need to perform steps to set up the + environment. + The tests are commands that run on the target system over + ssh. + they are written in Python and make use of the + unittest module. + + + + For information on how to enable, run, and create new tests, see the + "Performing Automated Runtime Testing" + section. + +
+ +
+ <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>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. + + + + 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 class supports 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 this class 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 this class. + + + + The useradd class supports the + USERADD_PACKAGES, + USERADD_PARAM, + GROUPADD_PARAM, + and + GROUPMEMS_PARAM + variables. + +
+ +
+ <filename>useradd-staticids.bbclass</filename> + + + 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 this 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 base_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 + variable to specify additional configuration options to be passed on + the Waf command line. + +
+ + + + + + -- cgit v1.2.3-54-g00ecf