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-variables.xml | 8419 ++++++++++++++++++++++++++++ 1 file changed, 8419 insertions(+) create mode 100644 documentation/ref-manual/ref-variables.xml (limited to 'documentation/ref-manual/ref-variables.xml') diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml new file mode 100644 index 0000000000..4ff1a21323 --- /dev/null +++ b/documentation/ref-manual/ref-variables.xml @@ -0,0 +1,8419 @@ + %poky; ] > + + + + +Variables Glossary + + + This chapter lists common variables used in the OpenEmbedded build system and gives an overview + of their function and contents. + + + + + + + A + B + C + D + E + F + G + H + I + + K + L + M + + O + P + Q + R + S + T + U + + W + + + + + + A + + ALLOW_EMPTY + + + Specifies if an output package should still be produced if it is empty. + By default, BitBake does not produce empty packages. + This default behavior can cause issues when there is an + RDEPENDS or + some other hard runtime requirement on the existence of the package. + + + + Like all package-controlling variables, you must always use them in + conjunction with a package name override, as in: + + ALLOW_EMPTY_${PN} = "1" + ALLOW_EMPTY_${PN}-dev = "1" + ALLOW_EMPTY_${PN}-staticdev = "1" + + + + + + ALTERNATIVE + + + Lists commands in a package that need an alternative + binary naming scheme. + Sometimes the same command is provided in multiple packages. + When this occurs, the OpenEmbedded build system needs to + use the alternatives system to create a different binary + naming scheme so the commands can co-exist. + + + + To use the variable, list out the package's commands + that also exist as part of another package. + For example, if the busybox package + has four commands that also exist as part of another + package, you identify them as follows: + + ALTERNATIVE_busybox = "sh sed test bracket" + + For more information on the alternatives system, see the + "update-alternatives.bbclass" + section. + + + + + ALTERNATIVE_LINK_NAME + + + Used by the alternatives system to map duplicated commands + to actual locations. + For example, if the bracket command + provided by the busybox package is + duplicated through another package, you must use the + ALTERNATIVE_LINK_NAME variable to + specify the actual location: + + ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/[" + + In this example, the binary for the + bracket command (i.e. + [) from the + busybox package resides in + /usr/bin/. + + If ALTERNATIVE_LINK_NAME is not + defined, it defaults to + ${bindir}/<name>. + + + + + For more information on the alternatives system, see the + "update-alternatives.bbclass" + section. + + + + + ALTERNATIVE_PRIORITY + + + Used by the alternatives system to create default + priorities for duplicated commands. + You can use the variable to create a single default + regardless of the command name or package, a default for + specific duplicated commands regardless of the package, or + a default for specific commands tied to particular packages. + Here are the available syntax forms: + + ALTERNATIVE_PRIORITY = "<priority>" + ALTERNATIVE_PRIORITY[<name>] = "<priority>" + ALTERNATIVE_PRIORITY_<pkg>[<name>] = "<priority>" + + + + + For more information on the alternatives system, see the + "update-alternatives.bbclass" + section. + + + + + ALTERNATIVE_TARGET + + + Used by the alternatives system to create default link + locations for duplicated commands. + You can use the variable to create a single default + location for all duplicated commands regardless of the + command name or package, a default for + specific duplicated commands regardless of the package, or + a default for specific commands tied to particular packages. + Here are the available syntax forms: + + ALTERNATIVE_TARGET = "<target>" + ALTERNATIVE_TARGET[<name>] = "<target>" + ALTERNATIVE_TARGET_<pkg>[<name>] = "<target>" + + + + If ALTERNATIVE_TARGET is not + defined, it inherits the value from the + ALTERNATIVE_LINK_NAME + variable. + + + + If ALTERNATIVE_LINK_NAME and + ALTERNATIVE_TARGET are the + same, the target for + ALTERNATIVE_TARGET + has ".{BPN}" appended to it. + + + + Finally, if the file referenced has not been + renamed, the alternatives system will rename it to + avoid the need to rename alternative files in the + do_install task while + retaining support for the command if necessary. + + + + + + For more information on the alternatives system, see the + "update-alternatives.bbclass" + section. + + + + + APPEND + + + An override list of append strings for each + LABEL. + + + + See the + grub-efi + class for more information on how this variable is used. + + + + + AUTHOR + + The email address used to contact the original author + or authors in order to send patches and forward bugs. + + + + AUTO_SYSLINUXMENU + + + Enables creating an automatic menu. + You must set this in your recipe. + The + syslinux + class checks this variable. + + + + + AUTOREV + + When SRCREV + is set to the value of this variable, it specifies to use the latest + source revision in the repository. + Here is an example: + + SRCREV = "${AUTOREV}" + + + + + + + + B + + B + + + The directory within the + Build Directory + in which the OpenEmbedded build system places generated + objects during a recipe's build process. + By default, this directory is the same as the S + directory, which is defined as: + + S = "${WORKDIR}/${BP}/" + + You can separate the (S) directory + and the directory pointed to by the B + variable. + Most Autotools-based recipes support separating these + directories. + The build system defaults to using separate directories for + gcc and some kernel recipes. + + + + + BAD_RECOMMENDATIONS + + + Lists "recommended-only" packages to not install. + Recommended-only packages are packages installed only + through the + RRECOMMENDS + variable. + You can prevent any of these "recommended" packages from + being installed by listing them with the + BAD_RECOMMENDATIONS variable: + + BAD_RECOMMENDATIONS = "<package_name> <package_name> <package_name> ..." + + You can set this variable globally in your + local.conf file or you can attach it to + a specific image recipe by using the recipe name override: + + BAD_RECOMMENDATIONS_pn-<target_image> = "<package_name>" + + + + + It is important to realize that if you choose to not install + packages using this variable and some other packages are + dependent on them (i.e. listed in a recipe's + RDEPENDS + variable), the OpenEmbedded build system ignores your + request and will install the packages to avoid dependency + errors. + + + + Support for this variable exists only when using the + IPK and RPM packaging backend. + Support does not exist for DEB. + + + + See the + NO_RECOMMENDATIONS + and the + PACKAGE_EXCLUDE + variables for related information. + + + + + BB_DANGLINGAPPENDS_WARNONLY + + + Defines how BitBake handles situations where an append + file (.bbappend) has no + corresponding recipe file (.bb). + This condition often occurs when layers get out of sync + (e.g. oe-core bumps a + recipe version and the old recipe no longer exists and the + other layer has not been updated to the new version + of the recipe yet). + + + + The default fatal behavior is safest because it is + the sane reaction given something is out of sync. + It is important to realize when your changes are no longer + being applied. + + + + You can change the default behavior by setting this + variable to "1", "yes", or "true" + in your local.conf file, which is + located in the + Build Directory: + Here is an example: + + BB_DANGLINGAPPENDS_WARNONLY = "1" + + + + + + BB_DISKMON_DIRS + + + Monitors disk space and available inodes during the build + and allows you to control the build based on these + parameters. + + + + Disk space monitoring is disabled by default. + To enable monitoring, add the BB_DISKMON_DIRS + variable to your conf/local.conf file found in the + Build Directory. + Use the following form: + + BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]" + + where: + + <action> is: + ABORT: Immediately abort the build when + a threshold is broken. + STOPTASKS: Stop the build after the currently + executing tasks have finished when + a threshold is broken. + WARN: Issue a warning but continue the + build when a threshold is broken. + Subsequent warnings are issued as + defined by the + BB_DISKMON_WARNINTERVAL variable, + which must be defined in the + conf/local.conf file. + + <dir> is: + Any directory you choose. You can specify one or + more directories to monitor by separating the + groupings with a space. If two directories are + on the same device, only the first directory + is monitored. + + <threshold> is: + Either the minimum available disk space, + the minimum number of free inodes, or + both. You must specify at least one. To + omit one or the other, simply omit the value. + Specify the threshold using G, M, K for Gbytes, + Mbytes, and Kbytes, respectively. If you do + not specify G, M, or K, Kbytes is assumed by + default. Do not use GB, MB, or KB. + + + + + Here are some examples: + + BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" + BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G" + BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K" + + The first example works only if you also provide + the BB_DISKMON_WARNINTERVAL variable + in the conf/local.conf. + This example causes the build system to immediately + abort when either the disk space in ${TMPDIR} drops + below 1 Gbyte or the available free inodes drops below + 100 Kbytes. + Because two directories are provided with the variable, the + build system also issue a + warning when the disk space in the + ${SSTATE_DIR} directory drops + below 1 Gbyte or the number of free inodes drops + below 100 Kbytes. + Subsequent warnings are issued during intervals as + defined by the BB_DISKMON_WARNINTERVAL + variable. + + + + The second example stops the build after all currently + executing tasks complete when the minimum disk space + in the ${TMPDIR} + directory drops below 1 Gbyte. + No disk monitoring occurs for the free inodes in this case. + + + + The final example immediately aborts the build when the + number of free inodes in the ${TMPDIR} directory + drops below 100 Kbytes. + No disk space monitoring for the directory itself occurs + in this case. + + + + + BB_DISKMON_WARNINTERVAL + + + Defines the disk space and free inode warning intervals. + To set these intervals, define the variable in your + conf/local.conf file in the + Build Directory. + + + + If you are going to use the + BB_DISKMON_WARNINTERVAL variable, you must + also use the + BB_DISKMON_DIRS variable + and define its action as "WARN". + During the build, subsequent warnings are issued each time + disk space or number of free inodes further reduces by + the respective interval. + + + + If you do not provide a BB_DISKMON_WARNINTERVAL + variable and you do use BB_DISKMON_DIRS with + the "WARN" action, the disk monitoring interval defaults to + the following: + + BB_DISKMON_WARNINTERVAL = "50M,5K" + + + + + When specifying the variable in your configuration file, + use the following form: + + BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>" + + where: + + <disk_space_interval> is: + An interval of memory expressed in either + G, M, or K for Gbytes, Mbytes, or Kbytes, + respectively. You cannot use GB, MB, or KB. + + <disk_inode_interval> is: + An interval of free inodes expressed in either + G, M, or K for Gbytes, Mbytes, or Kbytes, + respectively. You cannot use GB, MB, or KB. + + + + + Here is an example: + + BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K" + BB_DISKMON_WARNINTERVAL = "50M,5K" + + These variables cause the OpenEmbedded build system to + issue subsequent warnings each time the available + disk space further reduces by 50 Mbytes or the number + of free inodes further reduces by 5 Kbytes in the + ${SSTATE_DIR} directory. + Subsequent warnings based on the interval occur each time + a respective interval is reached beyond the initial warning + (i.e. 1 Gbytes and 100 Kbytes). + + + + + BB_GENERATE_MIRROR_TARBALLS + + + Causes tarballs of the Git repositories, including the + Git metadata, to be placed in the + DL_DIR + directory. + + + + For performance reasons, creating and placing tarballs of + the Git repositories is not the default action by the + OpenEmbedded build system. + + BB_GENERATE_MIRROR_TARBALLS = "1" + + Set this variable in your local.conf + file in the + Build Directory. + + + + + BB_NUMBER_THREADS + + + The maximum number of tasks BitBake should run in parallel + at any one time. + If your host development system supports multiple cores, + a good rule of thumb is to set this variable to twice the + number of cores. + + + + The default value for BB_NUMBER_THREADS + is equal to the number of cores your build system has. + + + + + BBCLASSEXTEND + + + Allows you to extend a recipe so that it builds variants of the software. + Common variants for recipes exist such as "natives" like quilt-native, + which is a copy of Quilt built to run on the build system; + "crosses" such as gcc-cross, + which is a compiler built to run on the build machine but produces binaries + that run on the target MACHINE; + "nativesdk", which targets the SDK machine instead of MACHINE; + and "mulitlibs" in the form "multilib:<multilib_name>". + + + + To build a different variant of the recipe with a minimal amount of code, it usually + is as simple as adding the following to your recipe: + + BBCLASSEXTEND =+ "native nativesdk" + BBCLASSEXTEND =+ "multilib:<multilib_name>" + + + + + + BBFILE_COLLECTIONS + + Lists the names of configured layers. + These names are used to find the other BBFILE_* + variables. + Typically, each layer will append its name to this variable in its + conf/layer.conf file. + + + + + BBFILE_PATTERN + + Variable that expands to match files from + BBFILES + in a particular layer. + This variable is used in the conf/layer.conf file and must + be suffixed with the name of the specific layer (e.g. + BBFILE_PATTERN_emenlow). + + + + BBFILE_PRIORITY + + Assigns the priority for recipe files in each layer. + This variable is useful in situations where the same recipe appears in + more than one layer. + Setting this variable allows you to prioritize a + layer against other layers that contain the same recipe - effectively + letting you control the precedence for the multiple layers. + The precedence established through this variable stands regardless of a + recipe's version + (PV variable). + For example, a layer that has a recipe with a higher PV value but for + which the BBFILE_PRIORITY is set to have a lower precedence still has a + lower precedence. + A larger value for the BBFILE_PRIORITY variable results in a higher + precedence. + For example, the value 6 has a higher precedence than the value 5. + If not specified, the BBFILE_PRIORITY variable is set based on layer + dependencies (see the + LAYERDEPENDS variable for + more information. + The default priority, if unspecified + for a layer with no dependencies, is the lowest defined priority + 1 + (or 1 if no priorities are defined). + + You can use the command bitbake-layers show-layers to list + all configured layers along with their priorities. + + + + + BBFILES + + List of recipe files used by BitBake to build software. + + + + BBINCLUDELOGS + + Variable that controls how BitBake displays logs on build failure. + + + + BBLAYERS + + Lists the layers to enable during the build. + This variable is defined in the bblayers.conf configuration + file in the Build Directory. + Here is an example: + + BBLAYERS = " \ + /home/scottrif/poky/meta \ + /home/scottrif/poky/meta-yocto \ + /home/scottrif/poky/meta-yocto-bsp \ + /home/scottrif/poky/meta-mykernel \ + " + + BBLAYERS_NON_REMOVABLE ?= " \ + /home/scottrif/poky/meta \ + /home/scottrif/poky/meta-yocto \ + " + + This example enables four layers, one of which is a custom, user-defined layer + named meta-mykernel. + + + + + BBLAYERS_NON_REMOVABLE + + Lists core layers that cannot be removed from the + bblayers.conf file during a build + using the + Hob. + + When building an image outside of Hob, this variable + is ignored. + + In order for BitBake to build your image using Hob, your + bblayers.conf file must include the + meta and meta-yocto + core layers. + Here is an example that shows these two layers listed in + the BBLAYERS_NON_REMOVABLE statement: + + BBLAYERS = " \ + /home/scottrif/poky/meta \ + /home/scottrif/poky/meta-yocto \ + /home/scottrif/poky/meta-yocto-bsp \ + /home/scottrif/poky/meta-mykernel \ + " + + BBLAYERS_NON_REMOVABLE ?= " \ + /home/scottrif/poky/meta \ + /home/scottrif/poky/meta-yocto \ + " + + + + + + BBMASK + + + Prevents BitBake from processing recipes and recipe + append files. + Use the BBMASK variable from within the + conf/local.conf file found + in the + Build Directory. + + + + You can use the BBMASK variable + to "hide" these .bb and + .bbappend files. + BitBake ignores any recipe or recipe append files that + match the expression. + It is as if BitBake does not see them at all. + Consequently, matching files are not parsed or otherwise + used by BitBake. + + The value you provide is passed to Python's regular + expression compiler. + The expression is compared against the full paths to + the files. + For complete syntax information, see Python's + documentation at + . + + + + The following example uses a complete regular expression + to tell BitBake to ignore all recipe and recipe append + files in the meta-ti/recipes-misc/ + directory: + + BBMASK = "meta-ti/recipes-misc/" + + If you want to mask out multiple directories or recipes, + use the vertical bar to separate the regular expression + fragments. + This next example masks out multiple directories and + individual recipes: + + BBMASK = "meta-ti/recipes-misc/|meta-ti/recipes-ti/packagegroup/" + BBMASK .= "|.*meta-oe/recipes-support/" + BBMASK .= "|.*openldap" + BBMASK .= "|.*opencv" + BBMASK .= "|.*lzma" + + Notice how the vertical bar is used to append the fragments. + + When specifying a directory name, use the trailing + slash character to ensure you match just that directory + name. + + + + + + BBPATH + + + Used by BitBake to locate + .bbclass and configuration files. + This variable is analogous to the + PATH variable. + + If you run BitBake from a directory outside of the + Build Directory, + you must be sure to set + BBPATH to point to the + Build Directory. + Set the variable as you would any environment variable + and then run BitBake: + + $ BBPATH = "<build_directory>" + $ export BBPATH + $ bitbake <target> + + + + + + + BBSERVER + + + Points to the server that runs memory-resident BitBake. + This variable is set by the + oe-init-build-env-memres + setup script and should not be hand-edited. + The variable is only used when you employ memory-resident + BitBake. + The setup script exports the value as follows: + + export BBSERVER=localhost:$port + + For more information on how the + BBSERVER is used, see the + oe-init-build-env-memres script, which + is located in the + Source Directory. + + + + + BINCONFIG_GLOB + + + When inheriting binconfig.bbclass + from a recipe, this variable specifies a wildcard for + configuration scripts that need editing. + The scripts are edited to correct any paths that have been + set up during compilation so that they are correct for + use when installed into the sysroot and called by the + build processes of other recipes. + + + + For more information on how this variable works, see + meta/classes/binconfig.bbclass in the + Source Directory. + You can also find general information on the class in the + "binconfig.bbclass" + section. + + + + + BP + + The base recipe name and version but without any special + recipe name suffix (i.e. -native, lib64-, + and so forth). + BP is comprised of the following: + + ${BPN}-${PV} + + + + + BPN + + The bare name of the recipe. + This variable is a version of the PN variable + but removes common suffixes such as "-native" and "-cross" as well + as removes common prefixes such as multilib's "lib64-" and "lib32-". + The exact list of suffixes removed is specified by the + SPECIAL_PKGSUFFIX variable. + The exact list of prefixes removed is specified by the + MLPREFIX variable. + Prefixes are removed for multilib + and nativesdk cases. + + + + BUGTRACKER + + + Specifies a URL for an upstream bug tracking website for + a recipe. + The OpenEmbedded build system does not use this variable. + Rather, the variable is a useful pointer in case a bug + in the software being built needs to be manually reported. + + + + + BUILDDIR + + + Points to the location of the + Build Directory. + You can define this directory indirectly through the + &OE_INIT_FILE; + and + oe-init-build-env-memres + scripts by passing in a Build Directory path when you run + the scripts. + If you run the scripts and do not provide a Build Directory + path, the BUILDDIR defaults to + build in the current directory. + + + + + BUILDHISTORY_COMMIT + + + When inheriting the + buildhistory + class, specifies whether or not to commit the build + history output in a local Git repository. + If set to "1", this local repository will be maintained + automatically by the + buildhistory + class and a commit will be created on every + build for changes to each top-level subdirectory of the + build history output (images, packages, and sdk). + If you want to track changes to build history over + time, you should set this value to "1". + + + + By default, the buildhistory class + does not commit the build history output in a local + Git repository: + + BUILDHISTORY_COMMIT ?= "0" + + + + + + BUILDHISTORY_COMMIT_AUTHOR + + + When inheriting the + buildhistory + class, specifies the author to use for each Git commit. + In order for the BUILDHISTORY_COMMIT_AUTHOR + variable to work, the + BUILDHISTORY_COMMIT + variable must be set to "1". + + + + Git requires that the value you provide for the + BUILDHISTORY_COMMIT_AUTHOR variable + takes the form of "name <email@host>". + Providing an email address or host that is not valid does + not produce an error. + + + + By default, the buildhistory class + sets the variable as follows: + + BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>" + + + + + + BUILDHISTORY_DIR + + + When inheriting the + buildhistory + class, specifies the directory in which build history + information is kept. + For more information on how the variable works, see the + buildhistory.class. + + + + By default, the buildhistory class + sets the directory as follows: + + BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory" + + + + + + BUILDHISTORY_FEATURES + + + When inheriting the + buildhistory + class, specifies the build history features to be enabled. + For more information on how build history works, see the + "Maintaining Build Output Quality" + section. + + + + You can specify three features in the form of a + space-separated list: + + image: + Analysis of the contents of images, which + includes the list of installed packages among other + things. + + package: + Analysis of the contents of individual packages. + + sdk: + Analysis of the contents of the software + development kit (SDK). + + + + + + By default, the buildhistory class + enables all three features: + + BUILDHISTORY_FEATURES ?= "image package sdk" + + + + + + BUILDHISTORY_IMAGE_FILES + + + When inheriting the + buildhistory + class, specifies a list of paths to files copied from the + image contents into the build history directory under + an "image-files" directory in the directory for + the image, so that you can track the contents of each file. + The default is to copy /etc/passwd + and /etc/group, which allows you to + monitor for changes in user and group entries. + You can modify the list to include any file. + Specifying an invalid path does not produce an error. + Consequently, you can include files that might + not always be present. + + + + By default, the buildhistory class + provides paths to the following files: + + BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group" + + + + + + BUILDHISTORY_PUSH_REPO + + + When inheriting the + buildhistory + class, optionally specifies a remote repository + to which build history pushes Git changes. + In order for BUILDHISTORY_PUSH_REPO + to work, + BUILDHISTORY_COMMIT + must be set to "1". + + + + The repository should correspond to a remote + address that specifies a repository as understood by + Git, or alternatively to a remote name that you have + set up manually using git remote + within the local repository. + + + + By default, the buildhistory class + sets the variable as follows: + + BUILDHISTORY_PUSH_REPO ?= "" + + + + + + BUILDSTATS_BASE + + + Points to the location of the directory that holds build + statistics when you use and enable the + buildstats + class. + The BUILDSTATS_BASE directory defaults + to + ${TMPDIR}/buildstats/. + + + + + BUSYBOX_SPLIT_SUID + + + For the BusyBox recipe, specifies whether to split the + output executable file into two parts: one for features + that require setuid root, and one for + the remaining features (i.e. those that do not require + setuid root). + + + + The BUSYBOX_SPLIT_SUID variable + defaults to "1", which results in a single output + executable file. + Set the variable to "0" to split the output file. + + + + + + + C + + CFLAGS + + + Flags passed to the C compiler for the target system. + This variable evaluates to the same as + TARGET_CFLAGS. + + + + For information on flags that help with creating more + secure code, see the + "Making Images More Secure" + section in the Yocto Project Development Manual. + + + + + CLASSOVERRIDE + + + An internal variable specifying the special class override + that should currently apply (e.g. "class-target", + "class-native", and so forth). + The classes that use this variable set it to + appropriate values. + + + + You do not normally directly interact with this variable. + The value for the CLASSOVERRIDE + variable goes into + OVERRIDES + and then can be used as an override. + Here is an example where "python-native" is added to + DEPENDS + only when building for the native case: + + DEPENDS_append_class-native = " python-native" + + + + + + COMBINED_FEATURES + + + Provides a list of hardware features that are enabled in + both + MACHINE_FEATURES + and + DISTRO_FEATURES. + This select list of features contains features that make + sense to be controlled both at the machine and distribution + configuration level. + For example, the "bluetooth" feature requires hardware + support but should also be optional at the distribution + level, in case the hardware supports Bluetooth but you + do not ever intend to use it. + + + + For more information, see the + MACHINE_FEATURES + and DISTRO_FEATURES + variables. + + + + + COMMON_LICENSE_DIR + + + Points to meta/files/common-licenses + in the + Source Directory, + which is where generic license files reside. + + + + + COMPATIBLE_HOST + + A regular expression that resolves to one or more hosts + (when the recipe is native) or one or more targets (when + the recipe is non-native) with which a recipe is compatible. + The regular expression is matched against + HOST_SYS. + You can use the variable to stop recipes from being built + for classes of systems with which the recipes are not + compatible. + Stopping these builds is particularly useful with kernels. + The variable also helps to increase parsing speed + since the build system skips parsing recipes not + compatible with the current system. + + + + COMPATIBLE_MACHINE + + A regular expression that resolves to one or more + target machines with which a recipe is compatible. + The regular expression is matched against + MACHINEOVERRIDES. + You can use the variable to stop recipes from being built + for machines with which the recipes are not compatible. + Stopping these builds is particularly useful with kernels. + The variable also helps to increase parsing speed + since the build system skips parsing recipes not + compatible with the current machine. + + + + COMPLEMENTARY_GLOB + + + Defines wildcards to match when installing a list of + complementary packages for all the packages explicitly + (or implicitly) installed in an image. + The resulting list of complementary packages is associated + with an item that can be added to + IMAGE_FEATURES. + An example usage of this is the "dev-pkgs" item that when + added to IMAGE_FEATURES will + install -dev packages (containing headers and other + development files) for every package in the image. + + + + To add a new feature item pointing to a wildcard, use a + variable flag to specify the feature item name and + use the value to specify the wildcard. + Here is an example: + + COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev' + + + + + + CONFFILES + + + Identifies editable or configurable files that are part of a package. + If the Package Management System (PMS) is being used to update + packages on the target system, it is possible that + configuration files you have changed after the original installation + and that you now want to remain unchanged are overwritten. + In other words, editable files might exist in the package that you do not + want reset as part of the package update process. + You can use the CONFFILES variable to list the files in the + package that you wish to prevent the PMS from overwriting during this update process. + + + + To use the CONFFILES variable, provide a package name + override that identifies the resulting package. + Then, provide a space-separated list of files. + Here is an example: + + CONFFILES_${PN} += "${sysconfdir}/file1 \ + ${sysconfdir}/file2 ${sysconfdir}/file3" + + + + + A relationship exists between the CONFFILES and + FILES variables. + The files listed within CONFFILES must be a subset of + the files listed within FILES. + Because the configuration files you provide with CONFFILES + are simply being identified so that the PMS will not overwrite them, + it makes sense that + the files must already be included as part of the package through the + FILES variable. + + + + When specifying paths as part of the CONFFILES variable, + it is good practice to use appropriate path variables. + For example, ${sysconfdir} rather than + /etc or ${bindir} rather + than /usr/bin. + You can find a list of these variables at the top of the + meta/conf/bitbake.conf file in the + Source Directory. + + + + + CONFIG_INITRAMFS_SOURCE + + + Identifies the initial RAM disk (initramfs) source files. + The OpenEmbedded build system receives and uses + this kernel Kconfig variable as an environment variable. + By default, the variable is set to null (""). + + + + The CONFIG_INITRAMFS_SOURCE can be + either a single cpio archive with a + .cpio suffix or a + space-separated list of directories and files for building + the initramfs image. + A cpio archive should contain a filesystem archive + to be used as an initramfs image. + Directories should contain a filesystem layout to be + included in the initramfs image. + Files should contain entries according to the format + described by the + usr/gen_init_cpio program in the + kernel tree. + + + + If you specify multiple directories and files, the + initramfs image will be the aggregate of all of them. + + + + + CONFIG_SITE + + + A list of files that contains autoconf test results relevant + to the current build. + This variable is used by the Autotools utilities when running + configure. + + + + + CONFLICT_DISTRO_FEATURES + + + When a recipe inherits the + distro_features_check class, this + variable identifies distribution features that would + be in conflict should the recipe + be built. + In other words, if the + CONFLICT_DISTRO_FEATURES variable + lists a feature that also appears in + DISTRO_FEATURES within the + current configuration, an error occurs and the + build stops. + + + + + COPY_LIC_DIRS + + + If set to "1" along with the + COPY_LIC_MANIFEST + variable, the OpenEmbedded build system copies + into the image the license files, which are located in + /usr/share/common-licenses, + for each package. + The license files are placed + in directories within the image itself. + + + + + COPY_LIC_MANIFEST + + + If set to "1", the OpenEmbedded build system copies + the license manifest for the image to + /usr/share/common-licenses/license.manifest + within the image itself. + + + + + CORE_IMAGE_EXTRA_INSTALL + + + Specifies the list of packages to be added to the image. + You should only set this variable in the + local.conf configuration file found + in the + Build Directory. + + + + This variable replaces POKY_EXTRA_INSTALL, which is no longer supported. + + + + + COREBASE + + + Specifies the parent directory of the OpenEmbedded + Core Metadata layer (i.e. meta). + + + + It is an important distinction that + COREBASE points to the parent of this + layer and not the layer itself. + Consider an example where you have cloned the Poky Git + repository and retained the poky + name for your local copy of the repository. + In this case, COREBASE points to + the poky folder because it is the + parent directory of the poky/meta + layer. + + + + + + + D + + D + + + The destination directory. + The location in the Build Directory + where components are installed by the do_install task. + This location defaults to: + + ${WORKDIR}/image + + + + + + DATETIME + + + The date and time on which the current build started. + The format is suitable for timestamps. + + + + + DEBUG_BUILD + + + Specifies to build packages with debugging information. + This influences the value of the + SELECTED_OPTIMIZATION + variable. + + + + + DEBUG_OPTIMIZATION + + + The options to pass in + TARGET_CFLAGS + and CFLAGS when compiling + a system for debugging. + This variable defaults to "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe". + + + + + DEFAULT_PREFERENCE + + + Specifies a weak bias for recipe selection priority. + + + The most common usage of this is variable is to set + it to "-1" within a recipe for a development version of a + piece of software. + Using the variable in this way causes the stable version + of the recipe to build by default in the absence of + PREFERRED_VERSION + being used to build the development version. + + + The bias provided by DEFAULT_PREFERENCE + is weak and is overridden by + BBFILE_PRIORITY + if that variable is different between two layers + that contain different versions of the same recipe. + + + + + DEPENDS + + + Lists a recipe's build-time dependencies + (i.e. other recipe files). + The system ensures that all the dependencies listed + have been built and have their contents in the appropriate + sysroots before the recipe's configure task is executed. + + + + Consider this simple example for two recipes named "a" and + "b" that produce similarly named packages. + In this example, the DEPENDS + statement appears in the "a" recipe: + + DEPENDS = "b" + + Here, the dependency is such that the + do_configure task for recipe "a" + depends on the do_populate_sysroot + task of recipe "b". + This means anything that recipe "b" puts into sysroot + is available when recipe "a" is configuring itself. + + + + For information on runtime dependencies, see the + RDEPENDS + variable. + + + + + DEPLOY_DIR + + + Points to the general area that the OpenEmbedded build + system uses to place images, packages, SDKs and other output + files that are ready to be used outside of the build system. + By default, this directory resides within the + Build Directory + as ${TMPDIR}/deploy. + + + + For more information on the structure of the Build + Directory, see + "The Build Directory - build/" + section. + For more detail on the contents of the + deploy directory, see the + "Images" and + "Application Development SDK" + sections. + + + + + DEPLOY_DIR_IMAGE + + + Points to the area that the OpenEmbedded build system uses + to place images and other associated output files that are + ready to be deployed onto the target machine. + The directory is machine-specific as it contains the + ${MACHINE} name. + By default, this directory resides within the + Build Directory + as ${DEPLOY_DIR}/images/${MACHINE}/. + + + + For more information on the structure of the Build + Directory, see + "The Build Directory - build/" + section. + For more detail on the contents of the + deploy directory, see the + "Images" and + "Application Development SDK" + sections. + + + + + DEPLOYDIR + + + For recipes that inherit the + deploy + class, the DEPLOYDIR points to a + temporary work area for deployed files that is set in the + deploy class as follows: + + DEPLOYDIR = "${WORKDIR}/deploy-${PN}" + + Recipes inheriting the deploy class + should copy files to be deployed into + DEPLOYDIR, and the class will take + care of copying them into + DEPLOY_DIR_IMAGE + afterwards. + + + + + DESCRIPTION + + The package description used by package managers. + If not set, DESCRIPTION takes + the value of the + SUMMARY + variable. + + + + + DISK_SIGNATURE + + + A 32-bit MBR disk signature used by + directdisk images. + + + + By default, the signature is set to an automatically + generated random value that allows the OpenEmbedded + build system to create a boot loader. + You can override the signature in the image recipe + by setting DISK_SIGNATURE to an + 8-digit hex string. + You might want to override + DISK_SIGNATURE if you want the disk + signature to remain constant between image builds. + + + + When using Linux 3.8 or later, you can use + DISK_SIGNATURE to specify the root + by UUID to allow the kernel to locate the root device + even if the device name changes due to differences in + hardware configuration. + By default, SYSLINUX_ROOT is set + as follows: + + SYSLINUX_ROOT = "root=/dev/sda2" + + However, you can change this to locate the root device + using the disk signature instead: + + SYSLINUX_ROOT = "root=PARTUUID=${DISK_SIGNATURE}-02" + + + + + As previously mentioned, it is possible to set the + DISK_SIGNATURE variable in your + local.conf file to a fixed + value if you do not want syslinux.cfg + changing for each build. + You might find this useful when you want to upgrade the + root filesystem on a device without having to recreate or + modify the master boot record. + + + + + DISTRO + + + The short name of the distribution. + This variable corresponds to a distribution + configuration file whose root name is the same as the + variable's argument and whose filename extension is + .conf. + For example, the distribution configuration file for the + Poky distribution is named poky.conf + and resides in the + meta-yocto/conf/distro directory of + the + Source Directory. + + + + Within that poky.conf file, the + DISTRO variable is set as follows: + + DISTRO = "poky" + + + + + Distribution configuration files are located in a + conf/distro directory within the + Metadata + that contains the distribution configuration. + The value for DISTRO must not contain + spaces, and is typically all lower-case. + + If the DISTRO variable is blank, a set + of default configurations are used, which are specified + within + meta/conf/distro/defaultsetup.conf + also in the Source Directory. + + + + + + DISTRO_EXTRA_RDEPENDS + + + Specifies a list of distro-specific packages to add to all images. + This variable takes affect through + packagegroup-base so the + variable only really applies to the more full-featured + images that include packagegroup-base. + You can use this variable to keep distro policy out of + generic images. + As with all other distro variables, you set this variable + in the distro .conf file. + + + + + DISTRO_EXTRA_RRECOMMENDS + + + Specifies a list of distro-specific packages to add to all images + if the packages exist. + The packages might not exist or be empty (e.g. kernel modules). + The list of packages are automatically installed but you can + remove them. + + + + + DISTRO_FEATURES + + + The software support you want in your distribution for + various features. + You define your distribution features in the distribution + configuration file. + + + + In most cases, the presence or absence of a feature in + DISTRO_FEATURES is translated to the + appropriate option supplied to the configure script + during do_configure for recipes that + optionally support the feature. + For example, specifying "x11" in + DISTRO_FEATURES, causes + every piece of software built for the target that can + optionally support X11 to have its X11 support enabled. + + + + Two more examples are Bluetooth and NFS support. + For a more complete list of features that ships with the + Yocto Project and that you can provide with this variable, + see the + "Distro Features" + section. + + + + + DISTRO_FEATURES_BACKFILL + + Features to be added to + DISTRO_FEATURES + if not also present in + DISTRO_FEATURES_BACKFILL_CONSIDERED. + + + + This variable is set in the meta/conf/bitbake.conf file. + It is not intended to be user-configurable. + It is best to just reference the variable to see which distro features are + being backfilled for all distro configurations. + See the Feature backfilling section for + more information. + + + + + DISTRO_FEATURES_BACKFILL_CONSIDERED + + Features from + DISTRO_FEATURES_BACKFILL + that should not be backfilled (i.e. added to + DISTRO_FEATURES) + during the build. + See the "Feature Backfilling" section for + more information. + + + + + DISTRO_NAME + + The long name of the distribution. + + + + DISTRO_PN_ALIAS + + Alias names used for the recipe in various Linux distributions. + See the + "Handling + a Package Name Alias" section in the Yocto Project Development + Manual for more information. + + + + DISTRO_VERSION + + The version of the distribution. + + + + DISTROOVERRIDES + + + This variable lists overrides specific to the current + distribution. + By default, the variable list includes the value of the + DISTRO + variable. + You can extend the variable to apply any variable overrides + you want as part of the distribution and are not + already in OVERRIDES through + some other means. + + + + + DL_DIR + + + The central download directory used by the build process to + store downloads. + By default, DL_DIR gets files + suitable for mirroring for everything except Git + repositories. + If you want tarballs of Git repositories, use the + BB_GENERATE_MIRROR_TARBALLS + variable. + + + + You can set this directory by defining the + DL_DIR variable in the + conf/local.conf file. + This directory is self-maintaining and you should not have + to touch it. + By default, the directory is downloads + in the + Build Directory. + + #DL_DIR ?= "${TOPDIR}/downloads" + + To specify a different download directory, simply remove + the comment from the line and provide your directory. + + + + During a first build, the system downloads many different + source code tarballs from various upstream projects. + Downloading can take a while, particularly if your network + connection is slow. + Tarballs are all stored in the directory defined by + DL_DIR and the build system looks there + first to find source tarballs. + + When wiping and rebuilding, you can preserve this + directory to speed up this part of subsequent + builds. + + + + + You can safely share this directory between multiple builds + on the same development machine. + For additional information on how the build process gets + source files when working behind a firewall or proxy server, + see this specific question in the + "FAQ" + chapter. + + + + + + + E + + ENABLE_BINARY_LOCALE_GENERATION + + + Variable that controls which locales for + eglibc are generated during the + build (useful if the target device has 64Mbytes + of RAM or less). + + + + ERROR_QA + + + Specifies the quality assurance checks whose failures are + reported as errors by the OpenEmbedded build system. + You set this variable in your distribution configuration + file. + For a list of the checks you can control with this variable, + see the + "insane.bbclass" + section. + + + + + ERR_REPORT_DIR + + + When used with the + report-error + class, specifies the path used for storing the debug files + created by the + error reporting tool, + which allows you to submit build errors you encounter to a + central database. + By default, the value of this variable is + ${LOG_DIR}/error-report. + + + + You can set ERR_REPORT_DIR to the path + you want the error reporting tool to store the debug files + as follows in your local.conf file: + + ERR_REPORT_DIR = "path" + + + + + + EXCLUDE_FROM_WORLD + + + Directs BitBake to exclude a recipe from world builds (i.e. + bitbake world). + During world builds, BitBake locates, parses and builds all + recipes found in every layer exposed in the + bblayers.conf configuration file. + + + + To exclude a recipe from a world build using this variable, + set the variable to "1" in the recipe. + + + + Recipes added to EXCLUDE_FROM_WORLD + may still be built during a world build in order to satisfy + dependencies of other recipes. + Adding a recipe to EXCLUDE_FROM_WORLD + only ensures that the recipe is not explicitly added + to the list of build targets in a world build. + + + + + EXTENDPE + + + Used with file and pathnames to create a prefix for a recipe's + version based on the recipe's + PE value. + If PE is set and greater than zero for a recipe, + EXTENDPE becomes that value (e.g if + PE is equal to "1" then EXTENDPE + becomes "1_"). + If a recipe's PE is not set (the default) or is equal to + zero, EXTENDPE becomes "". + See the STAMP + variable for an example. + + + + + EXTENDPKGV + + + The full package version specification as it appears on the + final packages produced by a recipe. + The variable's value is normally used to fix a runtime + dependency to the exact same version of another package + in the same recipe: + + RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})" + + + + + The dependency relationships are intended to force the + package manager to upgrade these types of packages in + lock-step. + + + + + EXTERNALSRC + + + If externalsrc.bbclass is inherited, + this variable points to the source tree, which is + outside of the OpenEmbedded build system. + When set, this variable sets the + S + variable, which is what the OpenEmbedded build system uses + to locate unpacked recipe source code. + + + + For more information on + externalsrc.bbclass, see the + "externalsrc.bbclass" + section. + You can also find information on how to use this variable + in the + "Building Software from an External Source" + section in the Yocto Project Development Manual. + + + + + EXTERNALSRC_BUILD + + + If externalsrc.bbclass is inherited, + this variable points to the directory in which the recipe's + source code is built, + which is outside of the OpenEmbedded build system. + When set, this variable sets the + B + variable, which is what the OpenEmbedded build system uses + to locate the Build Directory. + + + + For more information on + externalsrc.bbclass, see the + "externalsrc.bbclass" + section. + You can also find information on how to use this variable + in the + "Building Software from an External Source" + section in the Yocto Project Development Manual. + + + + + EXTRA_IMAGE_FEATURES + + + The list of additional features to include in an image. + Typically, you configure this variable in your + local.conf file, which is found in the + Build Directory. + Although you can use this variable from within a recipe, + best practices dictate that you do not. + + To enable primary features from within the image + recipe, use the + IMAGE_FEATURES + variable. + + + + + Here are some examples of features you can add: + +"dbg-pkgs" - Adds -dbg packages for all installed packages + including symbol information for debugging and + profiling. + +"debug-tweaks" - Makes an image suitable for development. + For example, ssh root access has a blank + password. You should remove this feature + before you produce a production image. + +"dev-pkgs" - Adds -dev packages for all installed packages. + This is useful if you want to develop against + the libraries in the image. + +"read-only-rootfs" - Creates an image whose root + filesystem is read-only. See the + "Creating a Read-Only Root Filesystem" + section in the Yocto Project + Development Manual for more + information + +"tools-debug" - Adds debugging tools such as gdb and + strace. + +"tools-profile" - Adds profiling tools such as oprofile, + exmap, lttng and valgrind (x86 only). + +"tools-sdk" - Adds development tools such as gcc, make, + pkgconfig and so forth. + +"tools-testapps" - Adds useful testing tools such as + ts_print, aplay, arecord and so + forth. + + + + + + For a complete list of image features that ships with the + Yocto Project, see the + "Image Features" + section. + + + + For an example that shows how to customize your image by + using this variable, see the + "Customizing Images Using Custom IMAGE_FEATURES and EXTRA_IMAGE_FEATURES" + section in the Yocto Project Development Manual. + + + + + EXTRA_IMAGEDEPENDS + + A list of recipes to build that do not provide packages + for installing into the root filesystem. + + Sometimes a recipe is required to build the final image but is not + needed in the root filesystem. + You can use the EXTRA_IMAGEDEPENDS variable to + list these recipes and thus specify the dependencies. + A typical example is a required bootloader in a machine configuration. + + + To add packages to the root filesystem, see the various + *RDEPENDS + and *RRECOMMENDS + variables. + + + + + EXTRA_OECMAKE + + Additional cmake options. + + + + EXTRA_OECONF + + Additional configure script options. + + + + EXTRA_OEMAKE + + Additional GNU make options. + + + + EXTRA_OESCONS + + + When a recipe inherits the + scons + class, this variable specifies additional configuration + options you want to pass to the + scons command line. + + + + + EXTRA_QMAKEVARS_POST + + + Configuration variables or options you want to pass to + qmake. + Use this variable when the arguments need to be after the + .pro file list on the command line. + + + + This variable is used with recipes that inherit the + qmake_base + class or other classes that inherit + qmake_base. + + + + + EXTRA_QMAKEVARS_PRE + + + Configuration variables or options you want to pass to + qmake. + Use this variable when the arguments need to be before the + .pro file list on the command line. + + + + This variable is used with recipes that inherit the + qmake_base + class or other classes that inherit + qmake_base. + + + + + EXTRA_USERS_PARAMS + + + When a recipe inherits the + extrausers + class, this variable provides image level user and group + operations. + This is a more global method of providing user and group + configuration as compared to using the + useradd + class, which ties user and group configurations to a + specific recipe. + + + + The set list of commands you can configure using the + EXTRA_USERS_PARAMS is shown in the + extrausers class. + These commands map to the normal Unix commands of the same + names: + + # EXTRA_USERS_PARAMS = "\ + # useradd -p '' tester; \ + # groupadd developers; \ + # userdel nobody; \ + # groupdel -g video; \ + # groupmod -g 1020 developers; \ + # usermod -s /bin/sh tester; \ + # " + + + + + + + + F + + FEATURE_PACKAGES + + + Defines one or more packages to include in an image when + a specific item is included in + IMAGE_FEATURES. + When setting the value, FEATURE_PACKAGES + should have the name of the feature item as an override. + Here is an example: + + FEATURE_PACKAGES_widget = "package1 package2" + + In this example, if "widget" were added to + IMAGE_FEATURES, "package1" and + "package2" would be included in the image. + + Packages installed by features defined through + FEATURE_PACKAGES are often package + groups. + While similarly named, you should not confuse the + FEATURE_PACKAGES variable with + package groups, which are discussed elsewhere in the + documentation. + + + + + + FEED_DEPLOYDIR_BASE_URI + + + Points to the base URL of the server and location within + the document-root that provides the metadata and + packages required by OPKG to support runtime package + management of IPK packages. + You set this variable in your + local.conf file. + + + + Consider the following example: + + FEED_DEPLOYDIR_BASE_URI = "http://192.168.7.1/BOARD-dir" + + This example assumes you are serving your packages over + HTTP and your databases are located in a directory + named BOARD-dir, which is underneath + your HTTP server's document-root. + In this case, the OpenEmbedded build system generates a set + of configuration files for you in your target that work + with the feed. + + + + + FILES + + + The list of directories or files that are placed in packages. + + + + To use the FILES variable, provide a package name + override that identifies the resulting package. + Then, provide a space-separated list of files or paths that identifies the + files you want included as part of the resulting package. + Here is an example: + + FILES_${PN} += "${bindir}/mydir1/ ${bindir}/mydir2/myfile" + + + + + When specifying paths as part of the FILES variable, + it is good practice to use appropriate path variables. + For example, use ${sysconfdir} rather than + /etc, or ${bindir} rather + than /usr/bin. + You can find a list of these variables at the top of the + meta/conf/bitbake.conf file in the + Source Directory. + + + + If some of the files you provide with the FILES variable + are editable and you know they should not be + overwritten during the package update process by the Package Management + System (PMS), you can identify these files so that the PMS will not + overwrite them. + See the CONFFILES + variable for information on how to identify these files to the PMS. + + + + + + FILESEXTRAPATHS + + + Extends the search path the OpenEmbedded build system uses + when looking for files and patches as it processes recipes + and append files. + The default directories BitBake uses when it processes + recipes are initially defined by the + FILESPATH + variable. + You can extend FILESPATH variable + by using FILESEXTRAPATHS. + + + + Best practices dictate that you accomplish this by using + FILESEXTRAPATHS from within a + .bbappend file and that you prepend + paths as follows: + + FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" + + In the above example, the build system first looks for files + in a directory that has the same name as the corresponding + append file. + + When extending FILESEXTRAPATHS, + be sure to use the immediate expansion + (:=) operator. + Immediate expansion makes sure that BitBake evaluates + THISDIR + at the time the directive is encountered rather than at + some later time when expansion might result in a + directory that does not contain the files you need. + + Also, include the trailing separating colon + character if you are prepending. + The trailing colon character is necessary because you + are directing BitBake to extend the path by prepending + directories to the search path. + + Here is another common use: + + FILESEXTRAPATHS_prepend := "${THISDIR}/files:" + + In this example, the build system extends the + FILESPATH variable to include a + directory named files that is in the + same directory as the corresponding append file. + + + + Here is a final example that specifically adds three paths: + + FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:" + + + + + By prepending paths in .bbappend + files, you allow multiple append files that reside in + different layers but are used for the same recipe to + correctly extend the path. + + + + + FILESOVERRIDES + + + A subset of OVERRIDES + used by the OpenEmbedded build system for creating + FILESPATH. + You can find more information on how overrides are handled + in the BitBake Manual that is located at + bitbake/doc/manual in the + Source Directory. + + + + By default, the FILESOVERRIDES + variable is defined as: + + FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}" + + + + Do not hand-edit the FILESOVERRIDES + variable. + The values match up with expected overrides and are + used in an expected manner by the build system. + + + + + + FILESPATH + + + The default set of directories the OpenEmbedded build system + uses when searching for patches and files. + During the build process, BitBake searches each directory in + FILESPATH in the specified order when + looking for files and patches specified by each + file:// URI in a recipe. + + + + The default value for the FILESPATH + variable is defined in the base.bbclass + class found in meta/classes in the + Source Directory: + + FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \ + "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" + + + Do not hand-edit the FILESPATH + variable. + If you want the build system to look in directories + other than the defaults, extend the + FILESPATH variable by using the + FILESEXTRAPATHS + variable. + + Be aware that the default FILESPATH + directories do not map to directories in custom layers + where append files (.bbappend) + are used. + If you want the build system to find patches or files + that reside with your append files, you need to extend + the FILESPATH variable by using + the + FILESEXTRAPATHS + variable. + + + + + FILESYSTEM_PERMS_TABLES + + Allows you to define your own file permissions settings table as part of + your configuration for the packaging process. + For example, suppose you need a consistent set of custom permissions for + a set of groups and users across an entire work project. + It is best to do this in the packages themselves but this is not always + possible. + + + By default, the OpenEmbedded build system uses the fs-perms.txt, which + is located in the meta/files folder in the + Source Directory. + If you create your own file permissions setting table, you should place it in your + layer or the distro's layer. + + + You define the FILESYSTEM_PERMS_TABLES variable in the + conf/local.conf file, which is found in the + Build Directory, to + point to your custom fs-perms.txt. + You can specify more than a single file permissions setting table. + The paths you specify to these files must be defined within the + BBPATH variable. + + + For guidance on how to create your own file permissions settings table file, + examine the existing fs-perms.txt. + + + + + FONT_PACKAGES + + + When a recipe inherits the + fontcache + class, this variable identifies packages containing font + files that need to be cached by Fontconfig. + By default, the fontcache class assumes + that fonts are in the recipe's main package + (i.e. ${PN}). + Use this variable if fonts you need are in a package + other than that main package. + + + + + FULL_OPTIMIZATION + + + The options to pass in + TARGET_CFLAGS + and CFLAGS + when compiling an optimized system. + This variable defaults to + "-O2 -pipe ${DEBUG_FLAGS}". + + + + + + G + + GROUPADD_PARAM + + + When a recipe inherits the + useradd class, this variable + specifies for a package what parameters should be passed + to the groupadd command + if you wish to add a group to the system when the package + is installed. + + + + Here is an example from the dbus + recipe: + + GROUPADD_PARAM_${PN} = "-r netdev" + + For information on the standard Linux shell command + groupadd, see + . + + + + + GROUPMEMS_PARAM + + + When a recipe inherits the + useradd class, this variable + specifies for a package what parameters should be passed + to the groupmems command + if you wish to modify the members of a group when the + package is installed. + + + + For information on the standard Linux shell command + groupmems, see + . + + + + + GRUB_GFXSERIAL + + + Configures the GNU GRand Unified Bootloader (GRUB) to have + graphics and serial in the boot menu. + Set this variable to "1" in your + local.conf or distribution + configuration file to enable graphics and serial + in the menu. + + + + See the + grub-efi + class for more information on how this variable is used. + + + + + GRUB_OPTS + + + Additional options to add to the GNU GRand Unified + Bootloader (GRUB) configuration. + Use a semi-colon character (;) to + separate multiple options. + + + + The GRUB_OPTS variable is optional. + See the + grub-efi + class for more information on how this variable is used. + + + + + GRUB_TIMEOUT + + + Specifies the timeout before executing the default + LABEL in the GNU GRand Unified + Bootloader (GRUB). + + + + The GRUB_TIMEOUT variable is optional. + See the + grub-efi + class for more information on how this variable is used. + + + + + GTKIMMODULES_PACKAGES + + + For recipes that inherit the + gtk-immodules-cache + class, this variable specifies the packages that contain the + GTK+ input method modules being installed when the modules + are in packages other than the main package. + + + + + + + H + + HOMEPAGE + + Website where more information about the software the recipe is building + can be found. + + + + HOST_SYS + + + Specifies the system, including the architecture and the + operating system, for with the build is occurring + in the context of the current + recipe. + The OpenEmbedded build system automatically sets this + variable. + You do not need to set the variable yourself. + + + + Here are two examples: + + Given a native recipe on a 32-bit + x86 machine running Linux, the value is + "i686-linux". + + Given a recipe being built for a + little-endian MIPS target running Linux, + the value might be "mipsel-linux". + + + + + + + + + I + + ICECC_DISABLED + + + Disables or enables the icecc + (Icecream) function. + For more information on this function and best practices + for using this variable, see the + "icecc.bbclass" + section. + + + + Setting this variable to "1" in your + local.conf disables the function: + + ICECC_DISABLED ??= "1" + + To enable the function, set the variable as follows: + + ICECC_DISABLED = "" + + + + + + ICECC_ENV_EXEC + + + Points to the icecc-create-env script + that you provide. + This variable is used by the + icecc + class. + You set this variable in your + local.conf file. + + + + If you do not point to a script that you provide, the + OpenEmbedded build system uses the default script provided + by the icecc-create-env.bb recipe, + which is a modified version and not the one that comes with + icecc. + + + + + ICECC_PARALLEL_MAKE + + + Extra options passed to the make + command during the do_compile task + that specify parallel compilation. + This variable usually takes the form of + -j 4, where the number + represents the maximum number of parallel threads + make can run. + + The options passed affect builds on all enabled + machines on the network, which are machines running the + iceccd daemon. + + + + + If your enabled machines support multiple cores, + coming up with the maximum number of parallel threads + that gives you the best performance could take some + experimentation since machine speed, network lag, + available memory, and existing machine loads can all + affect build time. + Consequently, unlike the + PARALLEL_MAKE + variable, there is no rule-of-thumb for setting + ICECC_PARALLEL_MAKE to achieve + optimal performance. + + + + If you do not set ICECC_PARALLEL_MAKE, + the build system does not use it (i.e. the system does + not detect and assign the number of cores as is done with + PARALLEL_MAKE). + + + + + ICECC_PATH + + + The location of the icecc binary. + You can set this variable in your + local.conf file. + If your local.conf file does not define + this variable, the + icecc + class attempts to define it by locating + icecc using which. + + + + + ICECC_USER_CLASS_BL + + + Identifies user classes that you do not want the + Icecream distributed compile support to consider. + This variable is used by the + icecc + class. + You set this variable in your + local.conf file. + + + + When you list classes using this variable, you are + "blacklisting" them from distributed compilation across + remote hosts. + Any classes you list will be distributed and compiled + locally. + + + + + ICECC_USER_PACKAGE_BL + + + Identifies user recipes that you do not want the + Icecream distributed compile support to consider. + This variable is used by the + icecc + class. + You set this variable in your + local.conf file. + + + + When you list packages using this variable, you are + "blacklisting" them from distributed compilation across + remote hosts. + Any packages you list will be distributed and compiled + locally. + + + + + ICECC_USER_PACKAGE_WL + + + Identifies user recipes that use an empty + PARALLEL_MAKE + variable that you want to force remote distributed + compilation on using the Icecream distributed compile + support. + This variable is used by the + icecc + class. + You set this variable in your + local.conf file. + + + + + IMAGE_BASENAME + + + The base name of image output files. + This variable defaults to the recipe name + (${PN}). + + + + + IMAGE_CLASSES + + + A list of classes that all images should inherit. + You typically use this variable to specify the list of + classes that register the different types of images + the OpenEmbedded build system creates. + + + + The default value for IMAGE_CLASSES is + image_types. + You can set this variable in your + local.conf or in a distribution + configuration file. + + + + For more information, see + meta/classes/image_types.bbclass in the + Source Directory. + + + + + IMAGE_FEATURES + + + The primary list of features to include in an image. + Typically, you configure this variable in an image recipe. + Although you can use this variable from your + local.conf file, which is found in the + Build Directory, + best practices dictate that you do not. + + To enable extra features from outside the image recipe, + use the + EXTRA_IMAGE_FEATURES variable. + + For a list of image features that ships with the Yocto + Project, see the + "Image Features" + section. + + + + For an example that shows how to customize your image by + using this variable, see the + "Customizing Images Using Custom IMAGE_FEATURES and EXTRA_IMAGE_FEATURES" + section in the Yocto Project Development Manual. + + + + + IMAGE_FSTYPES + + + Specifies the formats the OpenEmbedded build system uses + during the build when creating the root filesystem. + For example, setting IMAGE_FSTYPES + as follows causes the build system to create root + filesystems using two formats: .ext3 + and .tar.bz2: + + IMAGE_FSTYPES = "ext3 tar.bz2" + + For the complete list of supported image formats from which + you can choose, see + IMAGE_TYPES. + + + + If you add "live" to IMAGE_FSTYPES + inside an image recipe, be sure that you do so prior to the + "inherit image" line of the recipe or the live image will + not build. + + + + Due to the way this variable is processed, it is not + possible to update its contents using + _append or + _prepend. To add one or more + additional options to this variable the + += operator must be used. + + + + + IMAGE_INSTALL + + + Specifies the packages to install into an image. + The IMAGE_INSTALL variable is a + mechanism for an image recipe and you should use it + with care to avoid ordering issues. + + When working with an + core-image-minimal-initramfs + image, do not use the IMAGE_INSTALL + variable to specify packages for installation. + Instead, use the + PACKAGE_INSTALL + variable, which allows the initial RAM disk (initramfs) + recipe to use a fixed set of packages and not be + affected by IMAGE_INSTALL. + + + + + Image recipes set IMAGE_INSTALL + to specify the packages to install into an image through + image.bbclass. + Additionally, "helper" classes exist, such as + core-image.bbclass, that can take + IMAGE_FEATURES + lists and turn these into auto-generated entries in + IMAGE_INSTALL in addition to its + default contents. + + + + Using IMAGE_INSTALL with the + += operator from the + /conf/local.conf file or from within + an image recipe is not recommended as it can cause ordering + issues. + Since core-image.bbclass sets + IMAGE_INSTALL to a default value using + the ?= operator, using a + += operation against + IMAGE_INSTALL will result in + unexpected behavior when used in + conf/local.conf. + Furthermore, the same operation from within an image + recipe may or may not succeed depending on the specific + situation. + In both these cases, the behavior is contrary to how most + users expect the += operator to work. + + + + When you use this variable, it is best to use it as follows: + + IMAGE_INSTALL_append = " package-name" + + Be sure to include the space between the quotation character + and the start of the package name or names. + + + + + IMAGE_LINGUAS + + + Specifies the list of locales to install into the image + during the root filesystem construction process. + The OpenEmbedded build system automatically splits locale + files, which are used for localization, into separate + packages. + Setting the IMAGE_LINGUAS variable + ensures that any locale packages that correspond to packages + already selected for installation into the image are also + installed. + Here is an example: + + IMAGE_LINGUAS = "pt-br de-de" + + In this example, the build system ensures any Brazilian + Portuguese and German locale files that correspond to + packages in the image are installed (i.e. + *-locale-pt-br + and *-locale-de-de as well as + *-locale-pt + and *-locale-de, since some software + packages only provide locale files by language and not by + country-specific language). + + + + + IMAGE_MANIFEST + + + The manifest file for the image. + This file lists all the installed packages that make up + the image. + The file contains package information on a line-per-package + basis as follows: + + <packagename> <packagearch> <version> + + + + + The + image + class defines the manifest file as follows: + + IMAGE_MANIFEST = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest" + + The location is derived using the + DEPLOY_DIR_IMAGE + and + IMAGE_NAME + variables. + You can find information on how the image + is created in the + "Image Generation" + section. + + + + + IMAGE_NAME + + + The name of the output image files minus the extension. + This variable is derived using the + IMAGE_BASENAME, + MACHINE, + and + DATETIME + variables: + + IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}" + + + + + + IMAGE_OVERHEAD_FACTOR + + + Defines a multiplier that the build system applies to the initial image + size for cases when the multiplier times the returned disk usage value + for the image is greater than the sum of + IMAGE_ROOTFS_SIZE + and + IMAGE_ROOTFS_EXTRA_SPACE. + The result of the multiplier applied to the initial image size creates + free disk space in the image as overhead. + By default, the build process uses a multiplier of 1.3 for this variable. + This default value results in 30% free disk space added to the image when this + method is used to determine the final generated image size. + You should be aware that post install scripts and the package management + system uses disk space inside this overhead area. + Consequently, the multiplier does not produce an image with + all the theoretical free disk space. + See IMAGE_ROOTFS_SIZE + for information on how the build system determines the overall image size. + + + + The default 30% free disk space typically gives the image enough room to boot + and allows for basic post installs while still leaving a small amount of + free disk space. + If 30% free space is inadequate, you can increase the default value. + For example, the following setting gives you 50% free space added to the image: + + IMAGE_OVERHEAD_FACTOR = "1.5" + + + + + Alternatively, you can ensure a specific amount of free disk space is added + to the image by using the + IMAGE_ROOTFS_EXTRA_SPACE + variable. + + + + + IMAGE_PKGTYPE + + + Defines the package type (DEB, RPM, IPK, or TAR) used + by the OpenEmbedded build system. + The variable is defined appropriately by the + package_deb, + package_rpm, + package_ipk, + or + package_tar + class. + + + + The + package_sdk_base + and + image + classes use the IMAGE_PKGTYPE for + packaging up images and SDKs. + + + + You should not set the IMAGE_PKGTYPE + manually. + Rather, the variable is set indirectly through the + appropriate + package_* + class using the + PACKAGE_CLASSES + variable. + The OpenEmbedded build system uses the first package type + (e.g. DEB, RPM, or IPK) that appears with the variable + + Files using the .tar format are + never used as a substitute packaging format for DEB, + RPM, and IPK formatted files for your image or SDK. + + + + + + IMAGE_POSTPROCESS_COMMAND + + + Added by classes to run post processing commands once the + OpenEmbedded build system has created the image. + You can specify shell commands separated by semicolons: + + IMAGE_POSTPROCESS_COMMAND += "<shell_command>; ... " + + If you need to pass the path to the root filesystem within + the command, you can use + ${IMAGE_ROOTFS}, which points to + the root filesystem image. + + + + + IMAGE_ROOTFS + + + The location of the root filesystem while it is under + construction (i.e. during do_rootfs). + This variable is not configurable. + Do not change it. + + + + + IMAGE_ROOTFS_EXTRA_SPACE + + + Defines additional free disk space created in the image in Kbytes. + By default, this variable is set to "0". + This free disk space is added to the image after the build system determines + the image size as described in + IMAGE_ROOTFS_SIZE. + + + + This variable is particularly useful when you want to ensure that a + specific amount of free disk space is available on a device after an image + is installed and running. + For example, to be sure 5 Gbytes of free disk space is available, set the + variable as follows: + + IMAGE_ROOTFS_EXTRA_SPACE = "5242880" + + + + + For example, the Yocto Project Build Appliance specifically requests 40 Gbytes + of extra space with the line: + + IMAGE_ROOTFS_EXTRA_SPACE = "41943040" + + + + + + IMAGE_ROOTFS_SIZE + + + Defines the size in Kbytes for the generated image. + The OpenEmbedded build system determines the final size for the generated + image using an algorithm that takes into account the initial disk space used + for the generated image, a requested size for the image, and requested + additional free disk space to be added to the image. + Programatically, the build system determines the final size of the + generated image as follows: + + if (image-du * overhead) < rootfs-size: + internal-rootfs-size = rootfs-size + xspace + else: + internal-rootfs-size = (image-du * overhead) + xspace + + where: + + image-du = Returned value of the du command on + the image. + + overhead = IMAGE_OVERHEAD_FACTOR + + rootfs-size = IMAGE_ROOTFS_SIZE + + internal-rootfs-size = Initial root filesystem + size before any modifications. + + xspace = IMAGE_ROOTFS_EXTRA_SPACE + + See the IMAGE_OVERHEAD_FACTOR + and IMAGE_ROOTFS_EXTRA_SPACE + variables for related information. + + + + + + IMAGE_TYPEDEP + + + Specifies a dependency from one image type on another. + Here is an example from the + image-live + class: + + IMAGE_TYPEDEP_live = "ext3" + + In the previous example, the variable ensures that when + "live" is listed with the + IMAGE_FSTYPES + variable, the OpenEmbedded build system produces an + ext3 image first since one of the + components of the live + image is an ext3 + formatted partition containing the root + filesystem. + + + + + IMAGE_TYPES + + + Specifies the complete list of supported image types + by default: + + jffs2 + jffs2.sum + cramfs + ext2 + ext2.gz + ext2.bz2 + ext3 + ext3.gz + ext2.lzma + btrfs + live + squashfs + squashfs-xz + ubi + ubifs + tar + tar.gz + tar.bz2 + tar.xz + cpio + cpio.gz + cpio.xz + cpio.lzma + vmdk + elf + + For more information on how these types of images, see + meta/classes/image_types*.bbclass + in the + Source Directory. + + + + + INC_PR + + Helps define the recipe revision for recipes that share + a common include file. + You can think of this variable as part of the recipe revision + as set from within an include file. + Suppose, for example, you have a set of recipes that + are used across several projects. + And, within each of those recipes the revision + (its PR + value) is set accordingly. + In this case, when the revision of those recipes changes, + the burden is on you to find all those recipes and + be sure that they get changed to reflect the updated + version of the recipe. + In this scenario, it can get complicated when recipes + that are used in many places and provide common functionality + are upgraded to a new revision. + A more efficient way of dealing with this situation is + to set the INC_PR variable inside + the include files that the recipes + share and then expand the INC_PR + variable within the recipes to help + define the recipe revision. + + + The following provides an example that shows how to use + the INC_PR variable + given a common include file that + defines the variable. + Once the variable is defined in the + include file, you can use the + variable to set the PR values in + each recipe. + You will notice that when you set a recipe's + PR you can provide more granular + revisioning by appending values to the + INC_PR variable: + +recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2" +recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1" +recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0" +recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" + + The first line of the example establishes the baseline + revision to be used for all recipes that use the + include file. + The remaining lines in the example are from individual + recipes and show how the PR value + is set. + + + + INCOMPATIBLE_LICENSE + + + Specifies a space-separated list of license names + (as they would appear in + LICENSE) + that should be excluded from the build. + Recipes that provide no alternatives to listed incompatible + licenses are not built. + Packages that are individually licensed with the specified + incompatible licenses will be deleted. + + + + This functionality is only regularly tested using + the following setting: + + INCOMPATIBLE_LICENSE = "GPLv3" + + Although you can use other settings, you might be required + to remove dependencies on or provide alternatives to + components that are required to produce a functional system + image. + + + + + INHIBIT_DEFAULT_DEPS + + + Prevents the default dependencies, namely the C compiler + and standard C library (libc), from being added to + DEPENDS. + This variable is usually used within recipes that do not + require any compilation using the C compiler. + + + + Set the variable to "1" to prevent the default dependencies + from being added. + + + + + INHIBIT_PACKAGE_STRIP + + + If set to "1", causes the build to not strip binaries in resulting packages. + + + + + INHERIT + + + Causes the named class to be inherited at + this point during parsing. + The variable is only valid in configuration files. + + + + + INHERIT_DISTRO + + + Lists classes that will be inherited at the + distribution level. + It is unlikely that you want to edit this variable. + + + + The default value of the variable is set as follows in the + meta/conf/distro/defaultsetup.conf + file: + + INHERIT_DISTRO ?= "debian devshell sstate license" + + + + + + INITRAMFS_FSTYPES + + + Defines the format for the output image of an initial + RAM disk (initramfs), which is used during boot. + Supported formats are the same as those supported by the + IMAGE_FSTYPES + variable. + + + + + INITRAMFS_IMAGE + + + Causes the OpenEmbedded build system to build an additional + recipe as a dependency to your root filesystem recipe + (e.g. core-image-sato). + The additional recipe is used to create an initial RAM disk + (initramfs) that might be needed during the initial boot of + the target system to accomplish such things as loading + kernel modules prior to mounting the root file system. + + + + When you set the variable, specify the name of the + initramfs you want created. + The following example, which is set in the + local.conf configuration file, causes + a separate recipe to be created that results in an + initramfs image named + core-image-sato-initramfs.bb to be + created: + + INITRAMFS_IMAGE = "core-image-minimal-initramfs" + + By default, the + kernel + class sets this variable to a null string as follows: + + INITRAMFS_IMAGE = "" + + + + + See the + local.conf.sample.extended + file for additional information. + You can also reference the + kernel.bbclass + file to see how the variable is used. + + + + + INITRAMFS_IMAGE_BUNDLE + + + Controls whether or not the image recipe specified by + INITRAMFS_IMAGE + is run through an extra pass during kernel compilation + in order to build a single binary that contains both the + kernel image and the initial RAM disk (initramfs). + Using an extra compilation pass ensures that when a kernel + attempts to use an initramfs, it does not encounter + circular dependencies should the initramfs include kernel + modules. + + + + The combined binary is deposited into the + tmp/deploy directory, which is part + of the + Build Directory. + + + + Setting the variable to "1" in a configuration file causes + the OpenEmbedded build system to make the extra pass during + kernel compilation: + + INITRAMFS_IMAGE_BUNDLE = "1" + + By default, the + kernel + class sets this variable to a null string as follows: + + INITRAMFS_IMAGE_BUNDLE = "" + + + You must set the + INITRAMFS_IMAGE_BUNDLE variable in + a configuration file. + You cannot set the variable in a recipe file. + + See the + local.conf.sample.extended + file for additional information. + + + + + INITRD + + + Indicates a filesystem image to use as an initial RAM + disk (initrd). + + + + The INITRD variable is an optional + variable used with the + buildimg + class. + + + + + INITSCRIPT_NAME + + + The filename of the initialization script as installed to + ${sysconfdir}/init.d. + + + This variable is used in recipes when using update-rc.d.bbclass. + The variable is mandatory. + + + + + INITSCRIPT_PACKAGES + + + A list of the packages that contain initscripts. + If multiple packages are specified, you need to append the package name + to the other INITSCRIPT_* as an override. + + This variable is used in recipes when using update-rc.d.bbclass. + The variable is optional and defaults to the + PN variable. + + + + + INITSCRIPT_PARAMS + + + Specifies the options to pass to update-rc.d. + Here is an example: + + INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ." + + In this example, the script has a runlevel of 99, + starts the script in initlevels 2 and 5, and + stops the script in levels 0, 1 and 6. + + + The variable is mandatory and is used in recipes when using + update-rc.d.bbclass. + + + + + INSANE_SKIP + + + Specifies the QA checks to skip for a specific package + within a recipe. + For example, to skip the check for symbolic link + .so files in the main package of a + recipe, add the following to the recipe. + The package name override must be used, which in this + example is ${PN}: + + INSANE_SKIP_${PN} += "dev-so" + + + + See the "insane.bbclass" + section for a list of the valid QA checks you can + specify using this variable. + + + + + IPK_FEED_URIS + + + When the IPK backend is in use and package management + is enabled on the target, you can use this variable to + set up opkg in the target image + to point to package feeds on a nominated server. + Once the feed is established, you can perform + installations or upgrades using the package manager + at runtime. + + + + + + + + + + + + K + + KARCH + + + Defines the kernel architecture used when assembling + the configuration. + Architectures supported for this release are: + + powerpc + i386 + x86_64 + arm + qemu + mips + + + + + You define the KARCH variable in the + BSP Descriptions. + + + + + KBRANCH + + + A regular expression used by the build process to explicitly + identify the kernel branch that is validated, patched + and configured during a build. + The KBRANCH variable is optional. + You can use it to trigger checks to ensure the exact kernel + branch you want is being used by the build process. + + + + Values for this variable are set in the kernel's recipe + file and the kernel's append file. + For example, if you are using the Yocto Project kernel that + is based on the Linux 3.10 kernel, the kernel recipe file + is the + meta/recipes-kernel/linux/linux-yocto_3.10.bb + file. + Following is the default value for KBRANCH + and the default override for the architectures the Yocto + Project supports: + + KBRANCH_DEFAULT = "standard/base" + KBRANCH = "${KBRANCH_DEFAULT}" + + This branch exists in the linux-yocto-3.10 + kernel Git repository + . + + + + This variable is also used from the kernel's append file + to identify the kernel branch specific to a particular + machine or target hardware. + The kernel's append file is located in the BSP layer for + a given machine. + For example, the kernel append file for the Crown Bay BSP is in the + meta-intel Git repository and is named + meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend. + Here are the related statements from the append file: + + COMPATIBLE_MACHINE_crownbay = "crownbay" + KMACHINE_crownbay = "crownbay" + KBRANCH_crownbay = "standard/crownbay" + KERNEL_FEATURES_append_crownbay = " features/drm-emgd/drm-emgd-1.18 cfg/vesafb" + + COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd" + KMACHINE_crownbay-noemgd = "crownbay" + KBRANCH_crownbay-noemgd = "standard/crownbay" + KERNEL_FEATURES_append_crownbay-noemgd = " cfg/vesafb" + + The KBRANCH_* statements identify + the kernel branch to use when building for the Crown + Bay BSP. + In this case there are two identical statements: one + for each type of Crown Bay machine. + + + + + KBRANCH_DEFAULT + + + Defines the Linux kernel source repository's default + branch used to build the Linux kernel. + The KBRANCH_DEFAULT value is + the default value for + KBRANCH. + Unless you specify otherwise, + KBRANCH_DEFAULT initializes to + "master". + + + + + KERNEL_EXTRA_ARGS + + + Specifies additional make + command-line arguments the OpenEmbedded build system + passes on when compiling the kernel. + + + + + KERNEL_FEATURES + + Includes additional metadata from the Yocto Project kernel Git repository. + In the OpenEmbedded build system, the default Board Support Packages (BSPs) + Metadata + is provided through + the KMACHINE + and KBRANCH variables. + You can use the KERNEL_FEATURES variable to further + add metadata for all BSPs. + The metadata you add through this variable includes config fragments and + features descriptions, + which usually includes patches as well as config fragments. + You typically override the KERNEL_FEATURES variable + for a specific machine. + In this way, you can provide validated, but optional, sets of kernel + configurations and features. + For example, the following adds netfilter to all + the Yocto Project kernels and adds sound support to the qemux86 + machine: + + # Add netfilter to all linux-yocto kernels + KERNEL_FEATURES="features/netfilter" + + # Add sound support to the qemux86 machine + KERNEL_FEATURES_append_qemux86=" cfg/sound" + + + + + KERNEL_IMAGE_BASE_NAME + + + The base name of the kernel image. + This variable is set in the + kernel class + as follows: + + KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" + + See the + KERNEL_IMAGETYPE, + PKGE, + PKGV, + PKGR, + MACHINE, + and + DATETIME + variables for additional information. + + + + + KERNEL_IMAGETYPE + + The type of kernel to build for a device, usually set by the + machine configuration files and defaults to "zImage". + This variable is used + when building the kernel and is passed to make as the target to + build. + + + + KERNEL_PATH + + + The location of the kernel sources. + This variable is set to the value of the + STAGING_KERNEL_DIR + within the module.bbclass class. + For information on how this variable is used, see the + "Incorporating Out-of-Tree Modules" + section. + + + + To help maximize compatibility with out-of-tree drivers + used to build modules, the OpenEmbedded build system also + recognizes and uses the + KERNEL_SRC + variable, which is identical to the + KERNEL_PATH variable. + Both variables are common variables used by external + Makefiles to point to the kernel source directory. + + + + + KERNEL_SRC + + + The location of the kernel sources. + This variable is set to the value of the + STAGING_KERNEL_DIR + within the module.bbclass class. + For information on how this variable is used, see the + "Incorporating Out-of-Tree Modules" + section. + + + + To help maximize compatibility with out-of-tree drivers + used to build modules, the OpenEmbedded build system also + recognizes and uses the + KERNEL_PATH + variable, which is identical to the + KERNEL_SRC variable. + Both variables are common variables used by external + Makefiles to point to the kernel source directory. + + + + + KFEATURE_DESCRIPTION + + + Provides a short description of a configuration fragment. + You use this variable in the .scc + file that describes a configuration fragment file. + Here is the variable used in a file named + smp.scc to describe SMP being + enabled: + + define KFEATURE_DESCRIPTION "Enable SMP" + + + + + + KMACHINE + + + The machine as known by the kernel. + Sometimes the machine name used by the kernel does not match the machine name + used by the OpenEmbedded build system. + For example, the machine name that the OpenEmbedded build system understands as + qemuarm goes by a different name in the Linux Yocto kernel. + The kernel understands that machine as arm_versatile926ejs. + For cases like these, the KMACHINE variable maps the + kernel machine name to the OpenEmbedded build system machine name. + + + + Kernel machine names are initially defined in the + Yocto Linux Kernel's meta branch. + From the meta branch, look in + the meta/cfg/kernel-cache/bsp/<bsp_name>/<bsp-name>-<kernel-type>.scc file. + For example, from the meta branch in the + linux-yocto-3.0 kernel, the + meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc file + has the following: + + define KMACHINE cedartrail + define KTYPE standard + define KARCH i386 + + include ktypes/standard + branch cedartrail + + include cedartrail.scc + + You can see that the kernel understands the machine name for + the Cedar Trail Board Support Package (BSP) as + cedartrail. + + + + If you look in the Cedar Trail BSP layer in the + meta-intel + Source Repositories + at meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend, + you will find the following statements among others: + + COMPATIBLE_MACHINE_cedartrail = "cedartrail" + KMACHINE_cedartrail = "cedartrail" + KBRANCH_cedartrail = "yocto/standard/cedartrail" + KERNEL_FEATURES_append_cedartrail += "bsp/cedartrail/cedartrail-pvr-merge.scc" + KERNEL_FEATURES_append_cedartrail += "cfg/efi-ext.scc" + + COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail" + KMACHINE_cedartrail-nopvr = "cedartrail" + KBRANCH_cedartrail-nopvr = "yocto/standard/cedartrail" + KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc" + + The KMACHINE statements in the kernel's append file make sure that + the OpenEmbedded build system and the Yocto Linux kernel understand the same machine + names. + + + + This append file uses two KMACHINE statements. + The first is not really necessary but does ensure that the machine known to the + OpenEmbedded build system as cedartrail maps to the machine + in the kernel also known as cedartrail: + + KMACHINE_cedartrail = "cedartrail" + + + + + The second statement is a good example of why the KMACHINE variable + is needed. + In this example, the OpenEmbedded build system uses the cedartrail-nopvr + machine name to refer to the Cedar Trail BSP that does not support the proprietary + PowerVR driver. + The kernel, however, uses the machine name cedartrail. + Thus, the append file must map the cedartrail-nopvr machine name to + the kernel's cedartrail name: + + KMACHINE_cedartrail-nopvr = "cedartrail" + + + + + BSPs that ship with the Yocto Project release provide all mappings between the Yocto + Project kernel machine names and the OpenEmbedded machine names. + Be sure to use the KMACHINE if you create a BSP and the machine + name you use is different than that used in the kernel. + + + + + KTYPE + + + Defines the kernel type to be used in assembling the + configuration. + The linux-yocto recipes define "standard", "tiny", + and "preempt-rt" kernel types. + See the + "Kernel Types" + section in the Yocto Project Linux Kernel Development + Manual for more information on kernel types. + + + + You define the KTYPE variable in the + BSP Descriptions. + The value you use must match the value used for the + LINUX_KERNEL_TYPE + value used by the kernel recipe. + + + + + + L + + LABELS + + + Provides a list of targets for automatic configuration. + + + + See the + grub-efi + class for more information on how this variable is used. + + + + + LAYERDEPENDS + + Lists the layers that this recipe depends upon, separated by spaces. + Optionally, you can specify a specific layer version for a dependency + by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3" + to be compared against + LAYERVERSION_anotherlayer + in this case). + An error will be produced if any dependency is missing or + the version numbers do not match exactly (if specified). + This variable is used in the conf/layer.conf file + and must be suffixed with the name of the specific layer (e.g. + LAYERDEPENDS_mylayer). + + + + LAYERDIR + + When used inside the layer.conf configuration + file, this variable provides the path of the current layer. + This variable is not available outside of layer.conf + and references are expanded immediately when parsing of the file completes. + + + + LAYERVERSION + + Optionally specifies the version of a layer as a single number. + You can use this within + LAYERDEPENDS + for another layer in order to depend on a specific version + of the layer. + This variable is used in the conf/layer.conf file + and must be suffixed with the name of the specific layer (e.g. + LAYERVERSION_mylayer). + + + + LEAD_SONAME + + + Specifies the lead (or primary) compiled library file + (.so) that the + debian + class applies its naming policy to given a recipe that + packages multiple libraries. + + + + This variable works in conjunction with the + debian class. + + + + + LIC_FILES_CHKSUM + + Checksums of the license text in the recipe source code. + This variable tracks changes in license text of the source + code files. + If the license text is changed, it will trigger a build + failure, which gives the developer an opportunity to review any + license change. + + This variable must be defined for all recipes (unless + LICENSE + is set to "CLOSED") + For more information, see the + + Tracking License Changes section + + + + LICENSE + + + The list of source licenses for the recipe. + Follow these rules: + + Do not use spaces within individual + license names. + Separate license names using + | (pipe) when there is a choice between licenses. + + Separate license names using + & (ampersand) when multiple licenses exist + that cover different parts of the source. + + You can use spaces between license + names. + For standard licenses, use the names + of the files in + meta/files/common-licenses/ + or the + SPDXLICENSEMAP + flag names defined in + meta/conf/licenses.conf. + + + + + + Here are some examples: + + LICENSE = "LGPLv2.1 | GPLv3" + LICENSE = "MPL-1 & LGPLv2.1" + LICENSE = "GPLv2+" + + The first example is from the recipes for Qt, which the user + may choose to distribute under either the LGPL version + 2.1 or GPL version 3. + The second example is from Cairo where two licenses cover + different parts of the source code. + The final example is from sysstat, + which presents a single license. + + + + You can also specify licenses on a per-package basis to + handle situations where components of the output have + different licenses. + For example, a piece of software whose code is + licensed under GPLv2 but has accompanying documentation + licensed under the GNU Free Documentation License 1.2 could + be specified as follows: + + LICENSE = "GFDL-1.2 & GPLv2" + LICENSE_${PN} = "GPLv2" + LICENSE_${PN}-doc = "GFDL-1.2" + + + + + + LICENSE_PATH + + Path to additional licenses used during the build. + By default, the OpenEmbedded build system uses COMMON_LICENSE_DIR + to define the directory that holds common license text used during the build. + The LICENSE_PATH variable allows you to extend that + location to other areas that have additional licenses: + + LICENSE_PATH += "/path/to/additional/common/licenses" + + + + + LINUX_KERNEL_TYPE + + + Defines the kernel type to be used in assembling the + configuration. + The linux-yocto recipes define "standard", "tiny", and + "preempt-rt" kernel types. + See the + "Kernel Types" + section in the Yocto Project Linux Kernel Development + Manual for more information on kernel types. + + + + If you do not specify a + LINUX_KERNEL_TYPE, it defaults to + "standard". + Together with + KMACHINE, + the LINUX_KERNEL_TYPE variable + defines the search + arguments used by the kernel tools to find the appropriate + description within the kernel + Metadata + with which to build out the sources and configuration. + + + + + LINUX_VERSION + + The Linux version from kernel.org + on which the Linux kernel image being built using the + OpenEmbedded build system is based. + You define this variable in the kernel recipe. + For example, the linux-yocto-3.4.bb + kernel recipe found in + meta/recipes-kernel/linux + defines the variables as follows: + + LINUX_VERSION ?= "3.4.24" + + The LINUX_VERSION variable is used to + define PV + for the recipe: + + PV = "${LINUX_VERSION}+git${SRCPV}" + + + + + LINUX_VERSION_EXTENSION + + A string extension compiled into the version + string of the Linux kernel built with the OpenEmbedded + build system. + You define this variable in the kernel recipe. + For example, the linux-yocto kernel recipes all define + the variable as follows: + + LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}" + + Defining this variable essentially sets the + Linux kernel configuration item + CONFIG_LOCALVERSION, which is visible + through the uname command. + Here is an example that shows the extension assuming it + was set as previously shown: + + $ uname -r + 3.7.0-rc8-custom + + + + + + LOG_DIR + + + Specifies the directory to which the OpenEmbedded build + system writes overall log files. + The default directory is ${TMPDIR}/log. + + + For the directory containing logs specific to each task, + see the T + variable. + + + + + + + M + + MACHINE + + + Specifies the target device for which the image is built. + You define MACHINE in the + local.conf file found in the + Build Directory. + By default, MACHINE is set to + "qemux86", which is an x86-based architecture machine to + be emulated using QEMU: + + MACHINE ?= "qemux86" + + The variable corresponds to a machine configuration file of the + same name, through which machine-specific configurations are set. + Thus, when MACHINE is set to "qemux86" there + exists the corresponding qemux86.conf machine + configuration file, which can be found in the + Source Directory + in meta/conf/machine. + + + + The list of machines supported by the Yocto Project as + shipped include the following: + + MACHINE ?= "qemuarm" + MACHINE ?= "qemumips" + MACHINE ?= "qemuppc" + MACHINE ?= "qemux86" + MACHINE ?= "qemux86-64" + MACHINE ?= "genericx86" + MACHINE ?= "genericx86-64" + MACHINE ?= "beaglebone" + MACHINE ?= "mpc8315e-rdb" + MACHINE ?= "edgerouter" + + The last five are Yocto Project reference hardware boards, which + are provided in the meta-yocto-bsp layer. + Adding additional Board Support Package (BSP) layers + to your configuration adds new possible settings for + MACHINE. + + + + + + MACHINE_ESSENTIAL_EXTRA_RDEPENDS + + + + A list of required machine-specific packages to install as part of + the image being built. + The build process depends on these packages being present. + Furthermore, because this is a "machine essential" variable, the list of + packages are essential for the machine to boot. + The impact of this variable affects images based on + packagegroup-core-boot, + including the core-image-minimal image. + + + This variable is similar to the + MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS + variable with the exception that the image being built has a build + dependency on the variable's list of packages. + In other words, the image will not build if a file in this list is not found. + + + As an example, suppose the machine for which you are building requires + example-init to be run during boot to initialize the hardware. + In this case, you would use the following in the machine's + .conf configuration file: + + MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init" + + + + + + MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS + + + + A list of recommended machine-specific packages to install as part of + the image being built. + The build process does not depend on these packages being present. + However, because this is a "machine essential" variable, the list of + packages are essential for the machine to boot. + The impact of this variable affects images based on + packagegroup-core-boot, + including the core-image-minimal image. + + + This variable is similar to the + MACHINE_ESSENTIAL_EXTRA_RDEPENDS + variable with the exception that the image being built does not have a build + dependency on the variable's list of packages. + In other words, the image will still build if a package in this list is not found. + Typically, this variable is used to handle essential kernel modules, whose + functionality may be selected to be built into the kernel rather than as a module, + in which case a package will not be produced. + + + Consider an example where you have a custom kernel where a specific touchscreen + driver is required for the machine to be usable. + However, the driver can be built as a module or + into the kernel depending on the kernel configuration. + If the driver is built as a module, you want it to be installed. + But, when the driver is built into the kernel, you still want the + build to succeed. + This variable sets up a "recommends" relationship so that in the latter case, + the build will not fail due to the missing package. + To accomplish this, assuming the package for the module was called + kernel-module-ab123, you would use the + following in the machine's .conf configuration + file: + + MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123" + + + + Some examples of these machine essentials are flash, screen, keyboard, mouse, + or touchscreen drivers (depending on the machine). + + + + + MACHINE_EXTRA_RDEPENDS + + + A list of machine-specific packages to install as part of the + image being built that are not essential for the machine to boot. + However, the build process for more fully-featured images + depends on the packages being present. + + + This variable affects all images based on + packagegroup-base, which does not include the + core-image-minimal or core-image-full-cmdline + images. + + + The variable is similar to the + MACHINE_EXTRA_RRECOMMENDS + variable with the exception that the image being built has a build + dependency on the variable's list of packages. + In other words, the image will not build if a file in this list is not found. + + + An example is a machine that has WiFi capability but is not + essential for the machine to boot the image. + However, if you are building a more fully-featured image, you want to enable + the WiFi. + The package containing the firmware for the WiFi hardware is always + expected to exist, so it is acceptable for the build process to depend upon + finding the package. + In this case, assuming the package for the firmware was called + wifidriver-firmware, you would use the following in the + .conf file for the machine: + + MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware" + + + + + + MACHINE_EXTRA_RRECOMMENDS + + + + A list of machine-specific packages to install as part of the + image being built that are not essential for booting the machine. + The image being built has no build dependency on this list of packages. + + + This variable affects only images based on + packagegroup-base, which does not include the + core-image-minimal or core-image-full-cmdline + images. + + + This variable is similar to the + MACHINE_EXTRA_RDEPENDS + variable with the exception that the image being built does not have a build + dependency on the variable's list of packages. + In other words, the image will build if a file in this list is not found. + + + An example is a machine that has WiFi capability but is not essential + For the machine to boot the image. + However, if you are building a more fully-featured image, you want to enable + WiFi. + In this case, the package containing the WiFi kernel module will not be produced + if the WiFi driver is built into the kernel, in which case you still want the + build to succeed instead of failing as a result of the package not being found. + To accomplish this, assuming the package for the module was called + kernel-module-examplewifi, you would use the + following in the .conf file for the machine: + + MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi" + + + + + + MACHINE_FEATURES + + + Specifies the list of hardware features the + MACHINE is capable + of supporting. + For related information on enabling features, see the + DISTRO_FEATURES, + COMBINED_FEATURES, + and + IMAGE_FEATURES + variables. + + + + For a list of hardware features supported by the Yocto + Project as shipped, see the + "Machine Features" + section. + + + + + MACHINE_FEATURES_BACKFILL + + Features to be added to + MACHINE_FEATURES + if not also present in + MACHINE_FEATURES_BACKFILL_CONSIDERED. + + + + This variable is set in the meta/conf/bitbake.conf file. + It is not intended to be user-configurable. + It is best to just reference the variable to see which machine features are + being backfilled for all machine configurations. + See the "Feature backfilling" section for + more information. + + + + + MACHINE_FEATURES_BACKFILL_CONSIDERED + + Features from + MACHINE_FEATURES_BACKFILL + that should not be backfilled (i.e. added to + MACHINE_FEATURES) + during the build. + See the "Feature backfilling" section for + more information. + + + + + MACHINEOVERRIDES + + + Lists overrides specific to the current machine. + By default, this list includes the value + of MACHINE. + You can extend the list to apply variable overrides for + classes of machines. + For example, all QEMU emulated machines (e.g. qemuarm, + qemux86, and so forth) include a common file named + meta/conf/machine/include/qemu.inc + that prepends MACHINEOVERRIDES with + the following variable override: + + MACHINEOVERRIDES =. "qemuall:" + + Applying an override like qemuall + affects all QEMU emulated machines elsewhere. + Here is an example from the + connman-conf recipe: + + SRC_URI_append_qemuall = "file://wired.config \ + file://wired-setup \ + " + + + + + + MAINTAINER + + The email address of the distribution maintainer. + + + + MIRRORS + + + Specifies additional paths from which the OpenEmbedded + build system gets source code. + When the build system searches for source code, it first + tries the local download directory. + If that location fails, the build system tries locations + defined by + PREMIRRORS, + the upstream source, and then locations specified by + MIRRORS in that order. + + + + Assuming your distribution + (DISTRO) + is "poky", the default value for + MIRRORS is defined in the + conf/distro/poky.conf file in the + meta-yocto Git repository. + + + + + MLPREFIX + + + Specifies a prefix has been added to + PN to create a special version + of a recipe or package, such as a Multilib version. + The variable is used in places where the prefix needs to be + added to or removed from a the name (e.g. the + BPN variable). + MLPREFIX gets set when a prefix has been + added to PN. + + + + + module_autoload + + + Lists kernel modules that need to be auto-loaded during + boot. + + + + You can use this variable anywhere that it can be + recognized by the kernel recipe or out-of-tree kernel + module recipe (e.g. a machine configuration file, a + distribution configuration file, an append file for the + recipe, or the recipe itself). + + + + Specify it as follows: + + module_autoload_<modname> = "modname1 modname2 modname3" + + You must use the kernel module name override. + + + + Including module_autoload causes the + OpenEmbedded build system to populate the + /etc/modules-load.d/modname.conf + file with the list of modules to be auto-loaded on boot. + The modules appear one-per-line in the file. + Here is an example of the most common use case: + + module_autoload_modname = "modname" + + + + + For information on how to populate the + modname.conf file with + modprobe.d syntax lines, see the + module_conf + variable. + + + + + module_conf + + + Specifies modprobe.d syntax lines + for inclusion in the + /etc/modprobe.d/modname.conf file. + + + + You can use this variable anywhere that it can be + recognized by the kernel recipe or out-of-tree kernel + module recipe (e.g. a machine configuration file, a + distribution configuration file, an append file for the + recipe, or the recipe itself). + + + + Here is the general syntax: + + module_conf_<modname> = "modprobe.d-syntax" + + You must use the kernel module name override. + + + + Run man modprobe.d in the shell to + find out more information on the exact syntax for lines + you want to provide with module_conf. + + + + Including module_conf causes the + OpenEmbedded build system to populate the + /etc/modprobe.d/modname.conf + file with modprobe.d syntax lines. + Here is an example: + + module_conf_<modname> = "options modname arg1=val1 arg2=val2" + + + + + For information on how to specify kernel modules to + auto-load on boot, see the + module_autoload + variable. + + + + + MODULE_IMAGE_BASE_NAME + + + The base name of the kernel modules tarball. + This variable is set in the + kernel class + as follows: + + MODULE_IMAGE_BASE_NAME ?= "modules-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" + + See the + PKGE, + PKGV, + PKGR, + MACHINE, + and + DATETIME + variables for additional information. + + + + + MODULE_TARBALL_DEPLOY + + + Controls creation of the modules-*.tgz + file. + Set this variable to "0" to disable creation of this + file, which contains all of the kernel modules resulting + from a kernel build. + + + + + MULTIMACH_TARGET_SYS + + + Separates files for different machines such that you can build + for multiple target machines using the same output directories. + See the STAMP variable + for an example. + + + + + + + N + + NATIVELSBSTRING + + + A string identifying the host distribution. + Strings consist of the host distributor ID + followed by the release, as reported by the + lsb_release tool + or as read from /etc/lsb-release. + For example, when running a build on Ubuntu 12.10, the value + is "Ubuntu-12.10". + If this information is unable to be determined, the value + resolves to "Unknown". + + + This variable is used by default to isolate native shared + state packages for different distributions (e.g. to avoid + problems with glibc version + incompatibilities). + Additionally, the variable is checked against + SANITY_TESTED_DISTROS + if that variable is set. + + + + + NO_RECOMMENDATIONS + + + Prevents installation of all "recommended-only" packages. + Recommended-only packages are packages installed only + through the + RRECOMMENDS + variable). + Setting the NO_RECOMMENDATIONS variable + to "1" turns this feature on: + + NO_RECOMMENDATIONS = "1" + + You can set this variable globally in your + local.conf file or you can attach it to + a specific image recipe by using the recipe name override: + + NO_RECOMMENDATIONS_pn-<target_image> = "<package_name>" + + + + + It is important to realize that if you choose to not install + packages using this variable and some other packages are + dependent on them (i.e. listed in a recipe's + RDEPENDS + variable), the OpenEmbedded build system ignores your + request and will install the packages to avoid dependency + errors. + + Some recommended packages might be required for certain + system functionality, such as kernel modules. + It is up to you to add packages with the + IMAGE_INSTALL + variable. + + + + + Support for this variable exists only when using the + IPK and RPM packaging backend. + Support does not exist for DEB. + + + + See the + BAD_RECOMMENDATIONS + and the + PACKAGE_EXCLUDE + variables for related information. + + + + + NOHDD + + + Causes the OpenEmbedded build system to skip building the + .hddimg image. + The NOHDD variable is used with the + buildimg + class. + Set the variable to "1" to prevent the + .hddimg image from being built. + + + + + NOISO + + + Causes the OpenEmbedded build system to skip building the + ISO image. + The NOISO variable is used with the + buildimg + class. + Set the variable to "1" to prevent the ISO image from + being built. + To enable building an ISO image, set the variable to "0". + + + + + + + O + + OE_BINCONFIG_EXTRA_MANGLE + + + When a recipe inherits the + binconfig.bbclass class, this variable + specifies additional arguments passed to the "sed" command. + The sed command alters any paths in configuration scripts + that have been set up during compilation. + 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 will use the correct directories + for the cross compiling layout. + + + + See the meta/classes/binconfig.bbclass + in the + Source Directory + for details on how this class applies these additional + sed command arguments. + For general information on the + binconfig.bbclass class, see the + "Binary Configuration Scripts - binconfig.bbclass" + section. + + + + + OE_IMPORTS + + + An internal variable used to tell the OpenEmbedded build + system what Python modules to import for every Python + function run by the system. + + + + Do not set this variable. + It is for internal use only. + + + + + OE_TERMINAL + + + Controls how the OpenEmbedded build system spawns + interactive terminals on the host development system + (e.g. using the BitBake command with the + -c devshell command-line option). + For more information, see the + "Using a Development Shell" section + in the Yocto Project Development Manual. + + + + You can use the following values for the + OE_TERMINAL variable: + + auto + gnome + xfce + rxvt + screen + konsole + none + + Konsole support only works for KDE 3.x. + Also, "auto" is the default behavior for + OE_TERMINAL + + + + + OEROOT + + + The directory from which the top-level build environment + setup script is sourced. + The Yocto Project makes two top-level build environment + setup scripts available: + &OE_INIT_FILE; + and + oe-init-build-env-memres. + When you run one of these scripts, the + OEROOT variable resolves to the + directory that contains the script. + + + + For additional information on how this variable is used, + see the initialization scripts. + + + + + OLDEST_KERNEL + + + Declares the oldest version of the Linux kernel that the + produced binaries must support. + This variable is passed into the build of the Embedded + GNU C Library (eglibc). + + + + The default for this variable comes from the + meta/conf/bitbake.conf configuration + file. + You can override this default by setting the variable + in a custom distribution configuration file. + + + + + OVERRIDES + + + BitBake uses OVERRIDES to control + what variables are overridden after BitBake parses + recipes and configuration files. + You can find more information on how overrides are handled + in the BitBake Manual that is located at + bitbake/doc/manual in the + Source Directory. + + + + + + P + + P + + The recipe name and version. + P is comprised of the following: + + ${PN}-${PV} + + + + + PACKAGE_ARCH + + The architecture of the resulting package or packages. + + + + PACKAGE_BEFORE_PN + + Enables easily adding packages to + PACKAGES + before ${PN} + so that those added packages can pick up files that would normally be + included in the default package. + + + + PACKAGE_CLASSES + + + This variable, which is set in the + local.conf configuration file found in + the conf folder of the + Build Directory, + specifies the package manager the OpenEmbedded build system + uses when packaging data. + + + + You can provide one or more of the following arguments for + the variable: + + PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk package_tar" + + The build system uses only the first argument in the list + as the package manager when creating your image or SDK. + However, packages will be created using any additional + packaging classes you specify. + For example, if you use the following in your + local.conf file: + + PACKAGE_CLASSES ?= "package_ipk package_tar" + + The OpenEmbedded build system uses the IPK package manager + to create your image or SDK as well as generating + TAR packages. + + + + You cannot specify the + package_tar + class first in the list. + Files using the .tar format cannot + be used as a substitute packaging format + for DEB, RPM, and IPK formatted files for your image or SDK. + + + + For information on packaging and build performance effects + as a result of the package manager in use, see the + "package.bbclass" + section. + + + + + PACKAGE_EXCLUDE + + + Lists packages that should not be installed into an image. + For example: + + PACKAGE_EXCLUDE = "<package_name> <package_name> <package_name> ..." + + You can set this variable globally in your + local.conf file or you can attach it to + a specific image recipe by using the recipe name override: + + PACKAGE_EXCLUDE_pn-<target_image> = "<package_name>" + + + + + If you choose to not install + a package using this variable and some other package is + dependent on it (i.e. listed in a recipe's + RDEPENDS + variable), the OpenEmbedded build system generates a fatal + installation error. + Because the build system halts the process with a fatal + error, you can use the variable with an iterative + development process to remove specific components from a + system. + + + + Support for this variable exists only when using the + IPK and RPM packaging backend. + Support does not exist for DEB. + + + + See the + NO_RECOMMENDATIONS + and the + BAD_RECOMMENDATIONS + variables for related information. + + + + + PACKAGE_EXTRA_ARCHS + + Specifies the list of architectures compatible with the device CPU. + This variable is useful when you build for several different devices that use + miscellaneous processors such as XScale and ARM926-EJS). + + + + PACKAGE_GROUP + + + + The PACKAGE_GROUP variable has been + renamed to + FEATURE_PACKAGES. + See the variable description for + FEATURE_PACKAGES for information. + + + + If if you use the PACKAGE_GROUP + variable, the OpenEmbedded build system issues a warning + message. + + + + + PACKAGE_INSTALL + + + The final list of packages passed to the package manager + for installation into the image. + + + + Because the package manager controls actual installation + of all packages, the list of packages passed using + PACKAGE_INSTALL is not the final list + of packages that are actually installed. + This variable is internal to the image construction + code. + Consequently, in general, you should use the + IMAGE_INSTALL + variable to specify packages for installation. + The exception to this is when working with + the + core-image-minimal-initramfs + image. + When working with an initial RAM disk (initramfs) + image, use the PACKAGE_INSTALL + variable. + + + + + PACKAGECONFIG + + + This variable provides a means of enabling or disabling + features of a recipe on a per-recipe basis. + PACKAGECONFIG blocks are defined + in recipes when you specify features and then arguments + that define feature behaviors. + Here is the basic block structure: + + PACKAGECONFIG ??= "f1 f2 f3 ..." + PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1" + PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2" + PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3" + + The PACKAGECONFIG + variable itself specifies a space-separated list of the + features to enable. + Following the features, you can determine the behavior of + each feature by providing up to four order-dependent + arguments, which are separated by commas. + You can omit any argument you like but must retain the + separating commas. + The order is important and specifies the following: + + Extra arguments + that should be added to the configure script + argument list + (EXTRA_OECONF) + if the feature is enabled. + Extra arguments + that should be added to EXTRA_OECONF + if the feature is disabled. + + Additional build dependencies + (DEPENDS) + that should be added if the feature is enabled. + + Additional runtime dependencies + (RDEPENDS) + that should be added if the feature is enabled. + + + + + + Consider the following + PACKAGECONFIG block taken from the + librsvg recipe. + In this example the feature is croco, + which has three arguments that determine the feature's + behavior. + + PACKAGECONFIG ??= "croco" + PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco" + + The --with-croco and + libcroco arguments apply only if + the feature is enabled. + In this case, --with-croco is + added to the configure script argument list and + libcroco is added to + DEPENDS. + On the other hand, if the feature is disabled say through + a .bbappend file in another layer, then + the second argument --without-croco is + added to the configure script rather than + --with-croco. + + + + The basic PACKAGECONFIG structure + previously described holds true regardless of whether you + are creating a block or changing a block. + When creating a block, use the structure inside your + recipe. + + + + If you want to change an existing + PACKAGECONFIG block, you can do so + one of two ways: + + Append file: + Create an append file named + <recipename>.bbappend in your + layer and override the value of + PACKAGECONFIG. + You can either completely override the variable: + + PACKAGECONFIG="f4 f5" + + Or, you can just append the variable: + + PACKAGECONFIG_append = " f4" + + Configuration file: + This method is identical to changing the block + through an append file except you edit your + local.conf or + <mydistro>.conf file. + As with append files previously described, + you can either completely override the variable: + + PACKAGECONFIG_pn-<recipename>="f4 f5" + + Or, you can just amend the variable: + + PACKAGECONFIG_append_pn-<recipename> = " f4" + + + + + + + PACKAGES + + The list of packages to be created from the recipe. + The default value is the following: + + ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN} + + + + + PACKAGES_DYNAMIC + + + A promise that your recipe satisfies runtime dependencies + for optional modules that are found in other recipes. + PACKAGES_DYNAMIC + does not actually satisfy the dependencies, it only states that + they should be satisfied. + For example, if a hard, runtime dependency + (RDEPENDS) + of another package is satisfied + at build time through the PACKAGES_DYNAMIC + variable, but a package with the module name is never actually + produced, then the other package will be broken. + Thus, if you attempt to include that package in an image, + you will get a dependency failure from the packaging system + during do_rootfs. + + + Typically, if there is a chance that such a situation can + occur and the package that is not created is valid + without the dependency being satisfied, then you should use + RRECOMMENDS + (a soft runtime dependency) instead of + RDEPENDS. + + + + For an example of how to use the PACKAGES_DYNAMIC + variable when you are splitting packages, see the + "Handling Optional Module Packaging" section + in the Yocto Project Development Manual. + + + + + PARALLEL_MAKE + + + Extra options passed to the make + command during the do_compile task + in order to specify parallel compilation on the local + build host. + This variable is usually in the form "-j <x>", + where x represents the maximum number of parallel threads + make can run. + + + + If your development host supports multiple cores, a good + rule of thumb is to set this variable to twice the number + of cores on the host. + If you do not set PARALLEL_MAKE, it + defaults to the number of cores your build system has. + + Individual recipes might clear out this variable if + the software being built has problems running its + make process in parallel. + + + + + + PARALLEL_MAKEINST + + + Extra options passed to the + make install command during the + do_install task in order to specify + parallel installation. + This variable defaults to the value of + PARALLEL_MAKE. + + Individual recipes might clear out this variable if + the software being built has problems running its + make install process in parallel. + + + + + + PATCHRESOLVE + + + Determines the action to take when a patch fails. + You can set this variable to one of two values: "noop" and + "user". + + + + The default value of "noop" causes the build to simply fail + when the OpenEmbedded build system cannot successfully + apply a patch. + Setting the value to "user" causes the build system to + launch a shell and places you in the right location so that + you can manually resolve the conflicts. + + + + Set this variable in your + local.conf file. + + + + + PATCHTOOL + + + Specifies the utility used to apply patches for a recipe + during do_patch. + You can specify one of three utilities: "patch", "quilt", or + "git". + The default utility used is "quilt" except for the + quilt-native recipe itself. + Because the quilt tool is not available at the + time quilt-native is being patched, it uses "patch". + + + + If you wish to use an alternative patching tool, set the + variable in the recipe using one of the following: + + PATCHTOOL = "patch" + PATCHTOOL = "quilt" + PATCHTOOL = "git" + + + + + + PE + + + The epoch of the recipe. + By default, this variable is unset. + The variable is used to make upgrades possible when the + versioning scheme changes in some backwards incompatible + way. + + + + + PF + + Specifies the recipe or package name and includes all version and revision + numbers (i.e. eglibc-2.13-r20+svnr15508/ and + bash-4.2-r1/). + This variable is comprised of the following: + + ${PN}-${EXTENDPE}${PV}-${PR} + + + + + PIXBUF_PACKAGES + + + When a recipe inherits the + pixbufcache + class, this variable identifies packages that contain + the pixbuf loaders used with + gdk-pixbuf. + By default, the pixbufcache class + assumes that the loaders are in the recipe's main package + (i.e. ${PN}). + Use this variable if the loaders you need are in a package + other than that main package. + + + + + PKG + + + The name of the resulting package created by the + OpenEmbedded build system. + + When using the PKG variable, you + must use a package name override. + + For example, when the + debian + class renames the output package, it does so by setting + PKG_<packagename>. + + + + + PKGD + + + Points to the destination directory for files to be + packaged before they are split into individual packages. + This directory defaults to the following: + + ${WORKDIR}/package + + Do not change this default. + + + + + PKGDATA_DIR + + + Points to a shared, global-state directory that holds data + generated during the packaging process. + During the packaging process, the + do_packagedata task packages + data for each recipe and installs it into this temporary, + shared area. + This directory defaults to the following: + + ${STAGING_DIR_HOST}/pkgdata + + Do not change this default. + + + + + PKGDEST + + + Points to the parent directory for files to be packaged + after they have been split into individual packages. + This directory defaults to the following: + + ${WORKDIR}/packages-split + + Under this directory, the build system creates + directories for each package specified in + PACKAGES. + Do not change this default. + + + + + PKGDESTWORK + + + Points to a temporary work area used by the + do_package task to write output + from the do_packagedata task. + The PKGDESTWORK location defaults to + the following: + + ${WORKDIR}/pkgdata + + The do_packagedata task then packages + the data in the temporary work area and installs it into a + shared directory pointed to by + PKGDATA_DIR. + + + + Do not change this default. + + + + + PKGE + + + The epoch of the output package built by the + OpenEmbedded build system. + By default, PKGE is set to + PE. + + + + + PKGR + + + The revision of the output package built by the + OpenEmbedded build system. + By default, PKGR is set to + PR. + + + + + PKGV + + + The version of the output package built by the + OpenEmbedded build system. + By default, PKGV is set to + PV. + + + + + PN + + This variable can have two separate functions depending on the context: a recipe + name or a resulting package name. + PN refers to a recipe name in the context of a file used + by the OpenEmbedded build system as input to create a package. + The name is normally extracted from the recipe file name. + For example, if the recipe is named + expat_2.0.1.bb, then the default value of PN + will be "expat". + + The variable refers to a package name in the context of a file created or produced by the + OpenEmbedded build system. + If applicable, the PN variable also contains any special + suffix or prefix. + For example, using bash to build packages for the native + machine, PN is bash-native. + Using bash to build packages for the target and for Multilib, + PN would be bash and + lib64-bash, respectively. + + + + + PNBLACKLIST + + + Lists recipes you do not want the OpenEmbedded build system + to build. + This variable works in conjunction with the + blacklist + class, which the recipe must inherit globally. + + + + To prevent a recipe from being built, inherit the class + globally and use the variable in your + local.conf file. + Here is an example that prevents + myrecipe from being built: + + INHERIT += "blacklist" + PNBLACKLIST[myrecipe] = "Not supported by our organization." + + + + + + PR + + + The revision of the recipe. + The default value for this variable is "r0". + + + + + PREFERRED_PROVIDER + + + If multiple recipes provide an item, this variable + determines which recipe should be given preference. + You should always suffix the variable with the name of the + provided item, and you should set it to the + PN + of the recipe to which you want to give precedence. + Some examples: + + PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" + PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" + PREFERRED_PROVIDER_virtual/libgl ?= "mesa" + + + + + + PREFERRED_VERSION + + + If there are multiple versions of recipes available, this + variable determines which recipe should be given preference. + You must always suffix the variable with the + PN + you want to select, and you should set the + PV + accordingly for precedence. + You can use the "%" character as a + wildcard to match any number of characters, which can be + useful when specifying versions that contain long revision + numbers that could potentially change. + Here are two examples: + + PREFERRED_VERSION_python = "2.7.3" + PREFERRED_VERSION_linux-yocto = "3.10%" + + + + + + PREMIRRORS + + + Specifies additional paths from which the OpenEmbedded + build system gets source code. + When the build system searches for source code, it first + tries the local download directory. + If that location fails, the build system tries locations + defined by PREMIRRORS, the upstream + source, and then locations specified by + MIRRORS + in that order. + + + + Assuming your distribution + (DISTRO) + is "poky", the default value for + PREMIRRORS is defined in the + conf/distro/poky.conf file in the + meta-yocto Git repository. + + + + Typically, you could add a specific server for the + build system to attempt before any others by adding + something like the following to the + local.conf configuration file in the + Build Directory: + + PREMIRRORS_prepend = "\ + git://.*/.* http://www.yoctoproject.org/sources/ \n \ + ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ + http://.*/.* http://www.yoctoproject.org/sources/ \n \ + https://.*/.* http://www.yoctoproject.org/sources/ \n" + + These changes cause the build system to intercept + Git, FTP, HTTP, and HTTPS requests and direct them to + the http:// sources mirror. + You can use file:// URLs to point + to local directories or network shares as well. + + + + + PRINC + + + + The PRINC variable has been deprecated + and triggers a warning if detected during a build. + For + PR + increments on changes, use the PR service instead. + You can find out more about this service in the + "Working With a PR Service" + section in the Yocto Project Development Manual. + + + + + + PROVIDES + + + A list of aliases that a recipe also provides. + These aliases are useful for satisfying dependencies of + other recipes during the build (as specified by + DEPENDS). + + A recipe's own + PN + is implicitly already in its + PROVIDES list. + + + + + + PRSERV_HOST + + + The network based + PR + service host and port. + + + + The conf/local.conf.sample.extended + configuration file in the + Source Directory + shows how the PRSERV_HOST variable is + set: + + PRSERV_HOST = "localhost:0" + + You must set the variable if you want to automatically + start a local + PR service. + You can set PRSERV_HOST to other + values to use a remote PR service. + + + + + PV + + + The version of the recipe. + The version is normally extracted from the recipe filename. + For example, if the recipe is named + expat_2.0.1.bb, then the default value of PV + will be "2.0.1". + PV is generally not overridden within + a recipe unless it is building an unstable (i.e. development) version from a source code repository + (e.g. Git or Subversion). + + + + + PYTHON_ABI + + + When used by recipes that inherit the + distutils3, + setuptools3, + distutils, + or + setuptools + classes, denotes the Application Binary Interface (ABI) + currently in use for Python. + By default, the ABI is "m". + You do not have to set this variable as the OpenEmbedded + build system sets it for you. + + + + The OpenEmbedded build system uses the ABI to construct + directory names used when installing the Python headers + and libraries in sysroot + (e.g. .../python3.3m/...). + + + + Recipes that inherit the + distutils + class during cross-builds also use this variable to + locate the headers and libraries of the appropriate Python + that the extension is targeting. + + + + + PYTHON_PN + + + When used by recipes that inherit the + distutils3, + setuptools3, + distutils, + or + setuptools + classes, specifies the major Python version being built. + For Python 2.x, PYTHON_PN would + be "python2". For Python 3.x, the variable would be + "python3". + You do not have to set this variable as the + OpenEmbedded build system automatically sets it for you. + + + + The variable allows recipes to use common infrastructure + such as the following: + + DEPENDS += "${PYTHON_PN}-native" + + In the previous example, the version of the dependency + is PYTHON_PN. + + + + + + + Q + + QMAKE_PROFILES + + + Specifies your own subset of .pro + files to be built for use with + qmake. + If you do not set this variable, all + .pro files in the directory pointed to + by S + will be built by default. + + + + This variable is used with recipes that inherit the + qmake_base + class or other classes that inherit + qmake_base. + + + + + + + R + + RCONFLICTS + + + The list of packages that conflict with packages. + Note that packages will not be installed if conflicting + packages are not first removed. + + + + Like all package-controlling variables, you must always use + them in conjunction with a package name override. + Here is an example: + + RCONFLICTS_${PN} = "another-conflicting-package-name" + + + + + BitBake, which the OpenEmbedded build system uses, supports + specifying versioned dependencies. + Although the syntax varies depending on the packaging + format, BitBake hides these differences from you. + Here is the general syntax to specify versions with + the RCONFLICTS variable: + + RCONFLICTS_${PN} = "<package> (<operator> <version>)" + + For operator, you can specify the + following: + + = + < + > + <= + >= + + For example, the following sets up a dependency on version + 1.2 or greater of the package foo: + + RCONFLICTS_${PN} = "foo (>= 1.2)" + + + + + + RDEPENDS + + + Lists a package's runtime dependencies (i.e. other packages) + that must be installed in order for the built package to run + correctly. + If a package in this list cannot be found during the build, + you will get a build error. + + + + When you use the RDEPENDS variable + in a recipe, you are essentially stating that the recipe's + do_build task depends on the existence + of a specific package. + Consider this simple example for two recipes named "a" and + "b" that produce similarly named IPK packages. + In this example, the RDEPENDS + statement appears in the "a" recipe: + + RDEPENDS_${PN} = "b" + + Here, the dependency is such that the + do_build task for recipe "a" depends + on the do_package_write_ipk task + of recipe "b". + This means the package file for "b" must be available when + the output for recipe "a" has been completely built. + More importantly, package "a" will be marked as depending + on package "b" in a manner that is understood by the + package manager. + + + + The names of the packages you list within + RDEPENDS must be the names of other + packages - they cannot be recipe names. + Although package names and recipe names usually match, + the important point here is that you are + providing package names within the + RDEPENDS variable. + For an example of the default list of packages created from + a recipe, see the + PACKAGES + variable. + + + + Because the RDEPENDS variable applies + to packages being built, you should always use the variable + in a form with an attached package name. + For example, suppose you are building a development package + that depends on the perl package. + In this case, you would use the following + RDEPENDS statement: + + RDEPENDS_${PN}-dev += "perl" + + In the example, the development package depends on + the perl package. + Thus, the RDEPENDS variable has the + ${PN}-dev package name as part of the + variable. + + + + The package name you attach to the + RDEPENDS variable must appear + as it would in the PACKAGES + namespace before any renaming of the output package by + classes like debian.bbclass. + + + + In many cases you do not need to explicitly add + runtime dependencies using + RDEPENDS since some automatic + handling occurs: + + shlibdeps: If + a runtime package contains a shared library + (.so), the build + processes the library in order to determine other + libraries to which it is dynamically linked. + The build process adds these libraries to + RDEPENDS when creating the runtime + package. + pcdeps: If + the package ships a pkg-config + information file, the build process uses this file + to add items to the RDEPENDS + variable to create the runtime packages. + + + + + + BitBake, which the OpenEmbedded build system uses, supports + specifying versioned dependencies. + Although the syntax varies depending on the packaging + format, BitBake hides these differences from you. + Here is the general syntax to specify versions with + the RDEPENDS variable: + + RDEPENDS_${PN} = "<package> (<operator> <version>)" + + For operator, you can specify the + following: + + = + < + > + <= + >= + + For example, the following sets up a dependency on version + 1.2 or greater of the package foo: + + RDEPENDS_${PN} = "foo (>= 1.2)" + + + + + For information on build-time dependencies, see the + DEPENDS + variable. + + + + + REQUIRED_DISTRO_FEATURES + + + When a recipe inherits the + distro_features_check class, this + variable identifies distribution features that must + exist in the current configuration in order for the + OpenEmbedded build system to build the recipe. + In other words, if the + REQUIRED_DISTRO_FEATURES variable + lists a feature that does not appear in + DISTRO_FEATURES within the + current configuration, an error occurs and the + build stops. + + + + + RM_OLD_IMAGE + + + Reclaims disk space by removing previously built + versions of the same image from the + images directory pointed to by the + DEPLOY_DIR + variable. + + + + Set this variable to "1" in your + local.conf file to remove these + images. + + + + + RM_WORK_EXCLUDE + + + With rm_work enabled, this + variable specifies a list of recipes whose work directories + should not be removed. + See the "rm_work.bbclass" + section for more details. + + + + + ROOT_HOME + + + Defines the root home directory. + By default, this directory is set as follows in the + BitBake configuration file: + + ROOT_HOME ??= "/home/root" + + + This default value is likely used because some + embedded solutions prefer to have a read-only root + filesystem and prefer to keep writeable data in one + place. + + + + + You can override the default by setting the variable + in any layer or in the local.conf file. + Because the default is set using a "weak" assignment + (i.e. "??="), you can use either of the following forms + to define your override: + + ROOT_HOME = "/root" + ROOT_HOME ?= "/root" + + These override examples use /root, + which is probably the most commonly used override. + + + + + ROOTFS + + + Indicates a filesystem image to include as the root + filesystem. + + + + The ROOTFS variable is an optional + variable used with the + buildimg + class. + + + + + ROOTFS_POSTPROCESS_COMMAND + + + Added by classes to run post processing commands once the + OpenEmbedded build system has created the root filesystem. + You can specify shell commands separated by semicolons: + + ROOTFS_POSTPROCESS_COMMAND += "<shell_command>; ... " + + If you need to pass the path to the root filesystem within + the command, you can use + ${IMAGE_ROOTFS}, which points to + the root filesystem image. + + + + + RPROVIDES + + + A list of package name aliases that a package also provides. + These aliases are useful for satisfying runtime dependencies + of other packages both during the build and on the target + (as specified by + RDEPENDS). + + A package's own name is implicitly already in its + RPROVIDES list. + + + + As with all package-controlling variables, you must always + use the variable in conjunction with a package name override. + Here is an example: + + RPROVIDES_${PN} = "widget-abi-2" + + + + + + RRECOMMENDS + + + A list of packages that extends the usability of a package + being built. + The package being built does not depend on this list of + packages in order to successfully build, but needs them for + the extended usability. + To specify runtime dependencies for packages, see the + RDEPENDS + variable. + + + + The OpenEmbedded build process automatically installs the + list of packages as part of the built package. + However, you can remove these packages later if you want. + If, during the build, a package from the + RRECOMMENDS list cannot be + found, the build process continues without an error. + + + + You can also prevent packages in the list from being + installed by using several variables. + See the + BAD_RECOMMENDATIONS, + NO_RECOMMENDATIONS, + and + PACKAGE_EXCLUDE + variables for more information. + + + + Because the RRECOMMENDS variable + applies to packages being built, you should always attach + an override to the variable to specify the particular + package whose usability is being extended. + For example, suppose you are building a development package + that is extended to support wireless functionality. + In this case, you would use the following: + + RRECOMMENDS_${PN}-dev += "<wireless_package_name>" + + In the example, the package name + (${PN}-dev) + must appear as it would in the + PACKAGES + namespace before any renaming of the output package by + classes such as debian.bbclass. + + + + BitBake, which the OpenEmbedded build system uses, supports + specifying versioned recommends. + Although the syntax varies depending on the packaging + format, BitBake hides these differences from you. + Here is the general syntax to specify versions with + the RRECOMMENDS variable: + + RRECOMMENDS_${PN} = "<package> (<operator> <version>)" + + For operator, you can specify the + following: + + = + < + > + <= + >= + + For example, the following sets up a recommend on version + 1.2 or greater of the package foo: + + RRECOMMENDS_${PN} = "foo (>= 1.2)" + + + + + + RREPLACES + + + A list of packages replaced by a package. + The package manager uses this variable to determine which + package should be installed to replace other package(s) + during an upgrade. + In order to also have the other package(s) removed at the + same time, you must add the name of the other + package to the + RCONFLICTS variable. + + + As with all package-controlling variables, you must use + this variable in conjunction with a package name + override. + Here is an example: + + RREPLACES_${PN} = "other-package-being-replaced" + + + + + BitBake, which the OpenEmbedded build system uses, supports + specifying versioned replacements. + Although the syntax varies depending on the packaging + format, BitBake hides these differences from you. + Here is the general syntax to specify versions with + the RREPLACES variable: + + RREPLACES_${PN} = "<package> (<operator> <version>)" + + For operator, you can specify the + following: + + = + < + > + <= + >= + + For example, the following sets up a replacement using + version 1.2 or greater of the package + foo: + + RREPLACES_${PN} = "foo (>= 1.2)" + + + + + + RSUGGESTS + + + A list of additional packages that you can suggest for + installation by the package manager at the time a package + is installed. + Not all package managers support this functionality. + + + As with all package-controlling variables, you must always + use this variable in conjunction with a package name + override. + Here is an example: + + RSUGGESTS_${PN} = "useful-package another-package" + + + + + + + + S + + S + + + The location in the + Build Directory + where unpacked recipe source code resides. + This location is within the work directory + (WORKDIR), + which is not static. + The unpacked source location depends on the recipe name + (PN) and + recipe version + (PV) as + follows: + + ${WORKDIR}/${PN}-${PV} + + As an example, assume a + Source Directory + top-level folder named poky and a + default Build Directory at poky/build. + In this case, the work directory the build system uses + to keep the unpacked recipe for db + is the following: + + poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19 + + + + + + SANITY_TESTED_DISTROS + + + A list of the host distribution identifiers that the + build system has been tested against. + Identifiers consist of the host distributor ID + followed by the release, + as reported by the lsb_release tool + or as read from /etc/lsb-release. + Separate the list items with explicit newline + characters (\n). + If SANITY_TESTED_DISTROS is not empty + and the current value of + NATIVELSBSTRING + does not appear in the list, then the build system reports + a warning that indicates the current host distribution has + not been tested as a build host. + + + + + SDK_ARCH + + + The target architecture for the SDK. + Typically, you do not directly set this variable. + Instead, use + SDKMACHINE. + + + + + SDK_DEPLOY + + + The directory set up and used by the + populate_sdk_base + to which the SDK is deployed. + The populate_sdk_base class defines + SDK_DEPLOY as follows: + + SDK_DEPLOY = "${TMPDIR}/deploy/sdk" + + + + + + SDK_DIR + + + The parent directory used by the OpenEmbedded build system + when creating SDK output. + The + populate_sdk_base + class defines the variable as follows: + + SDK_DIR = "${WORKDIR}/sdk" + + + The SDK_DIR directory is a + temporary directory as it is part of + WORKDIR. + The final output directory is + SDK_DEPLOY. + + + + + + SDK_NAME + + + The base name for SDK output files. + The name is derived from the + DISTRO, + TCLIBC, + SDK_ARCH, + IMAGE_BASENAME, + and + TUNE_PKGARCH + variables: + + SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}" + + + + + + SDK_OUTPUT + + + The location used by the OpenEmbedded build system when + creating SDK output. + The + populate_sdk_base + class defines the variable as follows: + + SDK_OUTPUT = "${SDK_DIR}/image" + + + The SDK_OUTPUT directory is a + temporary directory as it is part of + WORKDIR by way of + SDK_DIR. + The final output directory is + SDK_DEPLOY. + + + + + + + SDKIMAGE_FEATURES + + Equivalent to + IMAGE_FEATURES. + However, this variable applies to the SDK generated from an + image using the following command: + + $ bitbake -c populate_sdk imagename + + + + + + SDKMACHINE + + + The architecture of the machine that runs Application + Development Toolkit (ADT) items. + In other words, packages are built so that they will run + on the target you specify with the argument. + This implies that you can build out ADT/SDK items that + run on an architecture other than that of your build host. + For example, you can use an x86_64-based build host to + create packages that will run on an i686-based + SDK Machine. + + + + You can use "i686" and "x86_64" as possible values for this + variable. + The variable defaults to "i686" and is set in the + local.conf file in the + Build Directory. + + SDKMACHINE ?= "i686" + + + You cannot set the SDKMACHINE + variable in your distribution configuration file. + If you do, the configuration will not take affect. + + + + + + SDKPATH + + + Defines the path offered to the user for installation + of the SDK that is generated by the OpenEmbedded build + system. + The path appears as the default location for installing + the SDK when you run the SDK's installation script. + You can override the offered path when you run the + script. + + + + + SECTION + + The section in which packages should be categorized. + Package management utilities can make use of this variable. + + + + SELECTED_OPTIMIZATION + + + The variable takes the value of + FULL_OPTIMIZATION + unless DEBUG_BUILD = "1". + In this case the value of + DEBUG_OPTIMIZATION is used. + + + + + SERIAL_CONSOLE + + + Defines a serial console (TTY) to enable using getty. + Provide a value that specifies the baud rate followed by + the TTY device name separated by a space. + You cannot specify more than one TTY device: + + SERIAL_CONSOLE = "115200 ttyS0" + + + The SERIAL_CONSOLE variable + is deprecated. + Please use the + SERIAL_CONSOLES + variable. + + + + + + SERIAL_CONSOLES + + + Defines the serial consoles (TTYs) to enable using getty. + Provide a value that specifies the baud rate followed by + the TTY device name separated by a semicolon. + Use spaces to separate multiple devices: + + SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1" + + + + + + SERIAL_CONSOLES_CHECK + + + Similar to + SERIAL_CONSOLES + except the device is checked for existence before attempting + to enable it. + This variable is currently only supported with SysVinit + (i.e. not with systemd). + + + + + SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS + + + A list of recipe dependencies that should not be used to + determine signatures of tasks from one recipe when they + depend on tasks from another recipe. + For example: + + SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2" + + In this example, intone depends on + mplayer2. + + + + Use of this variable is one mechanism to remove dependencies + that affect task signatures and thus force rebuilds when a + recipe changes. + Caution + If you add an inappropriate dependency for a recipe + relationship, the software might break during + runtime if the interface of the second recipe was + changed after the first recipe had been built. + + + + + + SIGGEN_EXCLUDERECIPES_ABISAFE + + + A list of recipes that are completely stable and will + never change. + The ABI for the recipes in the list are presented by + output from the tasks run to build the recipe. + Use of this variable is one way to remove dependencies from + one recipe on another that affect task signatures and + thus force rebuilds when the recipe changes. + Caution + If you add an inappropriate variable to this list, + the software might break at runtime if the + interface of the recipe was changed after the other + had been built. + + + + + + SITEINFO_BITS + + + Specifies the number of bits for the target system CPU. + The value should be either "32" or "64". + + + + + SITEINFO_ENDIANNESS + + + Specifies the endian byte order of the target system. + The value should be either "le" for little-endian or "be" for big-endian. + + + + + SOC_FAMILY + + + Groups together machines based upon the same family + of SOC (System On Chip). + You typically set this variable in a common + .inc file that you include in the + configuration files of all the machines. + + You must include + conf/machine/include/soc-family.inc + for this variable to appear in + MACHINEOVERRIDES. + + + + + + SOLIBS + + + Defines the suffix for shared libraries used on the + target platform. + By default, this suffix is ".so.*" for all Linux-based + systems and is defined in the + meta/conf/bitbake.conf configuration + file. + + + + You will see this variable referenced in the default values + of FILES_${PN}. + + + + + SOLIBSDEV + + + Defines the suffix for the development symbolic link + (symlink) for shared libraries on the target platform. + By default, this suffix is ".so" for Linux-based + systems and is defined in the + meta/conf/bitbake.conf configuration + file. + + + + You will see this variable referenced in the default values + of FILES_${PN}-dev. + + + + + SOURCE_MIRROR_URL + + + Defines your own + PREMIRRORS + from which to first fetch source before attempting to fetch + from the upstream specified in + SRC_URI. + + + + To use this variable, you must globally inherit the + own-mirrors + class and then provide the URL to your mirrors. + 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. + + + + + + SPDXLICENSEMAP + + + Maps commonly used license names to their SPDX counterparts + found in meta/files/common-licenses/. + For the default SPDXLICENSEMAP + mappings, see the + meta/conf/licenses.conf file. + + + + For additional information, see the + LICENSE + variable. + + + + + SPECIAL_PKGSUFFIX + + + A list of prefixes for PN used by the + OpenEmbedded build system to create variants of recipes or packages. + The list specifies the prefixes to strip off during certain circumstances + such as the generation of the BPN variable. + + + + + SRC_URI + + The list of source files - local or remote. + This variable tells the OpenEmbedded build system which bits + to pull in for the build and how to pull them in. + For example, if the recipe or append file only needs to + fetch a tarball from the Internet, the recipe or + append file uses a single SRC_URI + entry. + On the other hand, if the recipe or append file needs to + fetch a tarball, apply two patches, and include a custom + file, the recipe or append file would include four + instances of the variable. + The following list explains the available URI protocols: + + file:// - + Fetches files, which are usually files shipped with + the + Metadata, + from the local machine. + The path is relative to the + FILESPATH + variable. + Thus, the build system searches, in order, from the + following directories, which are assumed to be a + subdirectories of the directory in which the + recipe file (.bb) or + append file (.bbappend) + resides: + + ${BPN} - + The base recipe name without any special + suffix or version numbers. + + ${BP} - + ${BPN}-${PV}. + The base recipe name and version but without + any special package name suffix. + + files - + Files within a directory, which is named + files and is also + alongside the recipe or append file. + + + + If you want the build system to pick up files + specified through a + SRC_URI + statement from your append file, you need to be + sure to extend the + FILESPATH + variable by also using the + FILESEXTRAPATHS + variable from within your append file. + + + bzr:// - Fetches files from a + Bazaar revision control repository. + git:// - Fetches files from a + Git revision control repository. + osc:// - Fetches files from + an OSC (OpenSUSE Build service) revision control repository. + repo:// - Fetches files from + a repo (Git) repository. + svk:// - Fetches files from + an SVK revision control repository. + http:// - Fetches files from + the Internet using http. + https:// - Fetches files + from the Internet using https. + ftp:// - Fetches files + from the Internet using ftp. + cvs:// - Fetches files from + a CVS revision control repository. + hg:// - Fetches files from + a Mercurial (hg) revision control repository. + p4:// - Fetches files from + a Perforce (p4) revision control repository. + ssh:// - Fetches files from + a secure shell. + svn:// - Fetches files from + a Subversion (svn) revision control repository. + + + Standard and recipe-specific options for SRC_URI exist. + Here are standard options: + + apply - Whether to apply + the patch or not. + The default action is to apply the patch. + striplevel - Which + striplevel to use when applying the patch. + The default level is 1. + patchdir - Specifies + the directory in which the patch should be applied. + The default is ${S}. + + + + Here are options specific to recipes building code from a revision control system: + + mindate - + Apply the patch only if + SRCDATE + is equal to or greater than mindate. + + maxdate - + Apply the patch only if SRCDATE + is not later than mindate. + + minrev - + Apply the patch only if SRCREV + is equal to or greater than minrev. + + maxrev - + Apply the patch only if SRCREV + is not later than maxrev. + + rev - + Apply the patch only if SRCREV + is equal to rev. + + notrev - + Apply the patch only if SRCREV + is not equal to rev. + + + + Here are some additional options worth mentioning: + + unpack - Controls + whether or not to unpack the file if it is an archive. + The default action is to unpack the file. + subdir - Places the file + (or extracts its contents) into the specified + subdirectory of WORKDIR. + This option is useful for unusual tarballs or other archives that + do not have their files already in a subdirectory within the archive. + + name - Specifies a + name to be used for association with SRC_URI checksums + when you have more than one file specified in SRC_URI. + + downloadfilename - Specifies + the filename used when storing the downloaded file. + + + + + + SRC_URI_OVERRIDES_PACKAGE_ARCH + + + + By default, the OpenEmbedded build system automatically detects whether + SRC_URI + contains files that are machine-specific. + If so, the build system automatically changes + PACKAGE_ARCH. + Setting this variable to "0" disables this behavior. + + + + + SRCDATE + + + The date of the source code used to build the package. + This variable applies only if the source was fetched from a Source Code Manager (SCM). + + + + + SRCPV + + + Returns the version string of the current package. + This string is used to help define the value of + PV. + + + + The SRCPV variable is defined in the + meta/conf/bitbake.conf configuration + file in the + Source Directory + as follows: + + SRCPV = "${@bb.fetch2.get_srcrev(d)}" + + + + + Recipes that need to define PV do so + with the help of the SRCPV. + For example, the ofono recipe + (ofono_git.bb) located in + meta/recipes-connectivity in the + Source Directory defines PV as + follows: + + PV = "0.12-git${SRCPV}" + + + + + + SRCREV + + + The revision of the source code used to build the package. + This variable applies to Subversion, Git, Mercurial and Bazaar + only. + Note that if you wish to build a fixed revision and you wish + to avoid performing a query on the remote repository every time + BitBake parses your recipe, you should specify a SRCREV that is a + full revision identifier and not just a tag. + + + + + SSTATE_DIR + + The directory for the shared state cache. + + + + SSTATE_MIRRORS + + + Configures the OpenEmbedded build system to search other + mirror locations for prebuilt cache data objects before + building out the data. + This variable works like fetcher + MIRRORS + and PREMIRRORS + and points to the cache locations to check for the shared + objects. + + + + You can specify a filesystem directory or a remote URL such + as HTTP or FTP. + The locations you specify need to contain the shared state + cache (sstate-cache) results from previous builds. + The sstate-cache you point to can also be from builds on + other machines. + + + + If a mirror uses the same structure as + SSTATE_DIR, + you need to add + "PATH" at the end as shown in the examples below. + The build system substitutes the correct path within the + directory structure. + + SSTATE_MIRRORS ?= "\ + file://.* http://someserver.tld/share/sstate/PATH \n \ + file://.* file:///some/local/dir/sstate/PATH" + + + + + + STAGING_KERNEL_DIR + + + The directory with kernel headers that are required to build out-of-tree + modules. + + + + + STAMP + + + Specifies the base path used to create recipe stamp files. + The path to an actual stamp file is constructed by evaluating this + string and then appending additional information. + Currently, the default assignment for STAMP + as set in the meta/conf/bitbake.conf file + is: + + STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}" + + See STAMPS_DIR, + MULTIMACH_TARGET_SYS, + PN, + EXTENDPE, + PV, and + PR for related variable + information. + + + + + STAMPS_DIR + + + Specifies the base directory in which the OpenEmbedded + build system places stamps. + The default directory is + ${TMPDIR}/stamps. + + + + + SUMMARY + + The short (72 characters or less) summary of the binary package for packaging + systems such as opkg, rpm or + dpkg. + By default, SUMMARY is used to define + the DESCRIPTION + variable if DESCRIPTION is not set + in the recipe. + + + + + SYSLINUX_DEFAULT_CONSOLE + + + Specifies the kernel boot default console. + If you want to use a console other than the default, + set this variable in your recipe as follows where "X" is + the console number you want to use: + + SYSLINUX_DEFAULT_CONSOLE = "console=ttyX" + + + + + The + syslinux + class initially sets this variable to null but then checks + for a value later. + + + + + SYSLINUX_OPTS + + + Lists additional options to add to the syslinux file. + You need to set this variable in your recipe. + If you want to list multiple options, separate the options + with a semicolon character (;). + + + + The + syslinux + class uses this variable to create a set of options. + + + + + SYSLINUX_SERIAL + + + Specifies the alternate serial port or turns it off. + To turn off serial, set this variable to an empty string + in your recipe. + The variable's default value is set in the + syslinux + as follows: + + SYSLINUX_SERIAL ?= "0 115200" + + The class checks for and uses the variable as needed. + + + + SYSLINUX_SPLASH + + + An .LSS file used as the background + for the VGA boot menu when you are using the boot menu. + You need to set this variable in your recipe. + + + + The + syslinux + class checks for this variable and if found, the + OpenEmbedded build system installs the splash screen. + + + + + SYSLINUX_SERIAL_TTY + + + Specifies the alternate console=tty... kernel boot argument. + The variable's default value is set in the + syslinux + as follows: + + SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200" + + The class checks for and uses the variable as needed. + + + + + SYSROOT_PREPROCESS_FUNCS + + + A list of functions to execute after files are staged into + the sysroot. + These functions are usually used to apply additional + processing on the staged files, or to stage additional + files. + + + + + SYSTEMD_AUTO_ENABLE + + + For recipes that inherit the + systemd + class, this variable specifies whether the service you have + specified in + SYSTEMD_SERVICE + should be started automatically or not. + By default, the service is enabled to automatically start + at boot time. + The default setting is in the + systemd + class as follows: + + SYSTEMD_AUTO_ENABLE ??= "enable" + + You can disable the service by setting the variable to + "disable". + + + + + SYSTEMD_PACKAGES + + + For recipes that inherit the + systemd + class, this variable locates the systemd unit files when + they are not found in the main recipe's package. + By default, the + SYSTEMD_PACKAGES variable is set + such that the systemd unit files are assumed to reside in + the recipes main package: + + SYSTEMD_PACKAGES ?= "${PN}" + + If these unit files are not in this recipe's main + package, you need to use + SYSTEMD_PACKAGES to list the package + or packages in which the build system can find the systemd + unit files. + + + + + SYSTEMD_SERVICE + + + For recipes that inherit the + systemd + class, this variable specifies the systemd service name for + a package. + + + + When you specify this file in your recipe, use a package + name override to indicate the package to which the value + applies. + Here is an example from the connman recipe: + + SYSTEMD_SERVICE_${PN} = "connman.service" + + + + + + + + T + + T + + This variable points to a directory were BitBake places + temporary files, which consist mostly of task logs and + scripts, when building a particular recipe. + The variable is typically set as follows: + + T = "${WORKDIR}/temp" + + The WORKDIR + is the directory into which BitBake unpacks and builds the + recipe. + The default bitbake.conf file sets this variable. + The T variable is not to be confused with + the TMPDIR variable, + which points to the root of the directory tree where BitBake + places the output of an entire build. + + + + + TARGET_ARCH + + + The target machine's architecture. + The OpenEmbedded build system supports many + architectures. + Here is an example list of architectures supported. + This list is by no means complete as the architecture + is configurable: + + arm + i586 + x86_64 + powerpc + powerpc64 + mips + mipsel + + + + + + TARGET_CFLAGS + + + Flags passed to the C compiler for the target system. + This variable evaluates to the same as + CFLAGS. + + + + + + TARGET_FPU + + Specifies the method for handling FPU code. + For FPU-less targets, which include most ARM CPUs, the variable must be + set to "soft". + If not, the kernel emulation gets used, which results in a performance penalty. + + + + TARGET_OS + + Specifies the target's operating system. + The variable can be set to "linux" for eglibc-based systems and + to "linux-uclibc" for uclibc. + For ARM/EABI targets, there are also "linux-gnueabi" and + "linux-uclibc-gnueabi" values possible. + + + + TCLIBC + + + Specifies the GNU standard C library (libc) + variant to use during the build process. + This variable replaces POKYLIBC, which is no longer + supported. + + + You can select "eglibc" or "uclibc". + + This release of the Yocto Project does not support the + glibc implementation of libc. + + + + + + TCMODE + + + Specifies the toolchain selector. + TCMODE controls the characteristics + of the generated packages and images by telling the + OpenEmbedded build system which toolchain profile to use. + By default, the OpenEmbedded build system builds its own + internal toolchain. + The variable's default value is "default", which uses + that internal toolchain. + + If TCMODE is set to a value + other than "default", then it is your responsibility + to ensure that the toolchain is compatible with the + default toolchain. + Using older or newer versions of these components + might cause build problems. + See the + Release Notes + for the specific components with which the toolchain + must be compatible. + + + + + With additional layers, it is possible to use a pre-compiled + external toolchain. + One example is the Sourcery G++ Toolchain. + The support for this toolchain resides in the separate + meta-sourcery layer at + . + You can use meta-sourcery as a + template for adding support for other external toolchains. + + + + The TCMODE variable points the build + system to a file in + conf/distro/include/tcmode-${TCMODE}.inc. + Thus, for meta-sourcery, + which has conf/distro/include/tcmode-external-sourcery.inc, + you would set the variable as follows: + + TCMODE ?= "external-sourcery" + + + + + The variable is similar to + TCLIBC, + which controls the variant of the GNU standard C library + (libc) used during the build process: + eglibc or uclibc. + + + + + TEST_EXPORT_DIR + + + The location the OpenEmbedded build system uses to export + tests when the + TEST_EXPORT_ONLY + variable is set to "1". + + + + The TEST_EXPORT_DIR variable defaults + to "${TMPDIR}/testimage/${PN}". + + + + + TEST_EXPORT_ONLY + + + Specifies to export the tests only. + Set this variable to "1" if you do not want to run the + tests but you want them to be exported in a manner that + you to run them outside of the build system. + + + + + TEST_IMAGE + + + Automatically runs the series of automated tests for + images when an image is successfully built. + + + + These tests are written in Python making use of the + unittest module, and the majority of + them run commands on the target system over + ssh. + You can set this variable to "1" in your + local.conf file in the + Build Directory + to have the OpenEmbedded build system automatically run + these tests after an image successfully builds: + + TEST_IMAGE = "1" + + For more information on enabling, running, and writing + these tests, see the + "Performing Automated Runtime Testing" + section in the Yocto Project Development Manual and the + "testimage.bbclass" + section. + + + + + TEST_LOG_DIR + + + Holds the SSH log and the boot log for QEMU machines. + The TEST_LOG_DIR variable defaults + to "${WORKDIR}/testimage". + + Actual test results reside in the task log + (log.do_testimage), which is in + the ${WORKDIR}/temp/ directory. + + + + + + TEST_QEMUBOOT_TIMEOUT + + + The time in seconds allowed for an image to boot before + automated runtime tests begin to run against an + image. + The default timeout period to allow the boot process to + reach the login prompt is 500 seconds. + You can specify a different value in the + local.conf file. + + + + For more information on testing images, see the + "Performing Automated Runtime Testing" + section in the Yocto Project Development Manual. + + + + + TEST_SERVER_IP + + + The IP address of the build machine (host machine). + This IP address is usually automatically detected. + However, if detection fails, this variable needs to be set + to the IP address of the build machine (i.e. where + the build is taking place). + + The TEST_SERVER_IP variable + is only used for a small number of tests such as + the "smart" test suite, which needs to download + packages from DEPLOY_DIR/rpm. + + + + + + TEST_TARGET + + + Specifies the target controller to use when running tests + against a test image. + The default controller to use is "qemu": + + TEST_TARGET = "qemu" + + A target controller is a class that defines how an + image gets deployed on a target and how a target is started. + A layer can extend the controllers by adding a module + in the layer's /lib/oeqa/controllers + directory and by inheriting the + BaseTarget class, which is an abstract + class that cannot be used as a value of + TEST_TARGET. + + + + You can provide the following arguments with + TEST_TARGET: + + "qemu" and "QemuTarget": + Boots a QEMU image and runs the tests. + See the + "Enabling Runtime Tests on QEMU" + section in the Yocto Project Development Manual for + more information. + + "simpleremote" and "SimpleRemoteTarget": + Runs the tests on target hardware that is already + up and running. + The hardware can be on the network or it can be + a device running an image on QEMU. + You must also set + TEST_TARGET_IP + when you use "simpleremote" or "SimpleRemoteTarget". + + This argument is defined in + meta/lib/oeqa/targetcontrol.py. + The small caps names are kept for compatibility + reasons. + + + "GummibootTarget": + Automatically deploys and runs tests on an + EFI-enabled machine that has a master image + installed. + + This argument is defined in + meta/lib/oeqa/controllers/masterimage.py. + + + + + + + For information on running tests on hardware, see the + "Enabling Runtime Tests on Hardware" + section in the Yocto Project Development Manual. + + + + + TEST_TARGET_IP + + + The IP address of your hardware under test. + The TEST_TARGET_IP variable has no + effect when + TEST_TARGET + is set to "qemu". + + + + When you specify the IP address, you can also include a + port. + Here is an example: + + TEST_TARGET_IP = "192.168.1.4:2201" + + Specifying a port is useful when SSH is started on a + non-standard port or in cases when your hardware under test + is behind a firewall or network that is not directly + accessible from your host and you need to do port address + translation. + + + + + TEST_SUITES + + + An ordered list of tests (modules) to run against + an image when performing automated runtime testing. + + + + The OpenEmbedded build system provides a core set of tests + that can be used against images. + + Currently, there is only support for running these tests + under QEMU. + + Tests include ping, + ssh, df among + others. + You can add your own tests to the list of tests by + appending TEST_SUITES as follows: + + TEST_SUITES_append = " mytest" + + Alternatively, you can provide the "auto" option to + have all applicable tests run against the image. + + TEST_SUITES_append = " auto" + + Using this option causes the build system to automatically + run tests that are applicable to the image. + Tests that are not applicable are skipped. + + + + The order in which tests are run is important. + Tests that depend on another test must appear later in the + list than the test on which they depend. + For example, if you append the list of tests with two + tests (test_A and + test_B) where + test_B is dependent on + test_A, then you must order the tests + as follows: + + TEST_SUITES = " test_A test_B" + + + + + For more information on testing images, see the + "Performing Automated Runtime Testing" + section in the Yocto Project Development Manual. + + + + + THISDIR + + + The directory in which the file BitBake is currently + parsing is located. + Do not manually set this variable. + + + + + TMPDIR + + + This variable is the base directory the OpenEmbedded + build system uses for all build output and intermediate + files (other than the shared state cache). + By default, the TMPDIR variable points + to tmp within the + Build Directory. + + + + If you want to establish this directory in a location other + than the default, you can uncomment and edit the following + statement in the + conf/local.conf file in the + Source Directory: + + #TMPDIR = "${TOPDIR}/tmp" + + An example use for this scenario is to set + TMPDIR to a local disk, which does + not use NFS, while having the Build Directory use NFS. + + + + The filesystem used by TMPDIR must + have standard filesystem semantics (i.e. mixed-case files + are unique, POSIX file locking, and persistent inodes). + Due to various issues with NFS and bugs in some + implementations, NFS does not meet this minimum + requirement. + Consequently, TMPDIR cannot be on + NFS. + + + + + TOOLCHAIN_HOST_TASK + + + This variable lists packages the OpenEmbedded build system + uses when building an SDK, which contains a + cross-development environment. + The packages specified by this variable are part of the + toolchain set that runs on the + SDKMACHINE, + and each package should usually have the prefix + "nativesdk-". + When building an SDK using + bitbake -c populate_sdk <imagename>, + a default list of packages is set in this variable, but + you can add additional packages to the list. + + + + For background information on cross-development toolchains + in the Yocto Project development environment, see the + "Cross-Development Toolchain Generation" + section. + For information on setting up a cross-development + environment, see the + "Installing the ADT and Toolchains" + section in the Yocto Project Application Developer's Guide. + + + + + TOOLCHAIN_TARGET_TASK + + + This variable lists packages the OpenEmbedded build system + uses when it creates the target part of an SDK + (i.e. the part built for the target hardware), which + includes libraries and headers. + + + + For background information on cross-development toolchains + in the Yocto Project development environment, see the + "Cross-Development Toolchain Generation" + section. + For information on setting up a cross-development + environment, see the + "Installing the ADT and Toolchains" + section in the Yocto Project Application Developer's Guide. + + + + + TOPDIR + + + The top-level + Build Directory. + BitBake automatically sets this variable when you + initialize your build environment using either + &OE_INIT_FILE; + or + oe-init-build-env-memres. + + + + + TRANSLATED_TARGET_ARCH + + + A sanitized version of + TARGET_ARCH. + This variable is used where the architecture is needed in + a value where underscores are not allowed, for example + within package filenames. + In this case, dash characters replace any underscore + characters used in TARGET_ARCH. + + + + Do not edit this variable. + + + + + TUNE_PKGARCH + + + The package architecture understood by the packaging + system to define the architecture, ABI, and tuning of + output packages. + + + + + + + U + + UBOOT_CONFIG + + + Configures the + UBOOT_MACHINE + and can also define + IMAGE_FSTYPES + for individual cases. + + + + Following is an example from the + meta-fsl-arm layer. + + UBOOT_CONFIG ??= "sd" + UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard" + UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config" + UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs" + UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config" + + In this example, "sd" is selected as the configuration + of the possible four for the + UBOOT_MACHINE. + The "sd" configuration defines "mx6qsabreauto_config" + as the value for UBOOT_MACHINE, while + the "sdcard" specifies the + IMAGE_FSTYPES to use for the U-boot + image. + + + + For more information on how the + UBOOT_CONFIG is handled, see the + uboot-config + class. + + + + + UBOOT_ENTRYPOINT + + + Specifies the entry point for the U-Boot image. + During U-Boot image creation, the + UBOOT_ENTRYPOINT variable is passed + as a command-line parameter to the + uboot-mkimage utility. + + + + + UBOOT_LOADADDRESS + + + Specifies the load address for the U-Boot image. + During U-Boot image creation, the + UBOOT_LOADADDRESS variable is passed + as a command-line parameter to the + uboot-mkimage utility. + + + + + UBOOT_LOCALVERSION + + + Appends a string to the name of the local version of the + U-Boot image. + For example, assuming the version of the U-Boot image + built was "2013.10, the full version string reported by + U-Boot would be "2013.10-yocto" given the following + statement: + + UBOOT_LOCALVERSION = "-yocto" + + + + + + UBOOT_MACHINE + + + Specifies the value passed on the + make command line when building + a U-Boot image. + The value indicates the target platform configuration. + You typically set this variable from the machine + configuration file (i.e. + conf/machine/<machine_name>.conf). + + + + + UBOOT_MAKE_TARGET + + + Specifies the target called in the + Makefile. + The default target is "all". + + + + + UBOOT_SUFFIX + + + Points to the generated U-Boot extension. + For example, u-boot.sb has a + .sb extension. + + + + The default U-Boot extension is + .bin + + + + + UBOOT_TARGET + + + Specifies the target used for building U-Boot. + The target is passed directly as part of the "make" command + (e.g. SPL and AIS). + If you do not specifically set this variable, the + OpenEmbedded build process passes and uses "all" for the + target during the U-Boot building process. + + + + + USER_CLASSES + + + A list of classes to globally inherit. + These classes are used by the OpenEmbedded build system + to enable extra features (e.g. + buildstats, + image-mklibs, and so forth). + + + + The default list is set in your + local.conf file: + + USER_CLASSES ?= "buildstats image-mklibs image-prelink" + + For more information, see + meta-yocto/conf/local.conf.sample in + the + Source Directory. + + + + + USERADD_ERROR_DYNAMIC + + + Forces the OpenEmbedded build system to produce an error + if the user identification (uid) and + group identification (gid) values + are not defined in files/passwd + and files/group files. + + + + The default behavior for the build system is to dynamically + apply uid and + gid values. + Consequently, the USERADD_ERROR_DYNAMIC + variable is by default not set. + If you plan on using statically assigned + gid and uid + values, you should set + the USERADD_ERROR_DYNAMIC variable in + your local.conf file as + follows: + + USERADD_ERROR_DYNAMIC = "1" + + Overriding the default behavior implies you are going to + also take steps to set static uid and + gid values through use of the + USERADDEXTENSION, + USERADD_UID_TABLES, + and + USERADD_GID_TABLES + variables. + + + + + USERADD_GID_TABLES + + + Specifies a password file to use for obtaining static + group identification (gid) values + when the OpenEmbedded build system adds a group to the + system during package installation. + + + + When applying static group identification + (gid) values, the OpenEmbedded build + system looks in + BBPATH + for a files/group file and then applies + those uid values. + Set the variable as follows in your + local.conf file: + + USERADD_GID_TABLES = "files/group" + + + + + Setting the + USERADDEXTENSION + variable to "useradd-staticids" causes the build system + to use static gid values. + + + + + USERADD_UID_TABLES + + + Specifies a password file to use for obtaining static + user identification (uid) values + when the OpenEmbedded build system adds a user to the + system during package installation. + + + + When applying static user identification + (uid) values, the OpenEmbedded build + system looks in + BBPATH + for a files/passwd file and then applies + those uid values. + Set the variable as follows in your + local.conf file: + + USERADD_UID_TABLES = "files/passwd" + + + + + Setting the + USERADDEXTENSION + variable to "useradd-staticids" causes the build system + to use static uid values. + + + + + USERADD_PACKAGES + + + When a recipe inherits the + useradd class, this variable + specifies the individual packages within the recipe that + require users and/or groups to be added. + + + + You must set this variable if the recipe inherits the + class. + For example, the following enables adding a user for the + main package in a recipe: + + USERADD_PACKAGES = "${PN}" + + + If follows that if you are going to use the + USERADD_PACKAGES variable, + you need to set one or more of the + USERADD_PARAM, + GROUPADD_PARAM, + or + GROUPMEMS_PARAM + variables. + + + + + + + USERADD_PARAM + + + When a recipe inherits the + useradd class, this variable + specifies for a package what parameters should be passed + to the useradd command + if you wish to add a user to the system when the package + is installed. + + + + Here is an example from the dbus + recipe: + + USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \ + --no-create-home --shell /bin/false \ + --user-group messagebus" + + For information on the standard Linux shell command + useradd, see + . + + + + + USERADDEXTENSION + + + When set to "useradd-staticids", causes the + OpenEmbedded build system to base all user and group + additions on a static + passwd and + group files found in + BBPATH. + + + + To use static user identification (uid) + and group identification (gid) + values, set the variable + as follows in your local.conf file: + + USERADDEXTENSION = "useradd-staticids" + + + Setting this variable to use static + uid and gid + values causes the OpenEmbedded build system to employ + the + useradd-staticids + class. + + + + + If you use static uid and + gid information, you must also + specify the files/passwd and + files/group files by setting the + USERADD_UID_TABLES + and + USERADD_GID_TABLES + variables. + Additionally, you should also set the + USERADD_ERROR_DYNAMIC + variable. + + + + + + + + + + W + + WARN_QA + + + Specifies the quality assurance checks whose failures are + reported as warnings by the OpenEmbedded build system. + You set this variable in your distribution configuration + file. + For a list of the checks you can control with this variable, + see the + "insane.bbclass" + section. + + + + + WORKDIR + + + The pathname of the work directory in which the OpenEmbedded + build system builds a recipe. + This directory is located within the + TMPDIR + directory structure and is specific to the recipe being + built and the system for which it is being built. + + + + The WORKDIR directory is defined as + follows: + + ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} + + The actual directory depends on several things: + + TMPDIR: + The top-level build output directory + MULTIMACH_TARGET_SYS: + The target system identifier + PN: + The recipe name + EXTENDPE: + The epoch - (if + PE + is not specified, which is usually the case for most + recipes, then EXTENDPE is blank) + PV: + The recipe version + PR: + The recipe revision + + + + + As an example, assume a Source Directory top-level folder + name poky, a default Build Directory at + poky/build, and a + qemux86-poky-linux machine target + system. + Furthermore, suppose your recipe is named + foo_1.3.0-r0.bb. + In this case, the work directory the build system uses to + build the package would be as follows: + + poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0 + + + + + + + + + + + + + + + + + + + -- cgit v1.2.3-54-g00ecf