From 4ba824759e43d5e1665080e1c4e0202350a33149 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 5 Dec 2013 13:35:21 -0600 Subject: ref-manual: Edits to icecc class and re-order of "I" classes. (From yocto-docs rev: 48640c823cf06ab818efd8f9d15c43353d31f87c) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/ref-classes.xml | 2602 +++++++++++++++--------------- 1 file changed, 1311 insertions(+), 1291 deletions(-) (limited to 'documentation') diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml index da47d51fd6..f36c80d6f3 100644 --- a/documentation/ref-manual/ref-classes.xml +++ b/documentation/ref-manual/ref-classes.xml @@ -824,9 +824,8 @@ <filename>icecc.bbclass</filename> - The Icecream distributed compile support (icecc) - class stages directories with symlinks from - gcc and g++ to + The icecc 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 @@ -892,26 +891,69 @@ -
- <filename>image-live.bbclass</filename> +
+ Creating Images - <filename>image.bbclass</filename> and <filename>rootfs*.bbclass</filename> - The live image (image-live) class - supports building "live" images. - Normally, you do not use this class directly. - Instead, you add "live" to - IMAGE_FSTYPES. + These classes add support for creating images in several formats. + First, the root filesystem is created from packages using + one of the rootfs_*.bbclass + files (depending on the package format used) and then the image is created. + + The + IMAGE_FSTYPES + variable controls the types of images to generate. + + The + IMAGE_INSTALL + variable controls the list of packages to install into the + image. +
-
- <filename>image-vmdk.bbclass</filename> +
+ <filename>image_types.bbclass</filename> - The Virtual Machine Disk image (image-vmdk) class - supports building VMware VMDK images. + The image types (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 U-Boot image types (image_types_uboot) class + defines additional image types specifically for the U-Boot bootloader. + +
+ +
+ <filename>image-live.bbclass</filename> + + + The live image (image-live) class + supports building "live" images. Normally, you do not use this class directly. - Instead, you add "vmdk" to + Instead, you add "live" to IMAGE_FSTYPES.
@@ -979,1502 +1021,1480 @@
-
- <filename>image_types.bbclass</filename> - - - The image types (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 U-Boot image types (image_types_uboot) class - defines additional image types specifically for the U-Boot bootloader. - -
- -
- <filename>insserve.bbclass</filename> - - - The insserve (insserve) 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-arch.bbclass</filename> - - - The kernel architecture (kernel-arch) class - sets the ARCH environment variable for Linux - kernel compilation (including modules). - -
- -
- <filename>kernel-module-split.bbclass</filename> - - - The kernel module split (kernel-module-split) class - provides common functionality for splitting Linux kernel modules into - separate packages. - -
- -
- <filename>kernel-yocto.bbclass</filename> - - - The Yocto Project kernel (kernel-yocto) class - provides common functionality for building from linux-yocto style - kernel source repositories. - -
- -
- <filename>lib_package.bbclass</filename> - - - The library package (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>linux-kernel-base.bbclass</filename> - - - The Linux kernel base (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>license.bbclass</filename> - - - The license (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>logging.bbclass</filename> - - - The logging (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. - +
+ <filename>image-vmdk.bbclass</filename> - This class is enabled by default since it is inherited by - the base class. + The Virtual Machine Disk image (image-vmdk) class + supports building VMware VMDK images. + Normally, you do not use this class directly. + Instead, you add "vmdk" to + IMAGE_FSTYPES.
-
- <filename>meta.bbclass</filename> +
+<filename>insane.bbclass</filename> - The Metadata (meta) class is inherited by recipes - that do not build any output packages themselves, but act as a "meta" - target for building other recipes. + This 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. -
- -
- <filename>metadata_scm.bbclass</filename> - The Metadata Source Code Management (SCM) System - (metadata_scm) class provides functionality for - querying the branch and revision of an SCM repository. + 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. - 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. + 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. -
- -
- <filename>mime.bbclass</filename> - The Multipurpose Internet Mail Extension (MIME) - (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 (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>multilib*.bbclass</filename> - - - The Multilib (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 (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: + The following list shows the tests you can list with the + WARN_QA and ERROR_QA + variables: - Create a myrecipe-native.bb - that inherits the native class. + 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. + 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. + 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. + 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. - 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 native SDK (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-native.bb - that inherits the nativesdk class. + 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. + 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 don't match the type since there would be an + incompatibility. + Sometimes software, like bootloaders, might need to bypass this check. - 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 OpenEmbedded link (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>ownmirrors.bbclass</filename> - - - The own mirrors (ownmirrors) 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. - -
- -
- Pkg-config - <filename>pkgconfig.bbclass</filename> - - - pkg-config 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>packagedata.bbclass</filename> - - - The package data (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>packageinfo.bbclass</filename> - - - The package information (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 input method modules 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 modules being installed are in packages other - than the main package, set - PIXBUF_PACKAGES - to include the packages containing the modules. - -
- -
- <filename>populate_sdk.bbclass</filename> - - - The populate_sdk class facilitates compatibility - with SDK-only recipes. - -
- -
- <filename>populate_sdk_*.bbclass</filename> - - - The populate_sdk_* family of classes support - SDK creation. - This family of classes consists of the following: - - 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. + 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. + 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. + 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. + textrel: + Checks for ELF binaries that contain relocations in their + .text sections, which can result in a + performance impact at runtime. + 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. - populate_sdk_rpm: - Supports creation of the SDK given the RPM package manager. + 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. - populate_sdk_ipk: - Supports creation of the SDK given the IPK package manager. + 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. - - - - - 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. - -
- -
- <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 use this variable - 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> - - - The pythonnative causes the OpenEmbedded build - system to use the native version of Python, which is built by the - build system. - Normally, the OpenEmbedded build system uses the version of Python - that is built by the build host. - - This class must be inherited by a recipe in order to be used. - + staticdev: + Checks for static library files (*.a) in + non-staticdev packages. + + 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. + desktop: + Runs the desktop-file-validate program + against any .desktop files to validate + their contents against the specification for + .desktop files. + 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. + + split-strip: + Reports that splitting or stripping debug symbols from binaries + has failed. + + arch: + Checks to ensure the architecture, bit size, and endianness + of all output binaries matches that of the target. + This test can detect when the wrong compiler or compiler options + have been used. + + 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. + + 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. + + 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. + + 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. + + 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. + + 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". + + 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. + + 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 -). + + 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". + + 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. + + + var-undefined: + Reports when variables fundamental to packaging (i.e. + WORKDIR, + DEPLOY_DIR, + D, + PN, and + PKGD) are + undefined during do_package. + + pkgv-undefined: + Checks to see if the PKGV variable + is undefined during do_package. + + 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. + + perms: + Currently, this check is unused but reserved. + + 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. + + +
-
- <filename>qemu.bbclass</filename> +
+ <filename>insserve.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. + The insserve (insserve) 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>qmake*.bbclass</filename> +
+ <filename>kernel-arch.bbclass</filename> - This family of classes consists 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. - + The kernel architecture (kernel-arch) class + sets the ARCH environment variable for Linux + kernel compilation (including modules). +
+ +
+ <filename>kernel-module-split.bbclass</filename> - The qmake* family of classes support recipes that - need to build software that uses Qt's qmake - build system. + The kernel module split (kernel-module-split) class + provides common functionality for splitting Linux kernel modules into + separate packages. +
+ +
+ <filename>kernel-yocto.bbclass</filename> - 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. + The Yocto Project kernel (kernel-yocto) class + provides common functionality for building from linux-yocto style + kernel source repositories. +
+ +
+ <filename>lib_package.bbclass</filename> - 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. + The library package (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>qt4*.bbclass</filename> +
+ <filename>linux-kernel-base.bbclass</filename> - This family of classes consists of the following: - - qt4e: - Supports building against Qt/Embedded, which uses the - framebuffer for graphical output. - qt4x11: - Supports building against Qt/X11. - + The Linux kernel base (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>license.bbclass</filename> - These classes support recipes that need to build software that uses - the Qt development framework version 4.x. - The classes inherit the - qmake2 - class. + The license (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>relocatable.bbclass</filename> +
+ <filename>logging.bbclass</filename> - The relocatable class enables relocation of - binaries when they are installed into the sysroot. + The logging (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 makes use of the - chrpath - class and is used by both the - cross - and - native - classes. + This class is enabled by default since it is inherited by + the base class.
-
- <filename>scons.bbclass</filename> +
+ <filename>meta.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. + The Metadata (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>sdl.bbclass</filename> +
+ <filename>metadata_scm.bbclass</filename> - The sdl class supports recipes that need to build - software that uses the Simple DirectMedia Layer (SDL) library. + The Metadata Source Code Management (SCM) System + (metadata_scm) class provides functionality for + querying the branch and revision of an SCM repository. -
- -
- <filename>setuptools.bbclass</filename> - The setuptools class supports extensions that use - setuptools-based build systems. - If your recipe uses these build systems, the recipe needs to - inherit the setuptools class. + 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.
-
- Package Groups - <filename>packagegroup.bbclass</filename> +
+ <filename>mime.bbclass</filename> - This 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. + The Multipurpose Internet Mail Extension (MIME) + (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> + - For information on how to use this class, see the - "Customizing Images Using Custom Package Groups" - section in the Yocto Project Development Manual. + The mirrors (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. + - Previously, this class was named task.bbclass. + This class is enabled by default since it is inherited by the + base class.
-
- <filename>package.bbclass</filename> +
+ <filename>multilib*.bbclass</filename> - The packaging class (package) supports generating - packages from a build's output. - The core generic functionality is in the - package.bbclass. - The code specific to particular package types resides in these - package-specific classes: - package_deb, - package_rpm, - package_ipk, - and - package_tar. + The Multilib (multilib*) classes provide support + for building libraries with different target optimizations or target + architectures and installing them side-by-side in the same image. - 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. + 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. +
- - 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. - +
+ <filename>native.bbclass</filename> - 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. + The native (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). - Before making your package manager decision, however, you should - consider some further things about using RPM: + You can create a recipe that builds tools that run natively on the + host a couple different ways: - - 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 Berkley - Database and the amount of metadata when using RPM can affect - your ability to perform on-device upgrades. + Create a myrecipe-native.bb + that inherits the native class. + 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. - 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 - - + 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>package_deb.bbclass</filename> +
+ <filename>nativesdk.bbclass</filename> - The Debian package manager (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 package inherits the - package - class. - + The native SDK (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). -
-
- <filename>package_rpm.bbclass</filename> + + You can create a recipe that builds tools that run on the SDK machine + a couple different ways: + + Create a myrecipe-native.bb + that inherits the nativesdk class. + + 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. + + - The RPM package manager (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 package inherits the - package - class. - + 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>package_ipk.bbclass</filename> +
+ <filename>oelint.bbclass</filename> - The Itsy package manager (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 package inherits the - package - class. - + The OpenEmbedded link (oelint) class is an + obsolete lint checking tool that exists in + meta/classes in the + Source Directory. -
- -
- <filename>sip.bbclass</filename> - The sip class - supports recipes that build or package SIP-based Python bindings. + 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>siteconfig.bbclass</filename> +
+ <filename>ownmirrors.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. + The own mirrors (ownmirrors) 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. -
- -
- <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. - + 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>sstate.bbclass</filename> +
+ Pkg-config - <filename>pkgconfig.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. + pkg-config provides a standard way to get + header and library information. + This class aims to smooth integration of + pkg-config into libraries that use it. - For more information on sstate, see the - "Shared State Cache" - section. + 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>staging.bbclass</filename> +
+ <filename>packagedata.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 + The package data (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>syslinux.bbclass</filename> +
+ <filename>packageinfo.bbclass</filename> - The syslinux class provides syslinux-specific - functions for building bootable images. + The package information (packageinfo) class + gives a BitBake user interface the ability to retrieve information + about output packages from the pkgdata files. - 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. - - + This class is enabled automatically when using the + Hob + user interface.
-
- <filename>systemd.bbclass</filename> +
+ <filename>patch.bbclass</filename> - The systemd class provides support for recipes - that install systemd unit files. + The patch class provides all functionality for + applying patches during the do_patch task. - The functionality for this class is disabled unless you have "systemd" - in - DISTRO_FEATURES. + This class is enabled by default because it is inherited by the + base + class. +
+ +
+ <filename>perlnative.bbclass</filename> - Under this class, unit files are installed into - ${D}${systemd_unitdir}/system - during the do_install task. - 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. + 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> - 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: + 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 input method modules 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 modules being installed are in packages other + than the main package, set + PIXBUF_PACKAGES + to include the packages containing the modules. + +
+ +
+ <filename>populate_sdk.bbclass</filename> + + + The populate_sdk class facilitates compatibility + with SDK-only recipes. + +
+ +
+ <filename>populate_sdk_*.bbclass</filename> + + + The populate_sdk_* family of classes support + SDK creation. + This family of classes consists of the following: + + 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: - SYSTEMD_SERVICE_${PN} = "connman.service" + ${SDK_OUTPUT}/<sdk_arch-nativesdk pkgs> + ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/<target pkgs> - 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. + 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.
-
- <filename>package_tar.bbclass</filename> +
+ <filename>prexport.bbclass</filename> - The consolidated Unix archive file (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. + The prexport class provides functionality for + exporting + PR values. - This package inherits the - package - class. + This class is not intended to be used directly. + Rather, it is enabled when using + "bitbake-prserv-tool export".
-
- Building Kernels - <filename>kernel.bbclass</filename> +
+ <filename>primport.bbclass</filename> - This class handles building Linux kernels. - The class contains code to build all kernel trees. - All needed headers are staged into the - STAGING_KERNEL_DIR - directory to allow out-of-tree module builds using module.bbclass. + 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> - 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 prserv class provides functionality for + using a + PR service + in order to automatically manage the incrementing of the + PR variable for + each recipe. - Various other classes are used by the kernel and module classes internally including - kernel-arch.bbclass, module_strip.bbclass, - module-base.bbclass, and linux-kernel-base.bbclass. + This class is enabled by default because it is inherited by the + package + class. + However, the OpenEmbedded build system will not use this variable + unless + PRSERV_HOST + has been set.
-
- Creating Images - <filename>image.bbclass</filename> and <filename>rootfs*.bbclass</filename> +
+ <filename>ptest.bbclass</filename> - These classes add support for creating images in several formats. - First, the root filesystem is created from packages using - one of the rootfs_*.bbclass - files (depending on the package format used) and then the image is created. - - The - IMAGE_FSTYPES - variable controls the types of images to generate. - - The - IMAGE_INSTALL - variable controls the list of packages to install into the - image. - + 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.
-
- Host System Sanity Checks - <filename>sanity.bbclass</filename> +
+ <filename>python-dir.bbclass</filename> - This 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. + The python-dir class provides the base version, + location, and site package location for Python.
-
-<filename>insane.bbclass</filename> +
+ <filename>pythonnative.bbclass</filename> - This class adds a step to the package generation process so that - output quality assurance checks are generated by the OpenEmbedded + The pythonnative causes the OpenEmbedded build + system to use the native version of Python, which is built by the 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. + Normally, the OpenEmbedded build system uses the version of Python + that is built by the build host. + + This class must be inherited by a recipe in order to be used. + +
- - 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. - +
+ <filename>qemu.bbclass</filename> - 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 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 following list shows the tests you can list with the - WARN_QA and ERROR_QA - variables: + This family of classes consists of the following: - 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. - 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. - 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. - 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. + qmake_base: + Provides base functionality for all versions of + qmake. + qmake2: + Extends base functionality for qmake 2.x as + used by Qt 4.x. + + + + + The qmake* family of classes support recipes that + need to build software that uses Qt's qmake + build system. + + + + 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> + + + This family of classes consists of the following: + + qt4e: + Supports building against Qt/Embedded, which uses the + framebuffer for graphical output. + qt4x11: + Supports building against Qt/X11. + + + + + These classes support recipes that need to build software that uses + the Qt development framework version 4.x. + 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>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 extensions that use + setuptools-based build systems. + If your recipe uses these build systems, the recipe needs to + inherit the setuptools class. + +
+ +
+ Package Groups - <filename>packagegroup.bbclass</filename> + + + This 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 named task.bbclass. + +
+ +
+ <filename>package.bbclass</filename> + + + The packaging class (package) supports generating + packages from a build's output. + The core generic functionality is in the + 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. - 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. - 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 don't match the type since there would be an - incompatibility. - Sometimes software, like bootloaders, might need to bypass this check. + + For smaller systems, the extra space used for the Berkley + Database and the amount of metadata when using RPM can affect + your ability to perform on-device upgrades. - 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. - 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. - 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. - textrel: - Checks for ELF binaries that contain relocations in their - .text sections, which can result in a - performance impact at runtime. - 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. - - 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. - - 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. - - staticdev: - Checks for static library files (*.a) in - non-staticdev packages. - - 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. - desktop: - Runs the desktop-file-validate program - against any .desktop files to validate - their contents against the specification for - .desktop files. - 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. - - split-strip: - Reports that splitting or stripping debug symbols from binaries - has failed. - - arch: - Checks to ensure the architecture, bit size, and endianness - of all output binaries matches that of the target. - This test can detect when the wrong compiler or compiler options - have been used. - - 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. - - 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. - - 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. - - 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. - - 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. - - 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". - - 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. - - 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 -). - - 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". - - 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. - + + + + + 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 Debian package manager (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 package inherits the + package + class. + + +
+ +
+ <filename>package_rpm.bbclass</filename> + + + The RPM package manager (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 package inherits the + package + class. + + +
+ +
+ <filename>package_ipk.bbclass</filename> + + + The Itsy package manager (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 package inherits the + package + 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>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". - 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. - + LABELS: + Lists targets for automatic configuration. - var-undefined: - Reports when variables fundamental to packaging (i.e. - WORKDIR, - DEPLOY_DIR, - D, - PN, and - PKGD) are - undefined during do_package. + APPEND: + Lists append string overrides for each label. - pkgv-undefined: - Checks to see if the PKGV variable - is undefined during do_package. + SYSLINUX_OPTS: + Lists additional options to add to the syslinux file. + Semicolon characters separate multiple options. - 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. + 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. - perms: - Currently, this check is unused but reserved. + 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. - 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. - + + +
+ +
+ <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, unit files are installed into + ${D}${systemd_unitdir}/system + during the do_install task. + 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>package_tar.bbclass</filename> + + + The consolidated Unix archive file (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 package inherits the + package + class. + + +
+ +
+ Building Kernels - <filename>kernel.bbclass</filename> + + + This class handles building Linux kernels. + The class contains code to build all kernel trees. + All needed headers are staged into the + STAGING_KERNEL_DIR + directory to allow out-of-tree module builds using module.bbclass. + + + + This means that each built kernel module is packaged separately and inter-module + dependencies are created by parsing the modinfo output. + If all modules are required, then installing the kernel-modules + package installs all packages with modules and various other kernel packages + such as kernel-vmlinux. + + + + Various other classes are used by the kernel and module classes internally including + kernel-arch.bbclass, module_strip.bbclass, + module-base.bbclass, and linux-kernel-base.bbclass. + +
+ +
+ Creating Images - <filename>image.bbclass</filename> and <filename>rootfs*.bbclass</filename> + + + These classes add support for creating images in several formats. + First, the root filesystem is created from packages using + one of the rootfs_*.bbclass + files (depending on the package format used) and then the image is created. + + The + IMAGE_FSTYPES + variable controls the types of images to generate. + The + IMAGE_INSTALL + variable controls the list of packages to install into the + image.
+
+ Host System Sanity Checks - <filename>sanity.bbclass</filename> + + + This 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. + +
+
Removing Work Files During the Build - <filename>rm_work.bbclass</filename> -- cgit v1.2.3-54-g00ecf