Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / openbmc / 475cb72d2bb2f40ca5e9f4edba6d49d6c7afbd3e / . / poky / documentation / ref-manual / ref-variables.xml
blob: 9fe744aff5309fa793d9011d9e48440ff3e90859 [file] [log] [blame]
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<!-- Dummy chapter -->
<chapter id='ref-variables-glos'>
<title>Variables Glossary</title>
<para>
This chapter lists common variables used in the OpenEmbedded build system and gives an overview
of their function and contents.
</para>
<glossary id='ref-variables-glossary'>
<para>
<link linkend='var-ABIEXTENSION'>A</link>
<link linkend='var-B'>B</link>
<link linkend='var-CACHE'>C</link>
<link linkend='var-D'>D</link>
<link linkend='var-EFI_PROVIDER'>E</link>
<link linkend='var-FEATURE_PACKAGES'>F</link>
<link linkend='var-GCCPIE'>G</link>
<link linkend='var-HOMEPAGE'>H</link>
<link linkend='var-ICECC_DISABLED'>I</link>
<!-- <link linkend='var-glossary-j'>J</link> -->
<link linkend='var-KARCH'>K</link>
<link linkend='var-LABELS'>L</link>
<link linkend='var-MACHINE'>M</link>
<link linkend='var-NATIVELSBSTRING'>N</link>
<link linkend='var-OBJCOPY'>O</link>
<link linkend='var-P'>P</link>
<!-- <link linkend='var-glossary-q'>Q</link> -->
<link linkend='var-RANLIB'>R</link>
<link linkend='var-S'>S</link>
<link linkend='var-T'>T</link>
<link linkend='var-UBOOT_CONFIG'>U</link>
<link linkend='var-VOLATILE_LOG_DIR'>V</link>
<link linkend='var-WARN_QA'>W</link>
<link linkend='var-XSERVER'>X</link>
<!-- <link linkend='var-glossary-y'>Y</link> -->
<!-- <link linkend='var-glossary-z'>Z</link>-->
</para>
<glossdiv id='var-glossary-a'><title>A</title>
<glossentry id='var-ABIEXTENSION'><glossterm>ABIEXTENSION</glossterm>
<info>
ABIEXTENSION[doc] = "Extension to the Application Binary Interface (ABI) field of the GNU canonical architecture name (e.g. "eabi")."
</info>
<glossdef>
<para role="glossdeffirst">
Extension to the Application Binary Interface (ABI)
field of the GNU canonical architecture name
(e.g. "eabi").
</para>
<para>
ABI extensions are set in the machine include files.
For example, the
<filename>meta/conf/machine/include/arm/arch-arm.inc</filename>
file sets the following extension:
<literallayout class='monospaced'>
ABIEXTENSION = "eabi"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-ALLOW_EMPTY'><glossterm>ALLOW_EMPTY</glossterm>
<info>
ALLOW_EMPTY[doc] = "Specifies whether to produce an output package even if it is empty."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies whether to produce an output package even if it is
empty.
By default, BitBake does not produce empty packages.
This default behavior can cause issues when there is an
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> or
some other hard runtime requirement on the existence of the package.
</para>
<para>
Like all package-controlling variables, you must always use them in
conjunction with a package name override, as in:
<literallayout class='monospaced'>
ALLOW_EMPTY_${PN} = "1"
ALLOW_EMPTY_${PN}-dev = "1"
ALLOW_EMPTY_${PN}-staticdev = "1"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-ALTERNATIVE'><glossterm>ALTERNATIVE</glossterm>
<info>
ALTERNATIVE[doc] = "Lists commands in a package that need an alternative binary naming scheme."
</info>
<glossdef>
<para role="glossdeffirst">
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.
</para>
<para>
To use the variable, list out the package's commands
that also exist as part of another package.
For example, if the <filename>busybox</filename> package
has four commands that also exist as part of another
package, you identify them as follows:
<literallayout class='monospaced'>
ALTERNATIVE_busybox = "sh sed test bracket"
</literallayout>
For more information on the alternatives system, see the
"<link linkend='ref-classes-update-alternatives'><filename>update-alternatives.bbclass</filename></link>"
section.
</para>
</glossdef>
</glossentry>
<glossentry id='var-ALTERNATIVE_LINK_NAME'><glossterm>ALTERNATIVE_LINK_NAME</glossterm>
<info>
ALTERNATIVE_LINK_NAME[doc] = "Used by the alternatives system to map duplicated commands to actual locations."
</info>
<glossdef>
<para role="glossdeffirst">
Used by the alternatives system to map duplicated commands
to actual locations.
For example, if the <filename>bracket</filename> command
provided by the <filename>busybox</filename> package is
duplicated through another package, you must use the
<filename>ALTERNATIVE_LINK_NAME</filename> variable to
specify the actual location:
<literallayout class='monospaced'>
ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
</literallayout>
</para>
<para>
In this example, the binary for the
<filename>bracket</filename> command (i.e.
<filename>[</filename>) from the
<filename>busybox</filename> package resides in
<filename>/usr/bin/</filename>.
<note>
If <filename>ALTERNATIVE_LINK_NAME</filename> is not
defined, it defaults to
<filename>${bindir}/<replaceable>name</replaceable></filename>.
</note>
</para>
<para>
For more information on the alternatives system, see the
"<link linkend='ref-classes-update-alternatives'><filename>update-alternatives.bbclass</filename></link>"
section.
</para>
</glossdef>
</glossentry>
<glossentry id='var-ALTERNATIVE_PRIORITY'><glossterm>ALTERNATIVE_PRIORITY</glossterm>
<info>
ALTERNATIVE_PRIORITY[doc] = "Used by the alternatives system to create default priorities for duplicated commands."
</info>
<glossdef>
<para role="glossdeffirst">
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:
<literallayout class='monospaced'>
ALTERNATIVE_PRIORITY = "<replaceable>priority</replaceable>"
ALTERNATIVE_PRIORITY[<replaceable>name</replaceable>] = "<replaceable>priority</replaceable>"
ALTERNATIVE_PRIORITY_<replaceable>pkg</replaceable>[<replaceable>name</replaceable>] = "<replaceable>priority</replaceable>"
</literallayout>
</para>
<para>
For more information on the alternatives system, see the
"<link linkend='ref-classes-update-alternatives'><filename>update-alternatives.bbclass</filename></link>"
section.
</para>
</glossdef>
</glossentry>
<glossentry id='var-ALTERNATIVE_TARGET'><glossterm>ALTERNATIVE_TARGET</glossterm>
<info>
ALTERNATIVE_TARGET[doc] = "Used by the alternatives system to create default link locations for duplicated commands."
</info>
<glossdef>
<para role="glossdeffirst">
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:
<literallayout class='monospaced'>
ALTERNATIVE_TARGET = "<replaceable>target</replaceable>"
ALTERNATIVE_TARGET[<replaceable>name</replaceable>] = "<replaceable>target</replaceable>"
ALTERNATIVE_TARGET_<replaceable>pkg</replaceable>[<replaceable>name</replaceable>] = "<replaceable>target</replaceable>"
</literallayout>
<note>
<para>
If <filename>ALTERNATIVE_TARGET</filename> is not
defined, it inherits the value from the
<link linkend='var-ALTERNATIVE_LINK_NAME'><filename>ALTERNATIVE_LINK_NAME</filename></link>
variable.
</para>
<para>
If <filename>ALTERNATIVE_LINK_NAME</filename> and
<filename>ALTERNATIVE_TARGET</filename> are the
same, the target for
<filename>ALTERNATIVE_TARGET</filename>
has "<filename>.{BPN}</filename>" appended to it.
</para>
<para>
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
<link linkend='ref-tasks-install'><filename>do_install</filename></link>
task while
retaining support for the command if necessary.
</para>
</note>
</para>
<para>
For more information on the alternatives system, see the
"<link linkend='ref-classes-update-alternatives'><filename>update-alternatives.bbclass</filename></link>"
section.
</para>
</glossdef>
</glossentry>
<glossentry id='var-APPEND'><glossterm>APPEND</glossterm>
<info>
APPEND[doc] = "An override list of append strings for target specified using LABELS."
</info>
<glossdef>
<para role="glossdeffirst">
An override list of append strings for each target
specified with
<link linkend='var-LABELS'><filename>LABELS</filename></link>.
</para>
<para>
See the
<link linkend='ref-classes-grub-efi'><filename>grub-efi</filename></link>
class for more information on how this variable is used.
</para>
</glossdef>
</glossentry>
<glossentry id='var-AR'><glossterm>AR</glossterm>
<info>
AR[doc] = "Minimal command and arguments to run 'ar'."
</info>
<glossdef>
<para role="glossdeffirst">
The minimal command and arguments used to run
<filename>ar</filename>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-ARCHIVER_MODE'><glossterm>ARCHIVER_MODE</glossterm>
<info>
ARCHIVER_MODE[doc] = "Controls archive creation used when releasing source files."
</info>
<glossdef>
<para role="glossdeffirst">
When used with the
<link linkend='ref-classes-archiver'><filename>archiver</filename></link>
class, determines the type of information used to create
a released archive.
You can use this variable to create archives of patched
source, original source, configured source, and so forth
by employing the following variable flags (varflags):
<literallayout class='monospaced'>
ARCHIVER_MODE[src] = "original" # Uses original (unpacked) source
# files.
ARCHIVER_MODE[src] = "patched" # Uses patched source files. This is
# the default.
ARCHIVER_MODE[src] = "configured" # Uses configured source files.
ARCHIVER_MODE[diff] = "1" # Uses patches between do_unpack and
# do_patch.
ARCHIVER_MODE[diff-exclude] ?= "<replaceable>file</replaceable> <replaceable>file</replaceable> ..." # Lists files and directories to
# exclude from diff.
ARCHIVER_MODE[dumpdata] = "1" # Uses environment data.
ARCHIVER_MODE[recipe] = "1" # Uses recipe and include files.
ARCHIVER_MODE[srpm] = "1" # Uses RPM package files.
</literallayout>
For information on how the variable works, see the
<filename>meta/classes/archiver.bbclass</filename> file
in the
<link linkend='source-directory'>Source Directory</link>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-AS'><glossterm>AS</glossterm>
<info>
AS[doc] = "Minimal command and arguments to run the assembler."
</info>
<glossdef>
<para role="glossdeffirst">
Minimal command and arguments needed to run the
assembler.
</para>
</glossdef>
</glossentry>
<glossentry id='var-ASSUME_PROVIDED'><glossterm>ASSUME_PROVIDED</glossterm>
<info>
ASSUME_PROVIDED[doc] = "Lists recipe names (PN values) BitBake does not attempt to build."
</info>
<glossdef>
<para role="glossdeffirst">
Lists recipe names
(<link linkend='var-PN'><filename>PN</filename></link>
values) BitBake does not attempt to build.
Instead, BitBake assumes these recipes have already been
built.
</para>
<para>
In OpenEmbedded-Core, <filename>ASSUME_PROVIDED</filename>
mostly specifies native tools that should not be built.
An example is <filename>git-native</filename>, which when
specified, allows for the Git binary from the host to be
used rather than building <filename>git-native</filename>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-ASSUME_SHLIBS'><glossterm>ASSUME_SHLIBS</glossterm>
<info>
ASSUME_SHLIBS[doc] = "Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system."
</info>
<glossdef>
<para role="glossdeffirst">
Provides additional <filename>shlibs</filename> provider
mapping information, which adds to or overwrites the
information provided automatically by the system.
Separate multiple entries using spaces.
</para>
<para>
As an example, use the following form to add an
<filename>shlib</filename> provider of
<replaceable>shlibname</replaceable> in
<replaceable>packagename</replaceable> with the optional
<replaceable>version</replaceable>:
<literallayout class='monospaced'>
<replaceable>shlibname:packagename</replaceable>[_<replaceable>version</replaceable>]
</literallayout>
</para>
<para>
Here is an example that adds a shared library named
<filename>libEGL.so.1</filename> as being provided by
the <filename>libegl-implementation</filename> package:
<literallayout class='monospaced'>
ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-AUTHOR'><glossterm>AUTHOR</glossterm>
<info>
AUTHOR[doc] = "Email address used to contact the original author or authors in order to send patches and forward bugs."
</info>
<glossdef>
<para role="glossdeffirst">
The email address used to contact the original author
or authors in order to send patches and forward bugs.
</para>
</glossdef>
</glossentry>
<glossentry id='var-AUTO_LIBNAME_PKGS'><glossterm>AUTO_LIBNAME_PKGS</glossterm>
<info>
AUTO_LIBNAME_PKGS[doc] = "Specifies which packages should be checked for libraries and renamed according to Debian library package naming."
</info>
<glossdef>
<para role="glossdeffirst">
When the
<link linkend='ref-classes-debian'><filename>debian</filename></link>
class is inherited, which is the default behavior,
<filename>AUTO_LIBNAME_PKGS</filename> specifies which
packages should be checked for libraries and renamed
according to Debian library package naming.
</para>
<para>
The default value is "${PACKAGES}", which causes the
debian class to act on all packages that are
explicitly generated by the recipe.
</para>
</glossdef>
</glossentry>
<glossentry id='var-AUTO_SYSLINUXMENU'><glossterm>AUTO_SYSLINUXMENU</glossterm>
<info>
AUTO_SYSLINUXMENU[doc] = "Enables creating an automatic menu for the syslinux bootloader."
</info>
<glossdef>
<para role="glossdeffirst">
Enables creating an automatic menu for the syslinux
bootloader.
You must set this variable in your recipe.
The
<link linkend='ref-classes-syslinux'><filename>syslinux</filename></link>
class checks this variable.
</para>
</glossdef>
</glossentry>
<glossentry id='var-AUTOREV'><glossterm>AUTOREV</glossterm>
<info>
AUTOREV[doc] = "When SRCREV is set to the value of this variable, it specifies to use the latest source revision in the repository."
</info>
<glossdef>
<para role="glossdeffirst">
When
<filename><link linkend='var-SRCREV'>SRCREV</link></filename>
is set to the value of this variable, it specifies to use
the latest source revision in the repository.
Here is an example:
<literallayout class='monospaced'>
SRCREV = "${AUTOREV}"
</literallayout>
</para>
<para>
If you use the previous statement to retrieve the latest
version of software, you need to be sure
<link linkend='var-PV'><filename>PV</filename></link>
contains
<filename>${</filename><link linkend='var-SRCPV'><filename>SRCPV</filename></link><filename>}</filename>.
For example, suppose you have a kernel recipe that
inherits the
<link linkend='ref-classes-kernel'>kernel</link> class
and you use the previous statement.
In this example, <filename>${SRCPV}</filename> does not
automatically get into <filename>PV</filename>.
Consequently, you need to change <filename>PV</filename>
in your recipe so that it does contain
<filename>${SRCPV}</filename>.
</para>
<para>
For more information see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number'>Automatically Incrementing a Binary Package Revision Number</ulink>"
section in the Yocto Project Development Tasks Manual.
</para>
</glossdef>
</glossentry>
<glossentry id='var-AVAILABLE_LICENSES'><glossterm>AVAILABLE_LICENSES</glossterm>
<info>
AVAILABLE_LICENSES[doc] = "List of licenses found in the directories specified by COMMON_LICENSE_DIR and LICENSE_PATH."
</info>
<glossdef>
<para role="glossdeffirst">
List of licenses found in the directories specified
by <link linkend='var-COMMON_LICENSE_DIR'><filename>COMMON_LICENSE_DIR</filename></link>
and <link linkend='var-LICENSE_PATH'><filename>LICENSE_PATH</filename></link>.
<note>
It is assumed that all changes
to <filename>COMMON_LICENSE_DIR</filename>
and <filename>LICENSE_PATH</filename> have been done
before <filename>AVAILABLE_LICENSES</filename> is
defined
(in <link linkend='ref-classes-license'>license.bbclass</link>).
</note>
</para>
</glossdef>
</glossentry>
<glossentry id='var-AVAILTUNES'><glossterm>AVAILTUNES</glossterm>
<info>
AVAILTUNES[doc] = "The list of defined CPU and Application Binary Interface (ABI) tunings (i.e. "tunes") available for use by the OpenEmbedded build system."
</info>
<glossdef>
<para role="glossdeffirst">
The list of defined CPU and Application Binary Interface
(ABI) tunings (i.e. "tunes") available for use by the
OpenEmbedded build system.
</para>
<para>
The list simply presents the tunes that are available.
Not all tunes may be compatible with a particular
machine configuration, or with each other in a
<ulink url='&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image'>Multilib</ulink>
configuration.
</para>
<para>
To add a tune to the list, be sure to append it with
spaces using the "+=" BitBake operator.
Do not simply replace the list by using the "=" operator.
See the
"<ulink url='&YOCTO_DOCS_BB_URL;#basic-syntax'>Basic Syntax</ulink>"
section in the BitBake User Manual for more information.
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-b'><title>B</title>
<glossentry id='var-B'><glossterm>B</glossterm>
<info>
B[doc] = "The Build Directory. The OpenEmbedded build system places generated objects into the Build Directory during a recipe's build process."
</info>
<glossdef>
<para role="glossdeffirst">
The directory within the
<link linkend='build-directory'>Build Directory</link>
in which the OpenEmbedded build system places generated
objects during a recipe's build process.
By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
directory, which is defined as:
<literallayout class='monospaced'>
S = "${WORKDIR}/${BP}"
</literallayout>
</para>
<para>
You can separate the (<filename>S</filename>) directory
and the directory pointed to by the <filename>B</filename>
variable.
Most Autotools-based recipes support separating these
directories.
The build system defaults to using separate directories for
<filename>gcc</filename> and some kernel recipes.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BAD_RECOMMENDATIONS'><glossterm>BAD_RECOMMENDATIONS</glossterm>
<info>
BAD_RECOMMENDATIONS[doc] = "A list of packages not to install despite being recommended by a recipe. Support for this variable exists only when using the IPK packaging backend."
</info>
<glossdef>
<para role="glossdeffirst">
Lists "recommended-only" packages to not install.
Recommended-only packages are packages installed only
through the
<link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
variable.
You can prevent any of these "recommended" packages from
being installed by listing them with the
<filename>BAD_RECOMMENDATIONS</filename> variable:
<literallayout class='monospaced'>
BAD_RECOMMENDATIONS = "<replaceable>package_name</replaceable> <replaceable>package_name</replaceable> <replaceable>package_name</replaceable> ..."
</literallayout>
</para>
<para>
You can set this variable globally in your
<filename>local.conf</filename> file or you can attach it to
a specific image recipe by using the recipe name override:
<literallayout class='monospaced'>
BAD_RECOMMENDATIONS_pn-<replaceable>target_image</replaceable> = "<replaceable>package_name</replaceable>"
</literallayout>
</para>
<para>
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
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
variable), the OpenEmbedded build system ignores your
request and will install the packages to avoid dependency
errors.
</para>
<para>
Support for this variable exists only when using the
IPK and RPM packaging backend.
Support does not exist for DEB.
</para>
<para>
See the
<link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link>
and the
<link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>
variables for related information.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BASE_LIB'><glossterm>BASE_LIB</glossterm>
<info>
BASE_LIB[doc] = "The library directory name for the CPU or Application Binary Interface (ABI) tune."
</info>
<glossdef>
<para role="glossdeffirst">
The library directory name for the CPU or Application
Binary Interface (ABI) tune.
The <filename>BASE_LIB</filename> applies only in the
Multilib context.
See the
"<ulink url='&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image'>Combining Multiple Versions of Library Files into One Image</ulink>"
section in the Yocto Project Development Tasks Manual for
information on Multilib.
</para>
<para>
The <filename>BASE_LIB</filename> variable is defined in
the machine include files in the
<link linkend='source-directory'>Source Directory</link>.
If Multilib is not being used, the value defaults to "lib".
</para>
</glossdef>
</glossentry>
<glossentry id='var-BASE_WORKDIR'><glossterm>BASE_WORKDIR</glossterm>
<info>
BASE_WORKDIR[doc] = "Points to the base of the work directory for all recipes."
</info>
<glossdef>
<para role="glossdeffirst">
Points to the base of the work directory for all recipes.
The default value is "${TMPDIR}/work".
</para>
</glossdef>
</glossentry>
<glossentry id='var-BB_ALLOWED_NETWORKS'><glossterm>BB_ALLOWED_NETWORKS</glossterm>
<info>
BB_ALLOWED_NETWORKS[doc] = "A list of hosts that the fetcher is allowed to use to obtain the required source code."
</info>
<glossdef>
<para>
Specifies a space-delimited list of hosts that the fetcher
is allowed to use to obtain the required source code.
Following are considerations surrounding this variable:
<itemizedlist>
<listitem><para>
This host list is only used if
<filename>BB_NO_NETWORK</filename> is either not
set or set to "0".
</para></listitem>
<listitem><para>
Limited support for wildcard matching against the
beginning of host names exists.
For example, the following setting matches
<filename>git.gnu.org</filename>,
<filename>ftp.gnu.org</filename>, and
<filename>foo.git.gnu.org</filename>.
<literallayout class='monospaced'>
BB_ALLOWED_NETWORKS = "*.gnu.org"
</literallayout>
<note><title>Important</title>
<para>The use of the "<filename>*</filename>"
character only works at the beginning of
a host name and it must be isolated from
the remainder of the host name.
You cannot use the wildcard character in any
other location of the name or combined with
the front part of the name.</para>
<para>For example,
<filename>*.foo.bar</filename> is supported,
while <filename>*aa.foo.bar</filename> is not.
</para>
</note>
</para></listitem>
<listitem><para>
Mirrors not in the host list are skipped and
logged in debug.
</para></listitem>
<listitem><para>
Attempts to access networks not in the host list
cause a failure.
</para></listitem>
</itemizedlist>
Using <filename>BB_ALLOWED_NETWORKS</filename> in
conjunction with
<link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
is very useful.
Adding the host you want to use to
<filename>PREMIRRORS</filename> results in the source code
being fetched from an allowed location and avoids raising
an error when a host that is not allowed is in a
<link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
statement.
This is because the fetcher does not attempt to use the
host listed in <filename>SRC_URI</filename> after a
successful fetch from the
<filename>PREMIRRORS</filename> occurs.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BB_DANGLINGAPPENDS_WARNONLY'><glossterm>BB_DANGLINGAPPENDS_WARNONLY</glossterm>
<info>
BB_DANGLINGAPPENDS_WARNONLY[doc] = "Defines how BitBake handles situations where an append file (.bbappend) has no corresponding recipe file (.bb)."
</info>
<glossdef>
<para role="glossdeffirst">
Defines how BitBake handles situations where an append
file (<filename>.bbappend</filename>) has no
corresponding recipe file (<filename>.bb</filename>).
This condition often occurs when layers get out of sync
(e.g. <filename>oe-core</filename> 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).
</para>
<para>
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.
</para>
<para>
You can change the default behavior by setting this
variable to "1", "yes", or "true"
in your <filename>local.conf</filename> file, which is
located in the
<link linkend='build-directory'>Build Directory</link>:
Here is an example:
<literallayout class='monospaced'>
BB_DANGLINGAPPENDS_WARNONLY = "1"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BB_DISKMON_DIRS'><glossterm>BB_DISKMON_DIRS</glossterm>
<info>
BB_DISKMON_DIRS[doc] = "Monitors disk space and available inodes during the build and allows you to control the build based on these parameters."
</info>
<glossdef>
<para role="glossdeffirst">
Monitors disk space and available inodes during the build
and allows you to control the build based on these
parameters.
</para>
<para>
Disk space monitoring is disabled by default.
To enable monitoring, add the <filename>BB_DISKMON_DIRS</filename>
variable to your <filename>conf/local.conf</filename> file found in the
<link linkend='build-directory'>Build Directory</link>.
Use the following form:
<literallayout class='monospaced'>
BB_DISKMON_DIRS = "<replaceable>action</replaceable>,<replaceable>dir</replaceable>,<replaceable>threshold</replaceable> [...]"
where:
<replaceable>action</replaceable> 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.
<replaceable>dir</replaceable> 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.
<replaceable>threshold</replaceable> 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.
</literallayout>
</para>
<para>
Here are some examples:
<literallayout class='monospaced'>
BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
</literallayout>
The first example works only if you also provide
the <link linkend='var-BB_DISKMON_WARNINTERVAL'><filename>BB_DISKMON_WARNINTERVAL</filename></link> variable
in the <filename>conf/local.conf</filename>.
This example causes the build system to immediately
abort when either the disk space in <filename>${TMPDIR}</filename> 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
<filename>${SSTATE_DIR}</filename> 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 <filename>BB_DISKMON_WARNINTERVAL</filename>
variable.
</para>
<para>
The second example stops the build after all currently
executing tasks complete when the minimum disk space
in the <filename>${<link linkend='var-TMPDIR'>TMPDIR</link>}</filename>
directory drops below 1 Gbyte.
No disk monitoring occurs for the free inodes in this case.
</para>
<para>
The final example immediately aborts the build when the
number of free inodes in the <filename>${TMPDIR}</filename> directory
drops below 100 Kbytes.
No disk space monitoring for the directory itself occurs
in this case.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BB_DISKMON_WARNINTERVAL'><glossterm>BB_DISKMON_WARNINTERVAL</glossterm>
<info>
BB_DISKMON_WARNINTERVAL[doc] = "Defines the disk space and free inode warning intervals. To set these intervals, define the variable in the conf/local.conf file in the Build Directory."
</info>
<glossdef>
<para role="glossdeffirst">
Defines the disk space and free inode warning intervals.
To set these intervals, define the variable in your
<filename>conf/local.conf</filename> file in the
<link linkend='build-directory'>Build Directory</link>.
</para>
<para>
If you are going to use the
<filename>BB_DISKMON_WARNINTERVAL</filename> variable, you must
also use the
<link linkend='var-BB_DISKMON_DIRS'><filename>BB_DISKMON_DIRS</filename></link> 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.
</para>
<para>
If you do not provide a <filename>BB_DISKMON_WARNINTERVAL</filename>
variable and you do use <filename>BB_DISKMON_DIRS</filename> with
the "WARN" action, the disk monitoring interval defaults to
the following:
<literallayout class='monospaced'>
BB_DISKMON_WARNINTERVAL = "50M,5K"
</literallayout>
</para>
<para>
When specifying the variable in your configuration file,
use the following form:
<literallayout class='monospaced'>
BB_DISKMON_WARNINTERVAL = "<replaceable>disk_space_interval</replaceable>,<replaceable>disk_inode_interval</replaceable>"
where:
<replaceable>disk_space_interval</replaceable> 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.
<replaceable>disk_inode_interval</replaceable> 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.
</literallayout>
</para>
<para>
Here is an example:
<literallayout class='monospaced'>
BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
BB_DISKMON_WARNINTERVAL = "50M,5K"
</literallayout>
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
<filename>${SSTATE_DIR}</filename> 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).
</para>
</glossdef>
</glossentry>
<glossentry id='var-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm>
<info>
BB_GENERATE_MIRROR_TARBALLS[doc] = "Causes tarballs of the source control repositories to be placed in the DL_DIR directory."
</info>
<glossdef>
<para role="glossdeffirst">
Causes tarballs of the source control repositories
(e.g. Git repositories), including metadata, to be placed
in the
<link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
directory.
</para>
<para>
For performance reasons, creating and placing tarballs of
these repositories is not the default action by the
OpenEmbedded build system.
<literallayout class='monospaced'>
BB_GENERATE_MIRROR_TARBALLS = "1"
</literallayout>
Set this variable in your <filename>local.conf</filename>
file in the
<link linkend='build-directory'>Build Directory</link>.
</para>
<para>
Once you have the tarballs containing your source files,
you can clean up your <filename>DL_DIR</filename>
directory by deleting any Git or other source control
work directories.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
<info>
BB_NUMBER_THREADS[doc] = "The maximum number of tasks BitBake should run in parallel at any one time. This variable is automatically configured to be equal to the number of build system cores."
</info>
<glossdef>
<para role="glossdeffirst">
The maximum number of tasks BitBake should run in parallel
at any one time.
The OpenEmbedded build system automatically configures
this variable to be equal to the number of cores on the
build system.
For example, a system with a dual core processor that
also uses hyper-threading causes the
<filename>BB_NUMBER_THREADS</filename> variable to default
to "4".
</para>
<para>
For single socket systems (i.e. one CPU), you should not
have to override this variable to gain optimal parallelism
during builds.
However, if you have very large systems that employ
multiple physical CPUs, you might want to make sure the
<filename>BB_NUMBER_THREADS</filename> variable is not
set higher than "20".
</para>
<para>
For more information on speeding up builds, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#speeding-up-a-build'>Speeding Up a Build</ulink>"
section in the Yocto Project Development Tasks Manual.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BB_SERVER_TIMEOUT'><glossterm>BB_SERVER_TIMEOUT</glossterm>
<info>
BB_SERVER_TIMEOUT [doc] = "Specifies the time (in seconds) after which to unload the BitBake server due to inactivity."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the time (in seconds) after which to unload the
BitBake server due to inactivity.
Set <filename>BB_SERVER_TIMEOUT</filename> to determine how
long the BitBake server stays resident between invocations.
</para>
<para>
For example, the following statement in your
<filename>local.conf</filename> file instructs the server
to be unloaded after 20 seconds of inactivity:
<literallayout class='monospaced'>
BB_SERVER_TIMEOUT = "20"
</literallayout>
If you want the server to never be unloaded, set
<filename>BB_SERVER_TIMEOUT</filename> to "-1".
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm>
<info>
BBCLASSEXTEND[doc] = "Allows you to extend a recipe so that it builds variants of the software. Common variants for recipes are 'native', 'cross', 'nativesdk', and multilibs."
</info>
<glossdef>
<para role="glossdeffirst">
Allows you to extend a recipe so that it builds variants of the software.
Common variants for recipes exist such as "natives" like <filename>quilt-native</filename>,
which is a copy of Quilt built to run on the build system;
"crosses" such as <filename>gcc-cross</filename>,
which is a compiler built to run on the build machine but produces binaries
that run on the target <link linkend='var-MACHINE'><filename>MACHINE</filename></link>;
"nativesdk", which targets the SDK machine instead of <filename>MACHINE</filename>;
and "mulitlibs" in the form "<filename>multilib:</filename><replaceable>multilib_name</replaceable>".
</para>
<para>
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:
<literallayout class='monospaced'>
BBCLASSEXTEND =+ "native nativesdk"
BBCLASSEXTEND =+ "multilib:<replaceable>multilib_name</replaceable>"
</literallayout>
<note>
<para>
Internally, the <filename>BBCLASSEXTEND</filename>
mechanism generates recipe variants by rewriting
variable values and applying overrides such as
<filename>_class-native</filename>.
For example, to generate a native version of a recipe,
a
<link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
on "foo" is rewritten to a <filename>DEPENDS</filename>
on "foo-native".
</para>
<para>
Even when using <filename>BBCLASSEXTEND</filename>, the
recipe is only parsed once.
Parsing once adds some limitations.
For example, it is not possible to
include a different file depending on the variant,
since <filename>include</filename> statements are
processed when the recipe is parsed.
</para>
</note>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm>
<info>
BBFILE_COLLECTIONS[doc] = "Lists the names of configured layers. These names are used to find the other BBFILE_* variables."
</info>
<glossdef>
<para role="glossdeffirst">
Lists the names of configured layers.
These names are used to find the other <filename>BBFILE_*</filename>
variables.
Typically, each layer will append its name to this variable in its
<filename>conf/layer.conf</filename> file.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm>
<info>
BBFILE_PATTERN[doc] = "Variable that expands to match files from BBFILES in a particular layer. This variable is used in the layer.conf file and must be suffixed with the name of a layer."
</info>
<glossdef>
<para role="glossdeffirst">
Variable that expands to match files from
<link linkend='var-BBFILES'><filename>BBFILES</filename></link>
in a particular layer.
This variable is used in the <filename>conf/layer.conf</filename> file and must
be suffixed with the name of the specific layer (e.g.
<filename>BBFILE_PATTERN_emenlow</filename>).
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm>
<info>
BBFILE_PRIORITY[doc] = "Assigns the priority for recipe files in each layer. Setting this variable allows you to prioritize a layer against other layers that contain the same recipe."
</info>
<glossdef>
<para role="glossdeffirst">
Assigns the priority for recipe files in each layer.
</para>
<para>
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
(<link linkend='var-PV'><filename>PV</filename></link> variable).
For example, a layer that has a recipe with a higher <filename>PV</filename> value but for
which the <filename>BBFILE_PRIORITY</filename> is set to have a lower precedence still has a
lower precedence.
</para>
<para>
A larger value for the <filename>BBFILE_PRIORITY</filename> variable results in a higher
precedence.
For example, the value 6 has a higher precedence than the value 5.
If not specified, the <filename>BBFILE_PRIORITY</filename> variable is set based on layer
dependencies (see the
<filename><link linkend='var-LAYERDEPENDS'>LAYERDEPENDS</link></filename> 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).
</para>
<tip>
You can use the command <filename>bitbake-layers show-layers</filename> to list
all configured layers along with their priorities.
</tip>
</glossdef>
</glossentry>
<glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm>
<info>
BBFILES[doc] = "A space-separated list of recipe files BitBake uses to build software."
</info>
<glossdef>
<para role="glossdeffirst">
A space-separated list of recipe files BitBake uses to
build software.
</para>
<para>
When specifying recipe files, you can pattern match using
Python's
<ulink url='https://docs.python.org/3/library/glob.html'><filename>glob</filename></ulink>
syntax.
For details on the syntax, see the documentation by
following the previous link.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBFILES_DYNAMIC'><glossterm>BBFILES_DYNAMIC</glossterm>
<info>
BBFILES_DYNAMIC[doc] = "Activates content when identified layers are present."
</info>
<glossdef>
<para role="glossdeffirst">
Activates content when identified layers are present.
You identify the layers by the collections that the layers
define.
</para>
<para>
Use the <filename>BBFILES_DYNAMIC</filename> variable to
avoid <filename>.bbappend</filename> files whose
corresponding <filename>.bb</filename> file is in a layer
that attempts to modify other layers through
<filename>.bbappend</filename> but does not want to
introduce a hard dependency on those other layers.
</para>
<para>
Use the following form for
<filename>BBFILES_DYNAMIC</filename>:
<literallayout class='monospaced'>
<replaceable>collection_name</replaceable>:<replaceable>filename_pattern</replaceable>
</literallayout>
The following example identifies two collection names and
two filename patterns:
<literallayout class='monospaced'>
BBFILES_DYNAMIC += " \
clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
"
</literallayout>
This next example shows an error message that occurs
because invalid entries are found, which cause parsing to
abort:
<literallayout class='monospaced'>
ERROR: BBFILES_DYNAMIC entries must be of the form &lt;collection name&gt;:&lt;filename pattern&gt;, not:
/work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
/work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm>
<info>
BBINCLUDELOGS[doc] = "Variable that controls how BitBake displays logs on build failure."
</info>
<glossdef>
<para role="glossdeffirst">
Variable that controls how BitBake displays logs on build failure.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBINCLUDELOGS_LINES'><glossterm>BBINCLUDELOGS_LINES</glossterm>
<info>
BBINCLUDELOGS_LINES[doc] = "Amount of log lines printed on failure."
</info>
<glossdef>
<para role="glossdeffirst">
If
<link linkend='var-BBINCLUDELOGS'><filename>BBINCLUDELOGS</filename></link>
is set, specifies the maximum number of lines from the
task log file to print when reporting a failed task.
If you do not set <filename>BBINCLUDELOGS_LINES</filename>,
the entire log is printed.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm>
<info>
BBLAYERS[doc] = "Lists the layers to enable during the build. This variable is defined in the bblayers.conf configuration file."
</info>
<glossdef>
<para role="glossdeffirst">
Lists the layers to enable during the build.
This variable is defined in the <filename>bblayers.conf</filename> configuration
file in the
<link linkend='build-directory'>Build Directory</link>.
Here is an example:
<literallayout class='monospaced'>
BBLAYERS = " \
/home/scottrif/poky/meta \
/home/scottrif/poky/meta-poky \
/home/scottrif/poky/meta-yocto-bsp \
/home/scottrif/poky/meta-mykernel \
"
</literallayout>
</para>
<para>
This example enables four layers, one of which is a custom, user-defined layer
named <filename>meta-mykernel</filename>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBMASK'><glossterm>BBMASK</glossterm>
<info>
BBMASK[doc] = "Prevents BitBake from processing specific recipes or recipe append files."
</info>
<glossdef>
<para role="glossdeffirst">
Prevents BitBake from processing recipes and recipe
append files.
</para>
<para>
You can use the <filename>BBMASK</filename> variable
to "hide" these <filename>.bb</filename> and
<filename>.bbappend</filename> files.
BitBake ignores any recipe or recipe append files that
match any of the expressions.
It is as if BitBake does not see them at all.
Consequently, matching files are not parsed or otherwise
used by BitBake.
</para>
<para>
The values you provide are passed to Python's regular
expression compiler.
Consequently, the syntax follows Python's Regular
Expression (re) syntax.
The expressions are compared against the full paths to
the files.
For complete syntax information, see Python's
documentation at
<ulink url='http://docs.python.org/3/library/re.html#re'></ulink>.
</para>
<para>
The following example uses a complete regular expression
to tell BitBake to ignore all recipe and recipe append
files in the <filename>meta-ti/recipes-misc/</filename>
directory:
<literallayout class='monospaced'>
BBMASK = "meta-ti/recipes-misc/"
</literallayout>
If you want to mask out multiple directories or recipes,
you can specify multiple regular expression fragments.
This next example masks out multiple directories and
individual recipes:
<literallayout class='monospaced'>
BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
BBMASK += "/meta-oe/recipes-support/"
BBMASK += "/meta-foo/.*/openldap"
BBMASK += "opencv.*\.bbappend"
BBMASK += "lzma"
</literallayout>
<note>
When specifying a directory name, use the trailing
slash character to ensure you match just that directory
name.
</note>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBMULTICONFIG'><glossterm>BBMULTICONFIG</glossterm>
<info>
BBMULTICONFIG[doc] = "Specifies each additional separate configuration when you are building targets with multiple configurations."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies each additional separate configuration when you
are building targets with multiple configurations.
Use this variable in your
<filename>conf/local.conf</filename> configuration file.
Specify a <replaceable>multiconfigname</replaceable> for
each configuration file you are using.
For example, the following line specifies three
configuration files:
<literallayout class='monospaced'>
BBMULTICONFIG = "configA configB configC"
</literallayout>
Each configuration file you use must reside in the
<link linkend='build-directory'>Build Directory</link>
<filename>conf/multiconfig</filename> directory
(e.g.
<replaceable>build_directory</replaceable><filename>/conf/multiconfig/configA.conf</filename>).
</para>
<para>
For information on how to use
<filename>BBMULTICONFIG</filename> in an environment that
supports building targets with multiple configurations,
see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#dev-building-images-for-multiple-targets-using-multiple-configurations'>Building Images for Multiple Targets Using Multiple Configurations</ulink>"
section in the Yocto Project Development Tasks Manual.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm>
<info>
BBPATH[doc] = "Used by BitBake to locate .bbclass and configuration files. This variable is analogous to the PATH variable."
</info>
<glossdef>
<para role="glossdeffirst">
Used by BitBake to locate
<filename>.bbclass</filename> and configuration files.
This variable is analogous to the
<filename>PATH</filename> variable.
<note>
If you run BitBake from a directory outside of the
<link linkend='build-directory'>Build Directory</link>,
you must be sure to set
<filename>BBPATH</filename> to point to the
Build Directory.
Set the variable as you would any environment variable
and then run BitBake:
<literallayout class='monospaced'>
$ BBPATH = "<replaceable>build_directory</replaceable>"
$ export BBPATH
$ bitbake <replaceable>target</replaceable>
</literallayout>
</note>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BBSERVER'><glossterm>BBSERVER</glossterm>
<info>
BBSERVER[doc] = "Points to the BitBake remote server."
</info>
<glossdef>
<para role="glossdeffirst">
If defined in the BitBake environment,
<filename>BBSERVER</filename> points to the BitBake
remote server.
</para>
<para>
Use the following format to export the variable to the
BitBake environment:
<literallayout class='monospaced'>
export BBSERVER=localhost:$port
</literallayout>
</para>
<para>
By default, <filename>BBSERVER</filename> also appears in
<ulink url='&YOCTO_DOCS_BB_URL;#var-BB_HASHBASE_WHITELIST'><filename>BB_HASHBASE_WHITELIST</filename></ulink>.
Consequently, <filename>BBSERVER</filename> is excluded
from checksum and dependency data.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BINCONFIG'><glossterm>BINCONFIG</glossterm>
<info>
BINCONFIG[doc] = "When inheriting the binconfig-disabled class, this variable specifies binary configuration scripts to disable in favor of using pkg-config to query the information."
</info>
<glossdef>
<para role="glossdeffirst">
When inheriting the
<link linkend='ref-classes-binconfig-disabled'><filename>binconfig-disabled</filename></link>
class, this variable specifies binary configuration
scripts to disable in favor of using
<filename>pkg-config</filename> to query the information.
The <filename>binconfig-disabled</filename> class will
modify the specified scripts to return an error so that
calls to them can be easily found and replaced.
</para>
<para>
To add multiple scripts, separate them by spaces.
Here is an example from the <filename>libpng</filename>
recipe:
<literallayout class='monospaced'>
BINCONFIG = "${bindir}/libpng-config ${bindir}/libpng16-config"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BINCONFIG_GLOB'><glossterm>BINCONFIG_GLOB</glossterm>
<info>
BINCONFIG_GLOB[doc] = "When inheriting binconfig.bbclass from a recipe, this variable specifies a wildcard for configuration scripts that need editing."
</info>
<glossdef>
<para role="glossdeffirst">
When inheriting the
<link linkend='ref-classes-binconfig'><filename>binconfig</filename></link>
class, 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.
<note>
The <filename>BINCONFIG_GLOB</filename> variable
uses
<ulink url='http://tldp.org/LDP/abs/html/globbingref.html'>shell globbing</ulink>,
which is recognition and expansion of wildcards during
pattern matching.
Shell globbing is very similar to
<ulink url='https://docs.python.org/2/library/fnmatch.html#module-fnmatch'><filename>fnmatch</filename></ulink>
and
<ulink url='https://docs.python.org/2/library/glob.html'><filename>glob</filename></ulink>.
</note>
</para>
<para>
For more information on how this variable works, see
<filename>meta/classes/binconfig.bbclass</filename> in the
<link linkend='source-directory'>Source Directory</link>.
You can also find general information on the class in the
"<link linkend='ref-classes-binconfig'><filename>binconfig.bbclass</filename></link>"
section.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BP'><glossterm>BP</glossterm>
<info>
BP[doc] = "The base recipe name and version but without any special recipe name suffix (i.e. -native, lib64-, and so forth). BP is comprised of ${BPN}-${PV}"
</info>
<glossdef>
<para role="glossdeffirst">
The base recipe name and version but without any special
recipe name suffix (i.e. <filename>-native</filename>, <filename>lib64-</filename>,
and so forth).
<filename>BP</filename> is comprised of the following:
<literallayout class="monospaced">
${BPN}-${PV}
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BPN'><glossterm>BPN</glossterm>
<info>
BPN[doc] = "This variable is a version of the PN variable but removes common suffixes and prefixes."
</info>
<glossdef>
<para role="glossdeffirst">
This variable is a version of the
<link linkend='var-PN'><filename>PN</filename></link>
variable with common prefixes and suffixes
removed, such as <filename>nativesdk-</filename>,
<filename>-cross</filename>,
<filename>-native</filename>, and multilib's
<filename>lib64-</filename> and
<filename>lib32-</filename>.
The exact lists of prefixes and suffixes removed are
specified by the
<link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link>
and
<link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link>
variables, respectively.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUGTRACKER'><glossterm>BUGTRACKER</glossterm>
<info>
BUGTRACKER[doc] = "Specifies a URL for an upstream bug tracking website for a recipe."
</info>
<glossdef>
<para role="glossdeffirst">
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.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_ARCH'><glossterm>BUILD_ARCH</glossterm>
<info>
BUILD_ARCH[doc] = "The name of the building architecture (e.g. i686)."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the architecture of the build host
(e.g. <filename>i686</filename>).
The OpenEmbedded build system sets the value of
<filename>BUILD_ARCH</filename> from the machine name
reported by the <filename>uname</filename> command.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_AS_ARCH'><glossterm>BUILD_AS_ARCH</glossterm>
<info>
BUILD_AS_ARCH[doc] = "Specifies the architecture-specific assembler flags for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the architecture-specific assembler flags for
the build host. By default, the value of
<filename>BUILD_AS_ARCH</filename> is empty.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_CC_ARCH'><glossterm>BUILD_CC_ARCH</glossterm>
<info>
BUILD_CC_ARCH[doc] = "Specifies the architecture-specific C compiler flags for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the architecture-specific C compiler flags for
the build host. By default, the value of
<filename>BUILD_CC_ARCH</filename> is empty.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_CCLD'><glossterm>BUILD_CCLD</glossterm>
<info>
BUILD_CCLD[doc] = "Specifies the linker command to be used for the build host when the C compiler is being used as the linker."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the linker command to be used for the build host
when the C compiler is being used as the linker. By default,
<filename>BUILD_CCLD</filename> points to GCC and passes as
arguments the value of
<link linkend='var-BUILD_CC_ARCH'><filename>BUILD_CC_ARCH</filename></link>,
assuming <filename>BUILD_CC_ARCH</filename> is set.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_CFLAGS'><glossterm>BUILD_CFLAGS</glossterm>
<info>
BUILD_CFLAGS[doc] = "Specifies the flags to pass to the C compiler when building for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the C compiler when building
for the build host.
When building in the <filename>-native</filename> context,
<link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
is set to the value of this variable by default.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_CPPFLAGS'><glossterm>BUILD_CPPFLAGS</glossterm>
<info>
BUILD_CPPFLAGS[doc] = "Specifies the flags to pass to the C preprocessor (i.e. to both the C and the C++ compilers) when building for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the C preprocessor
(i.e. to both the C and the C++ compilers) when building
for the build host.
When building in the <filename>-native</filename> context,
<link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
is set to the value of this variable by default.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_CXXFLAGS'><glossterm>BUILD_CXXFLAGS</glossterm>
<info>
BUILD_CXXFLAGS[doc] = "Specifies the flags to pass to the C++ compiler when building for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the C++ compiler when
building for the build host.
When building in the <filename>-native</filename> context,
<link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
is set to the value of this variable by default.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_FC'><glossterm>BUILD_FC</glossterm>
<info>
BUILD_FC[doc] = "Specifies the Fortran compiler command for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the Fortran compiler command for the build host.
By default, <filename>BUILD_FC</filename> points to
Gfortran and passes as arguments the value of
<link linkend='var-BUILD_CC_ARCH'><filename>BUILD_CC_ARCH</filename></link>,
assuming <filename>BUILD_CC_ARCH</filename> is set.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_LD'><glossterm>BUILD_LD</glossterm>
<info>
BUILD_LD[doc] = "Specifies the linker command for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the linker command for the build host. By default,
<filename>BUILD_LD</filename> points to the GNU linker (ld)
and passes as arguments the value of
<link linkend='var-BUILD_LD_ARCH'><filename>BUILD_LD_ARCH</filename></link>,
assuming <filename>BUILD_LD_ARCH</filename> is set.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_LD_ARCH'><glossterm>BUILD_LD_ARCH</glossterm>
<info>
BUILD_LD_ARCH[doc] = "Specifies architecture-specific linker flags for the build."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies architecture-specific linker flags for the build
host. By default, the value of
<filename>BUILD_LD_ARCH</filename> is empty.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_LDFLAGS'><glossterm>BUILD_LDFLAGS</glossterm>
<info>
BUILD_LDFLAGS[doc] = "Specifies the flags to pass to the linker when building for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the linker when building
for the build host.
When building in the <filename>-native</filename> context,
<link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
is set to the value of this variable by default.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_OPTIMIZATION'><glossterm>BUILD_OPTIMIZATION</glossterm>
<info>
BUILD_OPTIMIZATION[doc] = "Specifies the optimization flags passed to the C compiler when building for the build host or the SDK."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the optimization flags passed to the C compiler
when building for the build host or the SDK.
The flags are passed through the
<link linkend='var-BUILD_CFLAGS'><filename>BUILD_CFLAGS</filename></link>
and
<link linkend='var-BUILDSDK_CFLAGS'><filename>BUILDSDK_CFLAGS</filename></link>
default values.
</para>
<para>
The default value of the
<filename>BUILD_OPTIMIZATION</filename> variable is
"-O2 -pipe".
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_OS'><glossterm>BUILD_OS</glossterm>
<info>
BUILD_OS[doc] = "The operating system (in lower case) of the building architecture (e.g. Linux)."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the operating system in use on the build
host (e.g. "linux").
The OpenEmbedded build system sets the value of
<filename>BUILD_OS</filename> from the OS reported by
the <filename>uname</filename> command - the first word,
converted to lower-case characters.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_PREFIX'><glossterm>BUILD_PREFIX</glossterm>
<info>
BUILD_PREFIX[doc] = "The toolchain binary prefix used for native recipes."
</info>
<glossdef>
<para role="glossdeffirst">
The toolchain binary prefix used for native recipes.
The OpenEmbedded build system uses the
<filename>BUILD_PREFIX</filename> value to set the
<link linkend='var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></link>
when building for <filename>native</filename> recipes.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_STRIP'><glossterm>BUILD_STRIP</glossterm>
<info>
BUILD_STRIP[doc] = "Specifies the command to be used to strip debugging symbols from binaries produced for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the command to be used to strip debugging symbols
from binaries produced for the build host. By default,
<filename>BUILD_STRIP</filename> points to
<filename>${</filename><link linkend='var-BUILD_PREFIX'><filename>BUILD_PREFIX</filename></link><filename>}strip</filename>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_SYS'><glossterm>BUILD_SYS</glossterm>
<info>
BUILD_SYS[doc] = "The toolchain binary prefix used for native recipes."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the system, including the architecture and
the operating system, to use when building for the build
host (i.e. when building <filename>native</filename>
recipes).
</para>
<para>
The OpenEmbedded build system automatically sets this
variable based on
<link linkend='var-BUILD_ARCH'><filename>BUILD_ARCH</filename></link>,
<link linkend='var-BUILD_VENDOR'><filename>BUILD_VENDOR</filename></link>,
and
<link linkend='var-BUILD_OS'><filename>BUILD_OS</filename></link>.
You do not need to set the <filename>BUILD_SYS</filename>
variable yourself.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILD_VENDOR'><glossterm>BUILD_VENDOR</glossterm>
<info>
BUILD_VENDOR[doc] = "The vendor name to use when building for the build host."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the vendor name to use when building for the
build host.
The default value is an empty string ("").
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDDIR'><glossterm>BUILDDIR</glossterm>
<info>
BUILDDIR[doc] = "Points to the location of the Build Directory."
</info>
<glossdef>
<para role="glossdeffirst">
Points to the location of the
<link linkend='build-directory'>Build Directory</link>.
You can define this directory indirectly through the
<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
script by passing in a Build Directory path when you run
the script.
If you run the script and do not provide a Build Directory
path, the <filename>BUILDDIR</filename> defaults to
<filename>build</filename> in the current directory.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDHISTORY_COMMIT'><glossterm>BUILDHISTORY_COMMIT</glossterm>
<info>
BUILDHISTORY_COMMIT[doc] = "When inheriting the buildhistory class, this variable specifies whether or not to commit the build history output in a local Git repository."
</info>
<glossdef>
<para role="glossdeffirst">
When inheriting the
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
class, this variable 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
<filename>buildhistory</filename>
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".
</para>
<para>
By default, the <filename>buildhistory</filename> class
does not commit the build history output in a local
Git repository:
<literallayout class='monospaced'>
BUILDHISTORY_COMMIT ?= "0"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDHISTORY_COMMIT_AUTHOR'><glossterm>BUILDHISTORY_COMMIT_AUTHOR</glossterm>
<info>
BUILDHISTORY_COMMIT_AUTHOR[doc] = "When inheriting the buildhistory class, this variable specifies the author to use for each Git commit."
</info>
<glossdef>
<para role="glossdeffirst">
When inheriting the
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
class, this variable specifies the author to use for each
Git commit.
In order for the <filename>BUILDHISTORY_COMMIT_AUTHOR</filename>
variable to work, the
<link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT</filename></link>
variable must be set to "1".
</para>
<para>
Git requires that the value you provide for the
<filename>BUILDHISTORY_COMMIT_AUTHOR</filename> variable
takes the form of "name <replaceable>email@host</replaceable>".
Providing an email address or host that is not valid does
not produce an error.
</para>
<para>
By default, the <filename>buildhistory</filename> class
sets the variable as follows:
<literallayout class='monospaced'>
BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory &lt;buildhistory@${DISTRO}&gt;"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDHISTORY_DIR'><glossterm>BUILDHISTORY_DIR</glossterm>
<info>
BUILDHISTORY_DIR[doc] = "When inheriting the buildhistory class, this variable specifies the directory in which build history information is kept."
</info>
<glossdef>
<para role="glossdeffirst">
When inheriting the
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
class, this variable specifies the directory in which
build history information is kept.
For more information on how the variable works, see the
<filename>buildhistory.class</filename>.
</para>
<para>
By default, the <filename>buildhistory</filename> class
sets the directory as follows:
<literallayout class='monospaced'>
BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDHISTORY_FEATURES'><glossterm>BUILDHISTORY_FEATURES</glossterm>
<info>
BUILDHISTORY_FEATURES[doc] = "When inheriting the buildhistory class, this variable specifies the build history features to be enabled."
</info>
<glossdef>
<para role="glossdeffirst">
When inheriting the
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
class, this variable specifies the build history features
to be enabled.
For more information on how build history works, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>"
section in the Yocto Project Development Tasks Manual.
</para>
<para>
You can specify these features in the form of a
space-separated list:
<itemizedlist>
<listitem><para><emphasis>image:</emphasis>
Analysis of the contents of images, which
includes the list of installed packages among other
things.
</para></listitem>
<listitem><para><emphasis>package:</emphasis>
Analysis of the contents of individual packages.
</para></listitem>
<listitem><para><emphasis>sdk:</emphasis>
Analysis of the contents of the software
development kit (SDK).
</para></listitem>
<listitem><para><emphasis>task:</emphasis>
Save output file signatures for
<ulink url='&YOCTO_DOCS_OM_URL;#shared-state-cache'>shared state</ulink>
(sstate) tasks.
This saves one file per task and lists the SHA-256
checksums for each file staged (i.e. the output of
the task).
</para></listitem>
</itemizedlist>
</para>
<para>
By default, the <filename>buildhistory</filename> class
enables the following features:
<literallayout class='monospaced'>
BUILDHISTORY_FEATURES ?= "image package sdk"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDHISTORY_IMAGE_FILES'><glossterm>BUILDHISTORY_IMAGE_FILES</glossterm>
<info>
BUILDHISTORY_IMAGE_FILES[doc] = "When inheriting the buildhistory class, this variable 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."
</info>
<glossdef>
<para role="glossdeffirst">
When inheriting the
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
class, this variable 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 <filename>/etc/passwd</filename>
and <filename>/etc/group</filename>, 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.
</para>
<para>
By default, the <filename>buildhistory</filename> class
provides paths to the following files:
<literallayout class='monospaced'>
BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDHISTORY_PUSH_REPO'><glossterm>BUILDHISTORY_PUSH_REPO</glossterm>
<info>
BUILDHISTORY_PUSH_REPO[doc] = "When inheriting the buildhistory class, this variable optionally specifies a remote repository to which build history pushes Git changes."
</info>
<glossdef>
<para role="glossdeffirst">
When inheriting the
<link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
class, this variable optionally specifies a remote
repository to which build history pushes Git changes.
In order for <filename>BUILDHISTORY_PUSH_REPO</filename>
to work,
<link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT</filename></link>
must be set to "1".
</para>
<para>
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 <filename>git remote</filename>
within the local repository.
</para>
<para>
By default, the <filename>buildhistory</filename> class
sets the variable as follows:
<literallayout class='monospaced'>
BUILDHISTORY_PUSH_REPO ?= ""
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDSDK_CFLAGS'><glossterm>BUILDSDK_CFLAGS</glossterm>
<info>
BUILDSDK_CFLAGS[doc] = "Specifies the flags to pass to the C compiler when building for the SDK."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the C compiler when building
for the SDK.
When building in the <filename>nativesdk-</filename>
context,
<link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
is set to the value of this variable by default.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDSDK_CPPFLAGS'><glossterm>BUILDSDK_CPPFLAGS</glossterm>
<info>
BUILDSDK_CPPFLAGS[doc] = "Specifies the flags to pass to the C pre-processor (i.e. to both the C and the C++ compilers) when building for the SDK."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the C pre-processor
(i.e. to both the C and the C++ compilers) when building
for the SDK.
When building in the <filename>nativesdk-</filename>
context,
<link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
is set to the value of this variable by default.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDSDK_CXXFLAGS'><glossterm>BUILDSDK_CXXFLAGS</glossterm>
<info>
BUILDSDK_CXXFLAGS[doc] = "Specifies the flags to pass to the C++ compiler when building for the SDK."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the C++ compiler when
building for the SDK.
When building in the <filename>nativesdk-</filename>
context,
<link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
is set to the value of this variable by default.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDSDK_LDFLAGS'><glossterm>BUILDSDK_LDFLAGS</glossterm>
<info>
BUILDSDK_LDFLAGS[doc] = "Specifies the flags to pass to the linker when building for the SDK."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the linker when building
for the SDK.
When building in the <filename>nativesdk-</filename>
context,
<link linkend='var-LDFLAGS'><filename>LDFLAGS</filename></link>
is set to the value of this variable by default.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUILDSTATS_BASE'><glossterm>BUILDSTATS_BASE</glossterm>
<info>
BUILDSTATS_BASE[doc] = "Points to the location of the directory that holds build statistics when you use and enable the buildstats class."
</info>
<glossdef>
<para role="glossdeffirst">
Points to the location of the directory that holds build
statistics when you use and enable the
<link linkend='ref-classes-buildstats'><filename>buildstats</filename></link>
class.
The <filename>BUILDSTATS_BASE</filename> directory defaults
to
<filename>${</filename><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>}/buildstats/</filename>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-BUSYBOX_SPLIT_SUID'><glossterm>BUSYBOX_SPLIT_SUID</glossterm>
<info>
BUSYBOX_SPLIT_SUID[doc] = "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."
</info>
<glossdef>
<para role="glossdeffirst">
For the BusyBox recipe, specifies whether to split the
output executable file into two parts: one for features
that require <filename>setuid root</filename>, and one for
the remaining features (i.e. those that do not require
<filename>setuid root</filename>).
</para>
<para>
The <filename>BUSYBOX_SPLIT_SUID</filename> variable
defaults to "1", which results in splitting the output
executable file.
Set the variable to "0" to get a single output executable
file.
</para>
</glossdef>
</glossentry>
</glossdiv>
<glossdiv id='var-glossary-c'><title>C</title>
<glossentry id='var-CACHE'><glossterm>CACHE</glossterm>
<info>
CACHE[doc] = "The directory BitBake uses to store a cache of the metadata."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the directory BitBake uses to store a cache
of the
<link linkend='metadata'>Metadata</link>
so it does not need to be parsed every time BitBake is
started.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CC'><glossterm>CC</glossterm>
<info>
CC[doc] = "Minimum command and arguments to run the C compiler."
</info>
<glossdef>
<para role="glossdeffirst">
The minimal command and arguments used to run the C
compiler.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CFLAGS'><glossterm>CFLAGS</glossterm>
<info>
CFLAGS[doc] = "Flags passed to the C compiler for the target system. This variable evaluates to the same as TARGET_CFLAGS."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the C compiler.
This variable is exported to an environment
variable and thus made visible to the software being
built during the compilation step.
</para>
<para>
Default initialization for <filename>CFLAGS</filename>
varies depending on what is being built:
<itemizedlist>
<listitem><para>
<link linkend='var-TARGET_CFLAGS'><filename>TARGET_CFLAGS</filename></link>
when building for the target
</para></listitem>
<listitem><para>
<link linkend='var-BUILD_CFLAGS'><filename>BUILD_CFLAGS</filename></link>
when building for the build host (i.e.
<filename>-native</filename>)
</para></listitem>
<listitem><para>
<link linkend='var-BUILDSDK_CFLAGS'><filename>BUILDSDK_CFLAGS</filename></link>
when building for an SDK (i.e.
<filename>nativesdk-</filename>)
</para></listitem>
</itemizedlist>
</para>
</glossdef>
</glossentry>
<glossentry id='var-CLASSOVERRIDE'><glossterm>CLASSOVERRIDE</glossterm>
<info>
CLASSOVERRIDE[doc] = "An internal variable specifying the special class override that should currently apply (e.g. "class-target", "class-native", and so forth)."
</info>
<glossdef>
<para role="glossdeffirst">
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 (e.g.
<link linkend='ref-classes-native'><filename>native</filename></link>,
<link linkend='ref-classes-nativesdk'><filename>nativesdk</filename></link>,
and so forth) set the variable to appropriate values.
<note>
<filename>CLASSOVERRIDE</filename> gets its default
"class-target" value from the
<filename>bitbake.conf</filename> file.
</note>
</para>
<para>
As an example, the following override allows you to install
extra files, but only when building for the target:
<literallayout class='monospaced'>
do_install_append_class-target() {
install my-extra-file ${D}${sysconfdir}
}
</literallayout>
Here is an example where <filename>FOO</filename>
is set to "native" when building for the build host, and
to "other" when not building for the build host:
<literallayout class='monospaced'>
FOO_class-native = "native"
FOO = "other"
</literallayout>
The underlying mechanism behind
<filename>CLASSOVERRIDE</filename> is simply that it is
included in the default value of
<link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CLEANBROKEN'><glossterm>CLEANBROKEN</glossterm>
<info>
CLEANBROKEN[doc] = "Prevents the build system from running 'make clean' during the do_configure task."
</info>
<glossdef>
<para role="glossdeffirst">
If set to "1" within a recipe,
<filename>CLEANBROKEN</filename> specifies that
the <filename>make clean</filename> command does
not work for the software being built.
Consequently, the OpenEmbedded build system will not try
to run <filename>make clean</filename> during the
<link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
task, which is the default behavior.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COMBINED_FEATURES'><glossterm>COMBINED_FEATURES</glossterm>
<info>
COMBINED_FEATURES[doc] = "A set of features common between MACHINE_FEATURES and DISTRO_FEATURES."
</info>
<glossdef>
<para role="glossdeffirst">
Provides a list of hardware features that are enabled in
both
<link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
and
<link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
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.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COMMON_LICENSE_DIR'><glossterm>COMMON_LICENSE_DIR</glossterm>
<info>
COMMON_LICENSE_DIR[doc] = "Points to meta/files/common-licenses in the Source Directory, which is where generic license files reside."
</info>
<glossdef>
<para role="glossdeffirst">
Points to <filename>meta/files/common-licenses</filename>
in the
<link linkend='source-directory'>Source Directory</link>,
which is where generic license files reside.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COMPATIBLE_HOST'><glossterm>COMPATIBLE_HOST</glossterm>
<info>
COMPATIBLE_HOST[doc] = "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."
</info>
<glossdef>
<para role="glossdeffirst">
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
<link linkend="var-HOST_SYS"><filename>HOST_SYS</filename></link>.
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.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
<info>
COMPATIBLE_MACHINE[doc] = "A regular expression that resolves to one or more target machines with which a recipe is compatible."
</info>
<glossdef>
<para role="glossdeffirst">
A regular expression that resolves to one or more
target machines with which a recipe is compatible.
The regular expression is matched against
<link linkend="var-MACHINEOVERRIDES"><filename>MACHINEOVERRIDES</filename></link>.
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.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COMPLEMENTARY_GLOB'><glossterm>COMPLEMENTARY_GLOB</glossterm>
<info>
COMPLEMENTARY_GLOB[doc] = "Defines wildcards to match when installing a list of complementary packages for all the packages installed in an image."
</info>
<glossdef>
<para role="glossdeffirst">
Defines wildcards to match when installing a list of
complementary packages for all the packages explicitly
(or implicitly) installed in an image.
<note>
The <filename>COMPLEMENTARY_GLOB</filename> variable
uses Unix filename pattern matching
(<ulink url='https://docs.python.org/2/library/fnmatch.html#module-fnmatch'><filename>fnmatch</filename></ulink>),
which is similar to the Unix style pathname pattern
expansion
(<ulink url='https://docs.python.org/2/library/glob.html'><filename>glob</filename></ulink>).
</note>
The resulting list of complementary packages is associated
with an item that can be added to
<link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
An example usage of this is the "dev-pkgs" item that when
added to <filename>IMAGE_FEATURES</filename> will
install -dev packages (containing headers and other
development files) for every package in the image.
</para>
<para>
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:
<literallayout class='monospaced'>
COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-COMPONENTS_DIR'><glossterm>COMPONENTS_DIR</glossterm>
<info>
COMPONENTS_DIR[doc] = "Stores sysroot components for each recipe."
</info>
<glossdef>
<para role="glossdeffirst">
Stores sysroot components for each recipe.
The OpenEmbedded build system uses
<filename>COMPONENTS_DIR</filename> when constructing
recipe-specific sysroots for other recipes.
</para>
<para>
The default is
"<filename>${</filename><link linkend='var-STAGING_DIR'><filename>STAGING_DIR</filename></link><filename>}-components</filename>."
(i.e. "<filename>${</filename><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>}/sysroots-components</filename>").
</para>
</glossdef>
</glossentry>
<glossentry id='var-CONF_VERSION'><glossterm>CONF_VERSION</glossterm>
<info>
CONF_VERSION[doc] = "Tracks the version of local.conf. Increased each time build/conf/ changes incompatibly."
</info>
<glossdef>
<para role="glossdeffirst">
Tracks the version of the local configuration file
(i.e. <filename>local.conf</filename>).
The value for <filename>CONF_VERSION</filename>
increments each time <filename>build/conf/</filename>
compatibility changes.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CONFFILES'><glossterm>CONFFILES</glossterm>
<info>
CONFFILES[doc] = "Identifies editable or configurable files that are part of a package."
</info>
<glossdef>
<para role="glossdeffirst">
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 <filename>CONFFILES</filename> variable to list the files in the
package that you wish to prevent the PMS from overwriting during this update process.
</para>
<para>
To use the <filename>CONFFILES</filename> variable, provide a package name
override that identifies the resulting package.
Then, provide a space-separated list of files.
Here is an example:
<literallayout class='monospaced'>
CONFFILES_${PN} += "${sysconfdir}/file1 \
${sysconfdir}/file2 ${sysconfdir}/file3"
</literallayout>
</para>
<para>
A relationship exists between the <filename>CONFFILES</filename> and
<filename><link linkend='var-FILES'>FILES</link></filename> variables.
The files listed within <filename>CONFFILES</filename> must be a subset of
the files listed within <filename>FILES</filename>.
Because the configuration files you provide with <filename>CONFFILES</filename>
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
<filename>FILES</filename> variable.
</para>
<note>
When specifying paths as part of the <filename>CONFFILES</filename> variable,
it is good practice to use appropriate path variables.
For example, <filename>${sysconfdir}</filename> rather than
<filename>/etc</filename> or <filename>${bindir}</filename> rather
than <filename>/usr/bin</filename>.
You can find a list of these variables at the top of the
<filename>meta/conf/bitbake.conf</filename> file in the
<link linkend='source-directory'>Source Directory</link>.
</note>
</glossdef>
</glossentry>
<glossentry id='var-CONFIG_INITRAMFS_SOURCE'><glossterm>CONFIG_INITRAMFS_SOURCE</glossterm>
<info>
CONFIG_INITRAMFS_SOURCE[doc] = "Identifies the initial RAM filesystem (initramfs) source files. The OpenEmbedded build system receives and uses this kernel Kconfig variable as an environment variable."
</info>
<glossdef>
<para role="glossdeffirst">
Identifies the initial RAM filesystem (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 ("").
</para>
<para>
The <filename>CONFIG_INITRAMFS_SOURCE</filename> can be
either a single cpio archive with a
<filename>.cpio</filename> 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
<filename>usr/gen_init_cpio</filename> program in the
kernel tree.
</para>
<para>
If you specify multiple directories and files, the
initramfs image will be the aggregate of all of them.
</para>
<para>
For information on creating an initramfs, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image'>Building an Initial RAM Filesystem (initramfs) Image</ulink>"
section in the Yocto Project Development Tasks Manual.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CONFIG_SITE'><glossterm>CONFIG_SITE</glossterm>
<info>
CONFIG_SITE[doc] = "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."
</info>
<glossdef>
<para role="glossdeffirst">
A list of files that contains <filename>autoconf</filename> test results relevant
to the current build.
This variable is used by the Autotools utilities when running
<filename>configure</filename>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CONFIGURE_FLAGS'><glossterm>CONFIGURE_FLAGS</glossterm>
<info>
CONFIGURE_FLAGS[doc] = "The minimal arguments for GNU configure."
</info>
<glossdef>
<para role="glossdeffirst">
The minimal arguments for GNU configure.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CONFLICT_DISTRO_FEATURES'><glossterm>CONFLICT_DISTRO_FEATURES</glossterm>
<info>
CONFLICT_DISTRO_FEATURES[doc] = "When a recipe inherits the distro_features_check class, this variable identifies distribution features that would be in conflict should the recipe be built."
</info>
<glossdef>
<para role="glossdeffirst">
When inheriting the
<link linkend='ref-classes-distro_features_check'><filename>distro_features_check</filename></link>
class, this
variable identifies distribution features that would
be in conflict should the recipe
be built.
In other words, if the
<filename>CONFLICT_DISTRO_FEATURES</filename> variable
lists a feature that also appears in
<filename>DISTRO_FEATURES</filename> within the
current configuration, an error occurs and the
build stops.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COPYLEFT_LICENSE_EXCLUDE'><glossterm>COPYLEFT_LICENSE_EXCLUDE</glossterm>
<info>
COPYLEFT_LICENSE_EXCLUDE[doc] = "Licenses to exclude in the source archived by the archiver class."
</info>
<glossdef>
<para role="glossdeffirst">
A space-separated list of licenses to exclude from the
source archived by the
<link linkend='ref-classes-archiver'><filename>archiver</filename></link>
class.
In other words, if a license in a recipe's
<link linkend='var-LICENSE'><filename>LICENSE</filename></link>
value is in the value of
<filename>COPYLEFT_LICENSE_EXCLUDE</filename>, then its
source is not archived by the class.
<note>
The <filename>COPYLEFT_LICENSE_EXCLUDE</filename>
variable takes precedence over the
<link linkend='var-COPYLEFT_LICENSE_INCLUDE'><filename>COPYLEFT_LICENSE_INCLUDE</filename></link>
variable.
</note>
The default value, which is "CLOSED Proprietary", for
<filename>COPYLEFT_LICENSE_EXCLUDE</filename> is set
by the
<link linkend='ref-classes-copyleft_filter'><filename>copyleft_filter</filename></link>
class, which is inherited by the
<filename>archiver</filename> class.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COPYLEFT_LICENSE_INCLUDE'><glossterm>COPYLEFT_LICENSE_INCLUDE</glossterm>
<info>
COPYLEFT_LICENSE_INCLUDE[doc] = "Licenses to include in the source archived by the archiver class."
</info>
<glossdef>
<para role="glossdeffirst">
A space-separated list of licenses to include in the
source archived by the
<link linkend='ref-classes-archiver'><filename>archiver</filename></link>
class.
In other words, if a license in a recipe's
<link linkend='var-LICENSE'><filename>LICENSE</filename></link>
value is in the value of
<filename>COPYLEFT_LICENSE_INCLUDE</filename>, then its
source is archived by the class.
</para>
<para>
The default value is set by the
<link linkend='ref-classes-copyleft_filter'><filename>copyleft_filter</filename></link>
class, which is inherited by the
<filename>archiver</filename> class.
The default value includes "GPL*", "LGPL*", and "AGPL*".
</para>
</glossdef>
</glossentry>
<glossentry id='var-COPYLEFT_PN_EXCLUDE'><glossterm>COPYLEFT_PN_EXCLUDE</glossterm>
<info>
COPYLEFT_PN_EXCLUDE[doc] = "Recipes to exclude in the source archived by the archiver class."
</info>
<glossdef>
<para role="glossdeffirst">
A list of recipes to exclude in the source archived
by the
<link linkend='ref-classes-archiver'><filename>archiver</filename></link>
class.
The <filename>COPYLEFT_PN_EXCLUDE</filename> variable
overrides the license inclusion and exclusion caused
through the
<link linkend='var-COPYLEFT_LICENSE_INCLUDE'><filename>COPYLEFT_LICENSE_INCLUDE</filename></link>
and
<link linkend='var-COPYLEFT_LICENSE_EXCLUDE'><filename>COPYLEFT_LICENSE_EXCLUDE</filename></link>
variables, respectively.
</para>
<para>
The default value, which is "" indicating to not explicitly
exclude any recipes by name, for
<filename>COPYLEFT_PN_EXCLUDE</filename> is set
by the
<link linkend='ref-classes-copyleft_filter'><filename>copyleft_filter</filename></link>
class, which is inherited by the
<filename>archiver</filename> class.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COPYLEFT_PN_INCLUDE'><glossterm>COPYLEFT_PN_INCLUDE</glossterm>
<info>
COPYLEFT_PN_INCLUDE[doc] = "Recipes to include in the source archived by the archiver class."
</info>
<glossdef>
<para role="glossdeffirst">
A list of recipes to include in the source archived
by the
<link linkend='ref-classes-archiver'><filename>archiver</filename></link>
class.
The <filename>COPYLEFT_PN_INCLUDE</filename> variable
overrides the license inclusion and exclusion caused
through the
<link linkend='var-COPYLEFT_LICENSE_INCLUDE'><filename>COPYLEFT_LICENSE_INCLUDE</filename></link>
and
<link linkend='var-COPYLEFT_LICENSE_EXCLUDE'><filename>COPYLEFT_LICENSE_EXCLUDE</filename></link>
variables, respectively.
</para>
<para>
The default value, which is "" indicating to not explicitly
include any recipes by name, for
<filename>COPYLEFT_PN_INCLUDE</filename> is set
by the
<link linkend='ref-classes-copyleft_filter'><filename>copyleft_filter</filename></link>
class, which is inherited by the
<filename>archiver</filename> class.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COPYLEFT_RECIPE_TYPES'><glossterm>COPYLEFT_RECIPE_TYPES</glossterm>
<info>
COPYLEFT_RECIPE_TYPES[doc] = "Recipe types to include in the source archived by the archiver class."
</info>
<glossdef>
<para role="glossdeffirst">
A space-separated list of recipe types to include
in the source archived by the
<link linkend='ref-classes-archiver'><filename>archiver</filename></link>
class.
Recipe types are <filename>target</filename>,
<filename>native</filename>,
<filename>nativesdk</filename>,
<filename>cross</filename>,
<filename>crosssdk</filename>, and
<filename>cross-canadian</filename>.
</para>
<para>
The default value, which is "target*", for
<filename>COPYLEFT_RECIPE_TYPES</filename> is set
by the
<link linkend='ref-classes-copyleft_filter'><filename>copyleft_filter</filename></link>
class, which is inherited by the
<filename>archiver</filename> class.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COPY_LIC_DIRS'><glossterm>COPY_LIC_DIRS</glossterm>
<info>
COPY_LIC_DIRS[doc] = "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."
</info>
<glossdef>
<para role="glossdeffirst">
If set to "1" along with the
<link linkend='var-COPY_LIC_MANIFEST'><filename>COPY_LIC_MANIFEST</filename></link>
variable, the OpenEmbedded build system copies
into the image the license files, which are located in
<filename>/usr/share/common-licenses</filename>,
for each package.
The license files are placed
in directories within the image itself during build time.
<note>
The <filename>COPY_LIC_DIRS</filename> does not
offer a path for adding licenses for newly installed
packages to an image, which might be most suitable
for read-only filesystems that cannot be upgraded.
See the
<link linkend='var-LICENSE_CREATE_PACKAGE'><filename>LICENSE_CREATE_PACKAGE</filename></link>
variable for additional information.
You can also reference the
"<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
section in the Yocto Project Development Tasks Manual
for information on providing license text.
</note>
</para>
</glossdef>
</glossentry>
<glossentry id='var-COPY_LIC_MANIFEST'><glossterm>COPY_LIC_MANIFEST</glossterm>
<info>
COPY_LIC_MANIFEST[doc] = "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."
</info>
<glossdef>
<para role="glossdeffirst">
If set to "1", the OpenEmbedded build system copies
the license manifest for the image to
<filename>/usr/share/common-licenses/license.manifest</filename>
within the image itself during build time.
<note>
The <filename>COPY_LIC_MANIFEST</filename> does not
offer a path for adding licenses for newly installed
packages to an image, which might be most suitable
for read-only filesystems that cannot be upgraded.
See the
<link linkend='var-LICENSE_CREATE_PACKAGE'><filename>LICENSE_CREATE_PACKAGE</filename></link>
variable for additional information.
You can also reference the
"<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
section in the Yocto Project Development Tasks Manual
for information on providing license text.
</note>
</para>
</glossdef>
</glossentry>
<glossentry id='var-CORE_IMAGE_EXTRA_INSTALL'><glossterm>CORE_IMAGE_EXTRA_INSTALL</glossterm>
<info>
CORE_IMAGE_EXTRA_INSTALL[doc] = "Specifies the list of packages to be added to the image. You should only set this variable in the conf/local.conf file in the Build Directory."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the list of packages to be added to the image.
You should only set this variable in the
<filename>local.conf</filename> configuration file found
in the
<link linkend='build-directory'>Build Directory</link>.
</para>
<para>
This variable replaces <filename>POKY_EXTRA_INSTALL</filename>, which is no longer supported.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COREBASE'><glossterm>COREBASE</glossterm>
<info>
COREBASE[doc] = "Specifies the parent directory of the OpenEmbedded-Core Metadata layer (i.e. meta)."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the parent directory of the OpenEmbedded-Core
Metadata layer (i.e. <filename>meta</filename>).
</para>
<para>
It is an important distinction that
<filename>COREBASE</filename> 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 <filename>poky</filename>
name for your local copy of the repository.
In this case, <filename>COREBASE</filename> points to
the <filename>poky</filename> folder because it is the
parent directory of the <filename>poky/meta</filename>
layer.
</para>
</glossdef>
</glossentry>
<glossentry id='var-COREBASE_FILES'><glossterm>COREBASE_FILES</glossterm>
<info>
COREBASE_FILES[doc] = "Lists files from the COREBASE directory that should be copied other than the layers listed in the bblayers.conf file."
</info>
<glossdef>
<para role="glossdeffirst">
Lists files from the
<link linkend='var-COREBASE'><filename>COREBASE</filename></link>
directory that should be copied other than the layers
listed in the <filename>bblayers.conf</filename> file.
The <filename>COREBASE_FILES</filename> variable exists
for the purpose of copying metadata from the
OpenEmbedded build system into the extensible
SDK.
</para>
<para>
Explicitly listing files in <filename>COREBASE</filename>
is needed because it typically contains build
directories and other files that should not normally
be copied into the extensible SDK.
Consequently, the value of
<filename>COREBASE_FILES</filename> is used in order to
only copy the files that are actually needed.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CPP'><glossterm>CPP</glossterm>
<info>
CPP[doc] = "Minimum command and arguments to run the C preprocessor."
</info>
<glossdef>
<para role="glossdeffirst">
The minimal command and arguments used to run the C
preprocessor.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CPPFLAGS'><glossterm>CPPFLAGS</glossterm>
<info>
CPPFLAGS[doc] = "Specifies the flags to pass to the C pre-processor (i.e. to both the C and the C++ compilers)."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the C pre-processor
(i.e. to both the C and the C++ compilers).
This variable is exported to an environment
variable and thus made visible to the software being
built during the compilation step.
</para>
<para>
Default initialization for <filename>CPPFLAGS</filename>
varies depending on what is being built:
<itemizedlist>
<listitem><para>
<link linkend='var-TARGET_CPPFLAGS'><filename>TARGET_CPPFLAGS</filename></link>
when building for the target
</para></listitem>
<listitem><para>
<link linkend='var-BUILD_CPPFLAGS'><filename>BUILD_CPPFLAGS</filename></link>
when building for the build host (i.e.
<filename>-native</filename>)
</para></listitem>
<listitem><para>
<link linkend='var-BUILDSDK_CPPFLAGS'><filename>BUILDSDK_CPPFLAGS</filename></link>
when building for an SDK (i.e.
<filename>nativesdk-</filename>)
</para></listitem>
</itemizedlist>
</para>
</glossdef>
</glossentry>
<glossentry id='var-CROSS_COMPILE'><glossterm>CROSS_COMPILE</glossterm>
<info>
CROSS_COMPILE[doc] = "The toolchain binary prefix for the target tools."
</info>
<glossdef>
<para role="glossdeffirst">
The toolchain binary prefix for the target tools.
The <filename>CROSS_COMPILE</filename> variable is the
same as the
<link linkend='var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></link>
variable.
<note>
The OpenEmbedded build system sets the
<filename>CROSS_COMPILE</filename> variable only in
certain contexts (e.g. when building for kernel
and kernel module recipes).
</note>
</para>
</glossdef>
</glossentry>
<glossentry id='var-CVSDIR'><glossterm>CVSDIR</glossterm>
<info>
CVSDIR[doc] = "The directory where cvs checkouts will be stored in."
</info>
<glossdef>
<para role="glossdeffirst">
The directory in which files checked out under the
CVS system are stored.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CXX'><glossterm>CXX</glossterm>
<info>
CXX[doc] = "Minimum command and arguments to run the C++ compiler."
</info>
<glossdef>
<para role="glossdeffirst">
The minimal command and arguments used to run the C++
compiler.
</para>
</glossdef>
</glossentry>
<glossentry id='var-CXXFLAGS'><glossterm>CXXFLAGS</glossterm>
<info>
CXXFLAGS[doc] = "Specifies the flags to pass to the C++ compiler."
</info>
<glossdef>
<para role="glossdeffirst">
Specifies the flags to pass to the C++ compiler.
This variable is exported to an environment
variable and thus made visible to the software being
built during the compilation step.
</para>
<para>
Default initialization for <filename>CXXFLAGS</filename>
varies depending on what is being built:
<itemizedlist>
<listitem><para>
<link linkend='var-TARGET_CXXFLAGS'><filename>TARGET_CXXFLAGS</filename></link>
when building for the target
</para></listitem>
<listitem><para>
<link linkend='var-BUILD_CXXFLAGS'><filename>BUILD_CXXFLAGS</filename></link>
when building for the build host (i.e.
<filename>-native</filename>)
</para></listitem>
<listitem><para>
<link linkend='var-BUILDSDK_CXXFLAGS'><filename>BUILDSDK_CXXFLAGS</filename></link>
when building for an SDK (i.e.
<filename>nativesdk-</filename>)
</para></listitem>
</itemizedlist>
</para>
</glossdef>
</glossentry>