poky: subtree update:c67f57c09e..c6bc20857c
Adrian Freihofer (2):
oe-publish-sdk: fix layers init via ssh
oe-publish-sdk: add --keep-orig option
Alexander Kanavin (68):
meta-selftest: correct the virgl test for 5.8 kernels
bison: upgrade 3.6.4 -> 3.7.1
util-linux: upgrade 2.35.2 -> 2.36
python3-numpy: upgrade 1.19.0 -> 1.19.1
python3-setuptools: upgrade 49.3.1 -> 49.6.0
rsync: upgrade 3.2.2 -> 3.2.3
util-linux: merge .inc into .bb
acpica: upgrade 20200528 -> 20200717
asciidoc: upgrade 9.0.1 -> 9.0.2
cryptodev: upgrade 1.10 -> 1.11
diffoscope: upgrade 153 -> 156
epiphany: upgrade 3.36.3 -> 3.36.4
font-alias: upgrade 1.0.3 -> 1.0.4
gtk+3: upgrade 3.24.21 -> 3.24.22
libcheck: upgrade 0.15.0 -> 0.15.2
libinput: upgrade 1.16.0 -> 1.16.1
libpipeline: upgrade 1.5.2 -> 1.5.3
libx11: upgrade 1.6.9 -> 1.6.11
linux-firmware: upgrade 20200619 -> 20200721
man-pages: upgrade 5.07 -> 5.08
mc: upgrade 4.8.24 -> 4.8.25
mesa: upgrade 20.1.4 -> 20.1.5
piglit: upgrade to latest revision
re2c: upgrade 2.0 -> 2.0.2
sysstat: upgrade 12.2.2 -> 12.4.0
vala: upgrade 0.48.7 -> 0.48.9
bootchart2: update 0.14.8 -> 0.14.9
harfbuzz: convert to meson, enable gobject introspection
pango: update 1.44.7 -> 1.46.0
boost: update 1.73.0 -> 1.74.0
xev: update 1.2.3 -> 1.2.4
wpebackend-fdo: update 1.6.1 -> 1.7.1
gpgme: update 1.13.1 -> 1.14.0
libpsl: update 0.21.0 -> 0.21.1.
gettext: update 0.20.2 -> 0.21
cmake: update 3.17.3 -> 3.18.1
linux-firmware: update 20200721 -> 20200817
meson: update 0.55.0 -> 0.55.1
systemd-boot: bump version to 246.2
json-glib: inherit upstream-version-is-even
packagegroup-core-device-devel: remove
oeqa/x32lib: rework to use readelf from the host
oeqa/multilib: rework to use readelf from the host
oeqa/multilib: un-skip the connman test
poky.conf: do not install packagegroup-core-device-devel into qemu images
glib-2.0: update 2.64.4 -> 2.64.5
cmake: upgrade 3.18.1 -> 3.18.2
libxcrypt: upgrade 4.4.16 -> 4.4.17
debianutils: upgrade 4.11 -> 4.11.1
enchant2: upgrade 2.2.8 -> 2.2.9
harfbuzz: upgrade 2.7.1 -> 2.7.2
libmpc: upgrade 1.1.0 -> 1.2.0
librepo: upgrade 1.12.0 -> 1.12.1
libuv: upgrade 1.38.1 -> 1.39.0
msmtp: upgrade 1.8.11 -> 1.8.12
ninja: upgrade 1.10.0 -> 1.10.1
p11-kit: upgrade 0.23.20 -> 0.23.21
pango: upgrade 1.46.0 -> 1.46.1
re2c: upgrade 2.0.2 -> 2.0.3
resolvconf: upgrade 1.82 -> 1.83
stress-ng: upgrade 0.11.18 -> 0.11.19
gnu-config: update to latest revision
nasm: update 2.15.03 -> 2.15.05
libva-utils: fix upstream version check
gnupg: update 2.2.21 -> 2.2.22
libx11: update 1.6.11 -> 1.6.12
mesa: update 20.1.5 -> 20.1.6
xserver-xorg: update 1.20.8 -> 1.20.9
Andrey Zhizhikin (1):
insane: check for missing update-alternatives inherit
Anibal Limon (1):
recipes-kernel: linux-firmware add qcom-venus-{5.2,5.4} packages
Aníbal Limón (1):
recipes-graphics/xorg-xserver: Add patch to fix segfault when probe
Armin Kuster (2):
bind: update to 9.11.22 ESV
core-image-sato: qemumips use 512 mem
Bruce Ashfield (30):
linux-yocto/5.4: update to v5.4.59
linux-yocto/5.8: update to v5.8.2
yocto-bsp: update to v5.4.56
yocto-bsp: update to v5.4.58
qemu: bump default reference kernel to v5.8
linux-yocto/5.8: fix perf and virtio_scsi warnings
linux-yocto-rt/5.8: fix lttng-modules build
linux-yocto/5.8: selftests/bpf: Prevent runqslower from racing on building bpftool
linux-yocto/5.8: disable CONFIG_NFS_DISABLE_UDP_SUPPORT
poky: set preferred version for linux-yocto to be v5.8
poky-tiny: set preferred version to 5.8
poky: add preferred version for linux-yocto-rt
linux-yocto/5.8: update to v5.8.3
linux-yocto/5.4: update to v5.4.60
kernel: config cleanups for 5.8+
linux-yocto/5.4: update to v5.4.61
linux-yocto/5.8: update to v5.8.4
linux-yocto/5.8: disable IKHEADERS in default builds
kernel-yocto: allow promotion of configuration warnings to errors
kernel-yocto: checksum all modifications to available kernel fragments directories
lttng-modules/devupstream: bump to latest 2.12 commits
linux-yocto-dev: bump to v5.9+
linux-yocto/5.8: update to v5.8.5
kernel-devsrc: account for HOSTCC and HOSTCXX
linux-yocto/config: netfilter: Enable nat for ipv4 and ipv6
linux-yocto/5.8: update to v5.8.8
linux-yocto/5.4: update to v5.4.64
linux-yocto/config: configuration warning cleanup
linux-yocto/5.8: update to v5.8.9
linux-yocto/5.4: update to v5.4.65
Changhyeok Bae (2):
iw: upgrade 5.4 -> 5.8
iputils: upgrade s20190709 -> s20200821
Chris Laplante (12):
bitbake: compat.py: remove file since it no longer actually implements anything
bitbake: COW: formatting
bitbake: COW: migrate test suite into tests/cow
cve-update-db-native: add progress handler
cve-check/cve-update-db-native: use lockfile to fix usage under multiconfig
cve-update-db-native: use context manager for cve_f
cve-check: avoid FileNotFoundError if no do_cve_check task has run
bitbake: utils: process_profilelog: use context manager
bitbake: utils: fix UnboundLocalError when _print_exception raises
cve-update-db-native: be less magical about checking whether the cve-check class is enabled
cve-update-db-native: move -journal checking into do_fetch
cve-update-db-native: remove unused variable
Christophe GUIBOUT (1):
initramfs-framework: support kernel cmdline with double quotes
Denys Dmytriyenko (2):
weston: upgrade 8.0.0 -> 9.0.0
cryptodev: bump 1 commit past 1.11 to fix 5.9-rc1+
Diego Sueiro (2):
license_image.bbclass: Create symlink to the image license manifest dir
license_image.bbclass: Fix symlink to the image license manifest dir creation
Douglas Royds (1):
tcmode-default: Drop gcc-cross-initial, gcc-crosssdk-initial references
Frazer Clews (1):
bitbake: lib: fix most undefined code picked up by pylint
Geoff Parker (1):
systemd-serialgetty: Replace sed quoting using ' with " to allow var expansion
Jacob Kroon (1):
gcc10: Don't default back to -fcommon
Jean-Francois Dagenais (1):
bitbake: siggen: clean_basepath: remove recipe full path when virtual:xyz present
Jens Rehsack (1):
lttng-modules: backport patches from 2.12.x to fix 5.4.64+ and 5.8.9+ builds
Joe Slater (1):
pseudo: fix renaming to self
Jon Mason (4):
cortex-m0plus.inc: change file permissions
tune-cortexa55.inc: clean-up ARMv8.2a uses
tune-cortexa57-cortexa53.inc: add CRC and set march
tune-cortexa*: Cleanups
Joshua Watt (8):
wic: Add 512 Byte alignment to --offset
oeqa: runtime_tests: Extra GPG debugging
oeqa: sdk: Capture stderr output
oeqa: reproducible: Fix test not producing diffs
diffoscope: upgrade 156 -> 158
bitbake: bitbake: Add parsing torture test
bitbake: cooker: Block SIGINT in worker processes
sphinx: dev-manual: Clarify that virtual providers do not apply to runtime dependencies
Kai Kang (1):
dhcpcd: 9.1.4 -> 9.2.0
Kevin Hao (1):
meta-yocto-bsp: Bump to the v5.8 kernel
Khairul Rohaizzat Jamaluddin (1):
wic/bootimg-efi: IMAGE_EFI_BOOT_FILES variable added to separate bootimg-efi and bootimg-partition
Khem Raj (24):
gcc-cross-canadian: Install gcc/g++ wrappers for musl
uninative: Upgrade to 2.9
packagegroup-core-tools-profile: Disable lttng-modules for riscv64
lttng-modules: Disable on riscv64
kexec-tools: Fix build with -fno-common on ppc
lttng-tools: Do not build for riscv64
util-linux: Allow update alternatives for additional apps
lttng-tools: lttng-ust works on riscv64
json-glib: Backport a build fix with clang
rpcbind: Use update-alternatives for rpcinfo
go: Upgrade to 1.15 major release
weston-init: Redefine weston service and add socket activation option
musl: Upgrade to latest master
libucontext: Recognise riscv32 architecture
linuxloader.bbclass: Define riscv32 ldso for musl
populate_sdk_ext: Do not assume local.conf will always exist
weston: plane_add_prop() calls break musl atomic modesetting
weston-init: Enable RDP screen share
weston-init: Do not use fbdev backend
weston-init: Select drm/fbdev backends for qemu machines
oeqa/weston: Fix tests to run with systemd
core-image-weston: Bump qemu memory to 512M
go: Update to 1.15.2 minor release
bind: Inherit update-alternatives
Mark Hatle (6):
package_tar.bbclass: Sync to the other package_* classes
kernel.bbclass: Remove do_install[prefunc] no longer needed
buildhistory.bbclass: Rework to use read_subpackage_metadata
kernel.bbclass: Move away from calling package_get_auto_pr
package.bbclass: hash equivalency and pr service
bitbake: process.py: Handle SystemExit exception to eliminate backtrace
Mark Morton (1):
sphinx: test-manual code block, link, and format update
Martin Jansa (7):
devtool: expand SRC_URI when guessing recipe update mode
image-artifact-names: introduce new bbclass and move some variables into it
kernel.bbclass: use bash variables like imageType, base_name without {}
kernel.bbclass: eliminate (initramfs_)symlink_name variables
kernel.bbclass: use camelCase notation for bash variables in do_deploy
*-initramfs: don't use .rootfs IMAGE_NAME_SUFFIX
bitbake.conf: use ${TCMODE}-${TCLIBC} directory for CACHE
Matt Madison (1):
image.bbclass: fix REPRODUCIBLE_TIMESTAMP_ROOTFS reference
Michael Gloff (2):
sysvinit rc: Use PSPLASH_FIFO_DIR for progress fifo
sysvinit: Remove ${B} assignment
Michael Tretter (1):
devtool: deploy-target: Fix size calculation for hard links
Ming Liu (2):
systemd: split systemd specific udev rules into its own package
libubootenv: inherit uboot-config
Mingli Yu (3):
qemu: always define unknown_lock_type
qemu: override DEBUG_BUILD
bison: remove the parallel build patch
Naveen Saini (1):
lib/oe/recipeutils.py: add support for BBFILES_DYNAMIC
Nicolas Dechesne (73):
linux-libc-headers: kernel headers are installed in STAGING_KERNEL_BUILDDIR
bitbake: sphinx: add initial build infrastructure
bitbake: sphinx: initial sphinx support
bitbake: sphinx: bitbake-user-manual: use builtin sphinx glossary
bitbake: sphinx: switch to readthedocs theme
bitbake: sphinx: override theme CSS
bitbake: sphinx: fixup for links
bitbake: sphinx: fix links inside notes
bitbake: sphinx: fixes all remaining warnings
bitbake: sphinx: Makefile.sphinx: add clean and publish targets
bitbake: sphinx: tweak html output a bit
bitbake: sphinx: add SPDX headers
bitbake: sphinx: index: move the boilerplate at the end of the page
bitbake: sphinx: conf: enable extlinks extension
bitbake: sphinx: add releases page
bitbake: sphinx: bitbake-user-manual: insert additional blank line after title
bitbake: sphinx: last manual round of fixes/improvements
bitbake: sphinx: update style for important, caution and warnings
bitbake: sphinx: remove leading '/'
bitbake: sphinx: theme_override: properly set font for verbatim text
bitbake: bitbake-user-manual: fix bad links
sphinx: add initial build infrastructure
sphinx: initial sphinx support
sphinx: ref-variables: use builtin sphinx glossary
sphinx: overview-manual: add figures
sphinx: switch to readthedocs theme
sphinx: Add SPDX license headers
sphinx: add CSS theme override
sphinx: bsp-guide: add figures
sphinx: add Yocto project logo
sphinx: conf: update copyright
sphinx: conf: add substitutions/global variables
sphinx: add boilerplate file
sphinx: add boilerplate to manuals
sphinx: ref-manual: add revision history table
sphinx: add a general index
sphinx: conf.py: enable sphinx.ext.autosectionlabel
sphinx: ref-manual: use builtin glossary for the Terms section
sphinx: fix internal links
sphinx: ref-manual: fix typo
sphinx: fix custom term links
sphinx: manual updates for some links
sphinx: dev-manual add figures
sphinx: kernel-dev: add figures
sphinx: profile-manual: add figures
sphinx: fix up bold text for informalexample container
sphinx: ref-manual: add figures
sphinx: sdk-manual: add figures
sphinx: test-manual: add figures
sphinx: toaster-manual: add figures
sphinx: add links for Yocto project website
sphinx: fix links when the link text should be displayed
sphinx: add links to terms in the BitBake glossary
sphinx: add links to section in the Bitbake manual
sphinx: setup extlink for docs.yoctoproject.org
sphinx: enable intersphinx extension
sphinx: insert blank below between title and toc
sphinx: fix up terms related to kernel-fitimage
sphinx: conf: a few rendering tweaks
sphinx: makefile: add publish target
sphinx: conf: include CSS/JS files, the proper way
sphinx: convert 'what I wish I'd known'
sphinx: convert 'transitioning to a custom environment'
sphinx: ref-manual: fix heading for oe-init-build-env
sphinx: brief-yoctoprojectqs: fix up all remaining rendering issues
sphinx: Makefile.sphinx improvements
sphinx: convert bsp-guide
sphinx: remove leading '/'
sphinx: update style for important, caution and warnings
sphinx: profile-manual: convert profile-manual
sphinx: theme_override: properly set font for verbatim text
sphinx: theme_override: add tying-it-together admonition
sphinx: conf: exclude adt-manual/*.rst
Oleksandr Kravchuk (1):
ell: update to 0.33
Ovidiu Panait (1):
libxml2: Fix CVE-2020-24977
Peter A. Bigot (2):
bluez5: fix builds that require ell support
timezone: include leap second data in tzdata-core
Peter Bergin (1):
systemd: avoid failing if no udev rules provided
Pierre-Jean Texier (2):
libubootenv: upgrade 0.3 -> 0.3.1
diffoscope: upgrade 158 -> 160
Quentin Schulz (16):
sphinx: brief-yoctoprojectqs: remove redundant welcome
sphinx: brief-yoctoprojectqs: fix ambiguous note for cyclone5 example
sphinx: brief-yoctoprojectqs: add missing boilerplate
sphinx: overview-manual: add link to AUH how-to section
sphinx: overview-manual: fix bitbake basic explanation
sphinx: brief-yoctoprojectqs: add note on branch consistency between layers
sphinx: what-i-wish-id-known: update "don't be fooled by doc search results"
sphinx: overview-manual: remove highlight in bold section
sphinx: replace special quotes with single and double quotes
sphinx: fix incorrect indentations
sphinx: brief-yoctoprojectqs: put other distros note after Ubuntu-specific packages
sphinx: fix a few typos or missing/too many words
sphinx: "highlight" some variables, tasks or files
sphinx: fix or add missing links and remove mention of Eclipse workflow
ref-manual: examples: hello-autotools: upgrade to 2.10
ref-manual: examples: libxpm: add relative path to .inc
Rahul Kumar (1):
systemd-serialgetty: Fix sed expression quoting
Rasmus Villemoes (1):
kernel.bbclass: run do_symlink_kernsrc before do_patch
Richard Purdie (74):
nativesdk-sdk-provides-dummy: Add /bin/sh
bitbake: fetch2/wget: Remove buffering parameter
bitbake: cooker: Ensure parse_quit thread is closed down
bitbake: cooker: Explictly shut down the sync thread
bitbake: fetch2: Drop cups.org from wget status checks
bitbake: build/msg: Cleanup verbose option handling
bitbake: cooker/cookerdata/main: Improve loglevel handling
bitbake: cookerdata: Ensure UI options are updated to the server
bitbake: cooker/cookerdata: Ensure UI event log is updated from commandline
bitbake: cooker: Defer configuration init to after UI connection
bitbake: server/process: Move the socket code to server process only
bitbake: main/server/process: Drop configuration object passing
bitbake: cooker: Ensure BB_ORIGENV is updated by changes to configuration.env
bitbake: server/process: Log extra threads at exit
bitbake: server/process: Add bitbake-server and exec() a new server process
bitbake: runqueue: Don't use sys.argv
bitbake: cooker: Ensure cooker's enviroment is updated on updateConfig
connman-gnome/matchbox-desktop: Remove file:// globbing
selftest/recipetool: Drop globbing SRC_URI test, no longer supported
local.conf.sample: Document memory resident bitbake
bitbake: fetch2: Drop globbing supprt in file:// SRC_URIs
bitbake: server/process: Use sys.executable for bitbake-server
bitbake: process: Avoid bb.utils.timeout
bitbake: utils: Drop broken timeout function
bitbake: server/process: Fix typo in code causing tracebacks
oeqa/selftest: Apply patch to fix cpio build with -fno-common
runqemu: Show an error for conflicting graphics options
lttng: Move platform logic to dedicated inc file
patchelf: upgrade 0.11 -> 0.12
build-appliance/packagegroup-core-base-utils: Replace dhcp-client/dhcp-server with dhcpcd/kea
selftest/prservice: Improve test failure message
iputils: Adapt ${PN}-tftpd package dependency to PACKAGECONFIG
bitbake: process/knotty: Improve early exception handling
bitbake: cooker/cookerdata: Use BBHandledException, not sys.exit()
bitbake: cookerdata: Fix exception raise statements
bitbake: process: Avoid printing binary strings for leftover processes
bitbake: server/process: Ensure logging is flushed
bitbake: server/process: Don't show tracebacks if the lockfile is removed
bitbake: cooker: Ensure parser replacement calls parser final_cleanup
bitbake: cooker: Assign a name to the sync thread to aid debugging
bitbake: server/process: Ensure we don't keep looping if some other server is started
bitbake: server/process: Prefix the log data with pid/time information
bitbake: server/process: Note when commands complete in logs
bitbake: cooker: Ensure parser is cleaned up
runqemu: Add a hook to allow it to renice
bitbake: cooker: Avoid parser deadlocks
bitbake: cooker: Ensure parser worker signal handlers are default
selftest/signing: Ensure build path relocation is safe
oeqa/concurrencytest: Improve builddir path manipulations
bitbake: cooker/command: Fix disconnection handling
bitbake: tinfoil: Ensure sockets don't leak even when exceptions occur
bitbake: tests/fetch: Move away from problematic freedesktop.org urls
bitbake: sphinx: Enhance the sphinx experience/nagivation with:
bitbake: sphinx: theme_override: Use bold for emphasis text
Revert "qemu: always define unknown_lock_type"
Revert "core-image-sato: qemumips use 512 mem"
sphinx: Organize top level docs
sphinx: releases.rst: Add index/links to docs for previous releases
sphinx: boilerplate.rst: Drop versions notes as we have better navigation now
sphinx: boilerplate.rst: Sphinx puts the copyright elsewhere
sphinx: history: Move revision history to its own section
sphinx: manuals: Move boilerplate after toctree
sphinx: Add support for multiple docs version
sphinx: index.rst: Fix links
sphinx: ref-system-requirements: Improve formatting of the notes sections, merging them
sphinx: ref-manual links fixes and many other cleanups to import
sphinx: dev-manual: Various URL, code block and other fixes to imported data
sphinx: sdk-manual: Various URL, code block and other fixes to imported data
sphinx: kernel-dev: Various URL, code block and other fixes to imported data
sphinx: theme_override: Use bold for emphasis text
sphinx: ref-tasks: Add populate_sdk_ext task definition
sphinx: ref-manual/migration: Split each release into its own file
sphinx: overview-manual: Various URL, code block and other fixes to imported data
build-appliance-image: Update to master head revision
Robert Yang (3):
bitbake: cooker.py: Save prioritized BBFILES to BBFILES_PRIORITIZED
bitbake: utils.py: get_file_layer(): Exit the loop when file is matched
bitbake: utils.py: get_file_layer(): Improve performance
Ross Burton (25):
package.bbclass: explode the RPROVIDES so we don't think the versions are provides
elfutils: silence a new QA warning
insane: improve gnu-hash-style warning
gdk-pixbuf: add tests PACKAGECONFIG
debianutils: change SRC_URI to use snapshot.debian.org
insane: only load real files as ELF
autoconf: consolidate SRC_URI
autoconf: consolidate DEPENDS
kea: no need to depend on kea-native
kea: don't use PACKAGECONFIG inappropriately
kea: bump to 1.7.10
help2man: rewrite recipe
local.conf.sample.extended: remove help2man reference
curl: add vendors to CVE_PRODUCT to exclude false positives
harfbuzz: update patch status
harfbuzz: fix a build race around hb-version.h
cmake: whitelist CVE-2016-10642
ncurses: remove config.cache
qemu: fix CVE-2020-14364
cve-update-db-native: remove unused import
cve-update-db-native: add more logging when fetching
cve-update-db-native: use fetch task
alsa-plugins: improve .la removal
sato-screenshot: improve .la removal
buildhistory-diff: use BUILDDIR to know where buildhistory is
Saul Wold (1):
gnupg: uprev 2.2.22 -> 2.2.23
Stacy Gaikovaia (2):
bison: uprev from 3.7.1 to 3.7.2
valgrind: fix memcheck vgtests remove fullpath-after flags
Steve Sakoman (1):
xinput-calibrator: change SRC_URI to branch with libinput support
Sumit Garg (1):
insane: fix gnu-hash-style check
TeohJayShen (1):
oeqa/runtime: add test for matchbox-terminal
Tim Orling (1):
sphinx: toaster-manual: fix vars, links, code blocks
Vijai Kumar K (2):
image_types_wic: Add ASSUME_PROVIDED to WICVARS
wic: misc: Add /bin to the list of searchpaths
Yanfei Xu (1):
kernel-yocto: only replace leading -I in include paths
Yi Zhao (1):
glib-networking: add ptest
Zhixiong Chi (1):
gnutls: CVE-2020-24659
akuster (8):
log4cplus: move meta-oe pkg to core
kea: Move from meta-networking
maintainers.inc: Add me as kea & log4plus maintainer.
dhcpcd: Move from meta-network as OE-Core needs a client
maintainers.inc: Add me as dhcpcd maintainer
dhcp: remove from core
bind: Add 9.16.x
bind: 9.11 remove
hongxu (1):
sysstat: fix installed-vs-shipped QA Issue in systemd
zangrc (4):
libcap:upgrade 2.42 -> 2.43
libcap-ng:upgrade 0.7.10 -> 0.7.11
libgpg-error:upgrade 1.38 -> 1.39
at-spi2-core:upgrade 2.36.0 -> 2.36.1
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I5542f5eea751a2641342e945725fd687cd74bebe
diff --git a/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst b/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
new file mode 100644
index 0000000..fb1b353
--- /dev/null
+++ b/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
@@ -0,0 +1,1372 @@
+.. SPDX-License-Identifier: CC-BY-2.5
+
+==================
+Variables Glossary
+==================
+
+|
+
+This chapter lists common variables used by BitBake and gives an
+overview of their function and contents.
+
+.. note::
+
+ Following are some points regarding the variables listed in this
+ glossary:
+
+ - The variables listed in this glossary are specific to BitBake.
+ Consequently, the descriptions are limited to that context.
+
+ - Also, variables exist in other systems that use BitBake (e.g. The
+ Yocto Project and OpenEmbedded) that have names identical to those
+ found in this glossary. For such cases, the variables in those
+ systems extend the functionality of the variable as it is
+ described here in this glossary.
+
+ - Finally, there are variables mentioned in this glossary that do
+ not appear in the BitBake glossary. These other variables are
+ variables used in systems that use BitBake.
+
+.. glossary::
+
+ ASSUME_PROVIDED
+ Lists recipe names (:term:`PN` values) BitBake does not
+ attempt to build. Instead, BitBake assumes these recipes have already
+ been built.
+
+ In OpenEmbedded-Core, ``ASSUME_PROVIDED`` mostly specifies native
+ tools that should not be built. An example is ``git-native``, which
+ when specified allows for the Git binary from the host to be used
+ rather than building ``git-native``.
+
+ B
+ The directory in which BitBake executes functions during a recipe's
+ build process.
+
+ BB_ALLOWED_NETWORKS
+ 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:
+
+ - This host list is only used if
+ :term:`BB_NO_NETWORK` is either not set or
+ set to "0".
+
+ - Limited support for the "``*``" wildcard character for matching
+ against the beginning of host names exists. For example, the
+ following setting matches ``git.gnu.org``, ``ftp.gnu.org``, and
+ ``foo.git.gnu.org``. ::
+
+ BB_ALLOWED_NETWORKS = "\*.gnu.org"
+
+ .. important::
+
+ The use of the "``*``" 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.
+
+ For example, ``*.foo.bar`` is supported, while ``*aa.foo.bar``
+ is not.
+
+ - Mirrors not in the host list are skipped and logged in debug.
+
+ - Attempts to access networks not in the host list cause a failure.
+
+ Using ``BB_ALLOWED_NETWORKS`` in conjunction with
+ :term:`PREMIRRORS` is very useful. Adding the
+ host you want to use to ``PREMIRRORS`` 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
+ :term:`SRC_URI` statement. This is because the
+ fetcher does not attempt to use the host listed in ``SRC_URI`` after
+ a successful fetch from the ``PREMIRRORS`` occurs.
+
+ BB_CONSOLELOG
+ Specifies the path to a log file into which BitBake's user interface
+ writes output during the build.
+
+ BB_CURRENTTASK
+ Contains the name of the currently running task. The name does not
+ include the ``do_`` prefix.
+
+ BB_DANGLINGAPPENDS_WARNONLY
+ Defines how BitBake handles situations where an append file
+ (``.bbappend``) has no corresponding recipe file (``.bb``). This
+ condition often occurs when layers get out of sync (e.g. ``oe-core``
+ bumps a recipe version and the old recipe no longer exists and the
+ other layer has not been updated to the new version of the recipe
+ yet).
+
+ The default fatal behavior is safest because it is the sane reaction
+ given something is out of sync. It is important to realize when your
+ changes are no longer being applied.
+
+ BB_DEFAULT_TASK
+ The default task to use when none is specified (e.g. with the ``-c``
+ command line option). The task name specified should not include the
+ ``do_`` prefix.
+
+ BB_DISKMON_DIRS
+ Monitors disk space and available inodes during the build and allows
+ you to control the build based on these parameters.
+
+ Disk space monitoring is disabled by default. When setting this
+ variable, use the following form: ::
+
+ BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]"
+
+ where:
+
+ <action> is:
+ ABORT: Immediately abort the build when
+ a threshold is broken.
+ STOPTASKS: Stop the build after the currently
+ executing tasks have finished when
+ a threshold is broken.
+ WARN: Issue a warning but continue the
+ build when a threshold is broken.
+ Subsequent warnings are issued as
+ defined by the
+ BB_DISKMON_WARNINTERVAL variable,
+ which must be defined.
+
+ <dir> is:
+ Any directory you choose. You can specify one or
+ more directories to monitor by separating the
+ groupings with a space. If two directories are
+ on the same device, only the first directory
+ is monitored.
+
+ <threshold> is:
+ Either the minimum available disk space,
+ the minimum number of free inodes, or
+ both. You must specify at least one. To
+ omit one or the other, simply omit the value.
+ Specify the threshold using G, M, K for Gbytes,
+ Mbytes, and Kbytes, respectively. If you do
+ not specify G, M, or K, Kbytes is assumed by
+ default. Do not use GB, MB, or KB.
+
+ Here are some examples: ::
+
+ BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
+ BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
+ BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
+
+ The first example works only if you also set the
+ :term:`BB_DISKMON_WARNINTERVAL`
+ variable. This example causes the build system to immediately abort
+ when either the disk space in ``${TMPDIR}`` drops below 1 Gbyte or
+ the available free inodes drops below 100 Kbytes. Because two
+ directories are provided with the variable, the build system also
+ issues a warning when the disk space in the ``${SSTATE_DIR}``
+ directory drops below 1 Gbyte or the number of free inodes drops
+ below 100 Kbytes. Subsequent warnings are issued during intervals as
+ defined by the ``BB_DISKMON_WARNINTERVAL`` variable.
+
+ The second example stops the build after all currently executing
+ tasks complete when the minimum disk space in the ``${TMPDIR}``
+ directory drops below 1 Gbyte. No disk monitoring occurs for the free
+ inodes in this case.
+
+ The final example immediately aborts the build when the number of
+ free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No
+ disk space monitoring for the directory itself occurs in this case.
+
+ BB_DISKMON_WARNINTERVAL
+ Defines the disk space and free inode warning intervals.
+
+ If you are going to use the ``BB_DISKMON_WARNINTERVAL`` variable, you
+ must also use the :term:`BB_DISKMON_DIRS`
+ variable and define its action as "WARN". During the build,
+ subsequent warnings are issued each time disk space or number of free
+ inodes further reduces by the respective interval.
+
+ If you do not provide a ``BB_DISKMON_WARNINTERVAL`` variable and you
+ do use ``BB_DISKMON_DIRS`` with the "WARN" action, the disk
+ monitoring interval defaults to the following:
+ BB_DISKMON_WARNINTERVAL = "50M,5K"
+
+ When specifying the variable in your configuration file, use the
+ following form: ::
+
+ BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>"
+
+ where:
+
+ <disk_space_interval> is:
+ An interval of memory expressed in either
+ G, M, or K for Gbytes, Mbytes, or Kbytes,
+ respectively. You cannot use GB, MB, or KB.
+
+ <disk_inode_interval> is:
+ An interval of free inodes expressed in either
+ G, M, or K for Gbytes, Mbytes, or Kbytes,
+ respectively. You cannot use GB, MB, or KB.
+
+ Here is an example: ::
+
+ BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
+ BB_DISKMON_WARNINTERVAL = "50M,5K"
+
+ These variables cause BitBake to
+ issue subsequent warnings each time the available disk space further
+ reduces by 50 Mbytes or the number of free inodes further reduces by
+ 5 Kbytes in the ``${SSTATE_DIR}`` directory. Subsequent warnings
+ based on the interval occur each time a respective interval is
+ reached beyond the initial warning (i.e. 1 Gbytes and 100 Kbytes).
+
+ BB_ENV_WHITELIST
+ Specifies the internal whitelist of variables to allow through from
+ the external environment into BitBake's datastore. If the value of
+ this variable is not specified (which is the default), the following
+ list is used: :term:`BBPATH`, :term:`BB_PRESERVE_ENV`,
+ :term:`BB_ENV_WHITELIST`, and :term:`BB_ENV_EXTRAWHITE`.
+
+ .. note::
+
+ You must set this variable in the external environment in order
+ for it to work.
+
+ BB_ENV_EXTRAWHITE
+ Specifies an additional set of variables to allow through (whitelist)
+ from the external environment into BitBake's datastore. This list of
+ variables are on top of the internal list set in
+ :term:`BB_ENV_WHITELIST`.
+
+ .. note::
+
+ You must set this variable in the external environment in order
+ for it to work.
+
+ BB_FETCH_PREMIRRORONLY
+ When set to "1", causes BitBake's fetcher module to only search
+ :term:`PREMIRRORS` for files. BitBake will not
+ search the main :term:`SRC_URI` or
+ :term:`MIRRORS`.
+
+ BB_FILENAME
+ Contains the filename of the recipe that owns the currently running
+ task. For example, if the ``do_fetch`` task that resides in the
+ ``my-recipe.bb`` is executing, the ``BB_FILENAME`` variable contains
+ "/foo/path/my-recipe.bb".
+
+ BBFILES_DYNAMIC
+ Activates content depending on presence of identified layers. You
+ identify the layers by the collections that the layers define.
+
+ Use the ``BBFILES_DYNAMIC`` variable to avoid ``.bbappend`` files whose
+ corresponding ``.bb`` file is in a layer that attempts to modify other
+ layers through ``.bbappend`` but does not want to introduce a hard
+ dependency on those other layers.
+
+ Additionally you can prefix the rule with "!" to add ``.bbappend`` and
+ ``.bb`` files in case a layer is not present. Use this avoid hard
+ dependency on those other layers.
+
+ Use the following form for ``BBFILES_DYNAMIC``: ::
+
+ collection_name:filename_pattern
+
+ The following example identifies two collection names and two filename
+ patterns: ::
+
+ BBFILES_DYNAMIC += "\
+ clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
+ core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
+ "
+
+ When the collection name is prefixed with "!" it will add the file pattern in case
+ the layer is absent: ::
+
+ BBFILES_DYNAMIC += "\
+ !clang-layer:${LAYERDIR}/backfill/meta-clang/*/*/*.bb \
+ "
+
+ This next example shows an error message that occurs because invalid
+ entries are found, which cause parsing to abort: ::
+
+ ERROR: BBFILES_DYNAMIC entries must be of the form {!}<collection name>:<filename pattern>, not:
+ /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
+ /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
+
+ BB_GENERATE_MIRROR_TARBALLS
+ Causes tarballs of the Git repositories, including the Git metadata,
+ to be placed in the :term:`DL_DIR` directory. Anyone
+ wishing to create a source mirror would want to enable this variable.
+
+ For performance reasons, creating and placing tarballs of the Git
+ repositories is not the default action by BitBake. ::
+
+ BB_GENERATE_MIRROR_TARBALLS = "1"
+
+ BB_HASHCONFIG_WHITELIST
+ Lists variables that are excluded from base configuration checksum,
+ which is used to determine if the cache can be reused.
+
+ One of the ways BitBake determines whether to re-parse the main
+ metadata is through checksums of the variables in the datastore of
+ the base configuration data. There are variables that you typically
+ want to exclude when checking whether or not to re-parse and thus
+ rebuild the cache. As an example, you would usually exclude ``TIME``
+ and ``DATE`` because these variables are always changing. If you did
+ not exclude them, BitBake would never reuse the cache.
+
+ BB_HASHBASE_WHITELIST
+ Lists variables that are excluded from checksum and dependency data.
+ Variables that are excluded can therefore change without affecting
+ the checksum mechanism. A common example would be the variable for
+ the path of the build. BitBake's output should not (and usually does
+ not) depend on the directory in which it was built.
+
+ BB_HASHCHECK_FUNCTION
+ Specifies the name of the function to call during the "setscene" part
+ of the task's execution in order to validate the list of task hashes.
+ The function returns the list of setscene tasks that should be
+ executed.
+
+ At this point in the execution of the code, the objective is to
+ quickly verify if a given setscene function is likely to work or not.
+ It's easier to check the list of setscene functions in one pass than
+ to call many individual tasks. The returned list need not be
+ completely accurate. A given setscene task can still later fail.
+ However, the more accurate the data returned, the more efficient the
+ build will be.
+
+ BB_INVALIDCONF
+ Used in combination with the ``ConfigParsed`` event to trigger
+ re-parsing the base metadata (i.e. all the recipes). The
+ ``ConfigParsed`` event can set the variable to trigger the re-parse.
+ You must be careful to avoid recursive loops with this functionality.
+
+ BB_LOGCONFIG
+ Specifies the name of a config file that contains the user logging
+ configuration. See
+ :ref:`bitbake-user-manual/bitbake-user-manual-execution:logging`
+ for additional information
+
+ BB_LOGFMT
+ Specifies the name of the log files saved into
+ ``${``\ :term:`T`\ ``}``. By default, the ``BB_LOGFMT``
+ variable is undefined and the log file names get created using the
+ following form: ::
+
+ log.{task}.{pid}
+
+ If you want to force log files to take a specific name, you can set this
+ variable in a configuration file.
+
+ BB_NICE_LEVEL
+ Allows BitBake to run at a specific priority (i.e. nice level).
+ System permissions usually mean that BitBake can reduce its priority
+ but not raise it again. See :term:`BB_TASK_NICE_LEVEL` for
+ additional information.
+
+ BB_NO_NETWORK
+ Disables network access in the BitBake fetcher modules. With this
+ access disabled, any command that attempts to access the network
+ becomes an error.
+
+ Disabling network access is useful for testing source mirrors,
+ running builds when not connected to the Internet, and when operating
+ in certain kinds of firewall environments.
+
+ BB_NUMBER_THREADS
+ The maximum number of tasks BitBake should run in parallel at any one
+ time. If your host development system supports multiple cores, a good
+ rule of thumb is to set this variable to twice the number of cores.
+
+ BB_NUMBER_PARSE_THREADS
+ Sets the number of threads BitBake uses when parsing. By default, the
+ number of threads is equal to the number of cores on the system.
+
+ BB_ORIGENV
+ Contains a copy of the original external environment in which BitBake
+ was run. The copy is taken before any whitelisted variable values are
+ filtered into BitBake's datastore.
+
+ .. note::
+
+ The contents of this variable is a datastore object that can be
+ queried using the normal datastore operations.
+
+ BB_PRESERVE_ENV
+ Disables whitelisting and instead allows all variables through from
+ the external environment into BitBake's datastore.
+
+ .. note::
+
+ You must set this variable in the external environment in order
+ for it to work.
+
+ BB_RUNFMT
+ Specifies the name of the executable script files (i.e. run files)
+ saved into ``${``\ :term:`T`\ ``}``. By default, the
+ ``BB_RUNFMT`` variable is undefined and the run file names get
+ created using the following form: ::
+
+ run.{task}.{pid}
+
+ If you want to force run files to take a specific name, you can set this
+ variable in a configuration file.
+
+ BB_RUNTASK
+ Contains the name of the currently executing task. The value includes
+ the "do\_" prefix. For example, if the currently executing task is
+ ``do_config``, the value is "do_config".
+
+ BB_SCHEDULER
+ Selects the name of the scheduler to use for the scheduling of
+ BitBake tasks. Three options exist:
+
+ - *basic* - The basic framework from which everything derives. Using
+ this option causes tasks to be ordered numerically as they are
+ parsed.
+
+ - *speed* - Executes tasks first that have more tasks depending on
+ them. The "speed" option is the default.
+
+ - *completion* - Causes the scheduler to try to complete a given
+ recipe once its build has started.
+
+ BB_SCHEDULERS
+ Defines custom schedulers to import. Custom schedulers need to be
+ derived from the ``RunQueueScheduler`` class.
+
+ For information how to select a scheduler, see the
+ :term:`BB_SCHEDULER` variable.
+
+ BB_SETSCENE_DEPVALID
+ Specifies a function BitBake calls that determines whether BitBake
+ requires a setscene dependency to be met.
+
+ When running a setscene task, BitBake needs to know which
+ dependencies of that setscene task also need to be run. Whether
+ dependencies also need to be run is highly dependent on the metadata.
+ The function specified by this variable returns a "True" or "False"
+ depending on whether the dependency needs to be met.
+
+ BB_SETSCENE_VERIFY_FUNCTION2
+ Specifies a function to call that verifies the list of planned task
+ execution before the main task execution happens. The function is
+ called once BitBake has a list of setscene tasks that have run and
+ either succeeded or failed.
+
+ The function allows for a task list check to see if they make sense.
+ Even if BitBake was planning to skip a task, the returned value of
+ the function can force BitBake to run the task, which is necessary
+ under certain metadata defined circumstances.
+
+ BB_SIGNATURE_EXCLUDE_FLAGS
+ Lists variable flags (varflags) that can be safely excluded from
+ checksum and dependency data for keys in the datastore. When
+ generating checksum or dependency data for keys in the datastore, the
+ flags set against that key are normally included in the checksum.
+
+ For more information on varflags, see the
+ ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variable flags`"
+ section.
+
+ BB_SIGNATURE_HANDLER
+ Defines the name of the signature handler BitBake uses. The signature
+ handler defines the way stamp files are created and handled, if and
+ how the signature is incorporated into the stamps, and how the
+ signature itself is generated.
+
+ A new signature handler can be added by injecting a class derived
+ from the ``SignatureGenerator`` class into the global namespace.
+
+ BB_SRCREV_POLICY
+ Defines the behavior of the fetcher when it interacts with source
+ control systems and dynamic source revisions. The
+ ``BB_SRCREV_POLICY`` variable is useful when working without a
+ network.
+
+ The variable can be set using one of two policies:
+
+ - *cache* - Retains the value the system obtained previously rather
+ than querying the source control system each time.
+
+ - *clear* - Queries the source controls system every time. With this
+ policy, there is no cache. The "clear" policy is the default.
+
+ BB_STAMP_POLICY
+ Defines the mode used for how timestamps of stamp files are compared.
+ You can set the variable to one of the following modes:
+
+ - *perfile* - Timestamp comparisons are only made between timestamps
+ of a specific recipe. This is the default mode.
+
+ - *full* - Timestamp comparisons are made for all dependencies.
+
+ - *whitelist* - Identical to "full" mode except timestamp
+ comparisons are made for recipes listed in the
+ :term:`BB_STAMP_WHITELIST` variable.
+
+ .. note::
+
+ Stamp policies are largely obsolete with the introduction of
+ setscene tasks.
+
+ BB_STAMP_WHITELIST
+ Lists files whose stamp file timestamps are compared when the stamp
+ policy mode is set to "whitelist". For information on stamp policies,
+ see the :term:`BB_STAMP_POLICY` variable.
+
+ BB_STRICT_CHECKSUM
+ Sets a more strict checksum mechanism for non-local URLs. Setting
+ this variable to a value causes BitBake to report an error if it
+ encounters a non-local URL that does not have at least one checksum
+ specified.
+
+ BB_TASK_IONICE_LEVEL
+ Allows adjustment of a task's Input/Output priority. During
+ Autobuilder testing, random failures can occur for tasks due to I/O
+ starvation. These failures occur during various QEMU runtime
+ timeouts. You can use the ``BB_TASK_IONICE_LEVEL`` variable to adjust
+ the I/O priority of these tasks.
+
+ .. note::
+
+ This variable works similarly to the :term:`BB_TASK_NICE_LEVEL`
+ variable except with a task's I/O priorities.
+
+ Set the variable as follows: ::
+
+ BB_TASK_IONICE_LEVEL = "class.prio"
+
+ For *class*, the default value is "2", which is a best effort. You can use
+ "1" for realtime and "3" for idle. If you want to use realtime, you
+ must have superuser privileges.
+
+ For *prio*, you can use any value from "0", which is the highest
+ priority, to "7", which is the lowest. The default value is "4". You
+ do not need any special privileges to use this range of priority
+ values.
+
+ .. note::
+
+ In order for your I/O priority settings to take effect, you need the
+ Completely Fair Queuing (CFQ) Scheduler selected for the backing block
+ device. To select the scheduler, use the following command form where
+ device is the device (e.g. sda, sdb, and so forth): ::
+
+ $ sudo sh -c “echo cfq > /sys/block/device/queu/scheduler
+
+ BB_TASK_NICE_LEVEL
+ Allows specific tasks to change their priority (i.e. nice level).
+
+ You can use this variable in combination with task overrides to raise
+ or lower priorities of specific tasks. For example, on the `Yocto
+ Project <http://www.yoctoproject.org>`__ autobuilder, QEMU emulation
+ in images is given a higher priority as compared to build tasks to
+ ensure that images do not suffer timeouts on loaded systems.
+
+ BB_TASKHASH
+ Within an executing task, this variable holds the hash of the task as
+ returned by the currently enabled signature generator.
+
+ BB_VERBOSE_LOGS
+ Controls how verbose BitBake is during builds. If set, shell scripts
+ echo commands and shell script output appears on standard out
+ (stdout).
+
+ BB_WORKERCONTEXT
+ Specifies if the current context is executing a task. BitBake sets
+ this variable to "1" when a task is being executed. The value is not
+ set when the task is in server context during parsing or event
+ handling.
+
+ BBCLASSEXTEND
+ Allows you to extend a recipe so that it builds variants of the
+ software. Some examples of these variants for recipes from the
+ OpenEmbedded-Core metadata are "natives" such as ``quilt-native``,
+ which is a copy of Quilt built to run on the build system; "crosses"
+ such as ``gcc-cross``, which is a compiler built to run on the build
+ machine but produces binaries that run on the target ``MACHINE``;
+ "nativesdk", which targets the SDK machine instead of ``MACHINE``;
+ and "mulitlibs" in the form "``multilib:``\ multilib_name".
+
+ To build a different variant of the recipe with a minimal amount of
+ code, it usually is as simple as adding the variable to your recipe.
+ Here are two examples. The "native" variants are from the
+ OpenEmbedded-Core metadata: ::
+
+ BBCLASSEXTEND =+ "native nativesdk"
+ BBCLASSEXTEND =+ "multilib:multilib_name"
+
+ .. note::
+
+ Internally, the ``BBCLASSEXTEND`` mechanism generates recipe
+ variants by rewriting variable values and applying overrides such
+ as ``_class-native``. For example, to generate a native version of
+ a recipe, a :term:`DEPENDS` on "foo" is
+ rewritten to a ``DEPENDS`` on "foo-native".
+
+ Even when using ``BBCLASSEXTEND``, 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 ``include`` statements are processed when the recipe is
+ parsed.
+
+ BBDEBUG
+ Sets the BitBake debug output level to a specific value as
+ incremented by the ``-D`` command line option.
+
+ .. note::
+
+ You must set this variable in the external environment in order
+ for it to work.
+
+ BBFILE_COLLECTIONS
+ Lists the names of configured layers. These names are used to find
+ the other ``BBFILE_*`` variables. Typically, each layer appends its
+ name to this variable in its ``conf/layer.conf`` file.
+
+ BBFILE_PATTERN
+ Variable that expands to match files from
+ :term:`BBFILES` in a particular layer. This
+ variable is used in the ``conf/layer.conf`` file and must be suffixed
+ with the name of the specific layer (e.g.
+ ``BBFILE_PATTERN_emenlow``).
+
+ BBFILE_PRIORITY
+ Assigns the priority for recipe files in each layer.
+
+ This variable is useful in situations where the same recipe appears
+ in more than one layer. Setting this variable allows you to
+ prioritize a layer against other layers that contain the same recipe
+ - effectively letting you control the precedence for the multiple
+ layers. The precedence established through this variable stands
+ regardless of a recipe's version (:term:`PV` variable).
+ For example, a layer that has a recipe with a higher ``PV`` value but
+ for which the ``BBFILE_PRIORITY`` is set to have a lower precedence
+ still has a lower precedence.
+
+ A larger value for the ``BBFILE_PRIORITY`` variable results in a
+ higher precedence. For example, the value 6 has a higher precedence
+ than the value 5. If not specified, the ``BBFILE_PRIORITY`` variable
+ is set based on layer dependencies (see the ``LAYERDEPENDS`` variable
+ for more information. The default priority, if unspecified for a
+ layer with no dependencies, is the lowest defined priority + 1 (or 1
+ if no priorities are defined).
+
+ .. tip::
+
+ You can use the command bitbake-layers show-layers to list all
+ configured layers along with their priorities.
+
+ BBFILES
+ A space-separated list of recipe files BitBake uses to build
+ software.
+
+ When specifying recipe files, you can pattern match using Python's
+ `glob <https://docs.python.org/3/library/glob.html>`_ syntax.
+ For details on the syntax, see the documentation by following the
+ previous link.
+
+ BBINCLUDED
+ Contains a space-separated list of all of all files that BitBake's
+ parser included during parsing of the current file.
+
+ BBINCLUDELOGS
+ If set to a value, enables printing the task log when reporting a
+ failed task.
+
+ BBINCLUDELOGS_LINES
+ If :term:`BBINCLUDELOGS` 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 ``BBINCLUDELOGS_LINES``,
+ the entire log is printed.
+
+ BBLAYERS
+ Lists the layers to enable during the build. This variable is defined
+ in the ``bblayers.conf`` configuration file in the build directory.
+ Here is an example: ::
+
+ BBLAYERS = " \
+ /home/scottrif/poky/meta \
+ /home/scottrif/poky/meta-yocto \
+ /home/scottrif/poky/meta-yocto-bsp \
+ /home/scottrif/poky/meta-mykernel \
+ "
+
+ This example enables four layers, one of which is a custom, user-defined
+ layer named ``meta-mykernel``.
+
+ BBLAYERS_FETCH_DIR
+ Sets the base location where layers are stored. This setting is used
+ in conjunction with ``bitbake-layers layerindex-fetch`` and tells
+ ``bitbake-layers`` where to place the fetched layers.
+
+ BBMASK
+ Prevents BitBake from processing recipes and recipe append files.
+
+ You can use the ``BBMASK`` variable to "hide" these ``.bb`` and
+ ``.bbappend`` 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.
+
+ 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 http://docs.python.org/3/library/re.html.
+
+ The following example uses a complete regular expression to tell
+ BitBake to ignore all recipe and recipe append files in the
+ ``meta-ti/recipes-misc/`` directory: ::
+
+ BBMASK = "meta-ti/recipes-misc/"
+
+ If you want to mask out multiple directories or recipes, you can
+ specify multiple regular expression fragments. This next example
+ masks out multiple directories and individual recipes: ::
+
+ BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
+ BBMASK += "/meta-oe/recipes-support/"
+ BBMASK += "/meta-foo/.*/openldap"
+ BBMASK += "opencv.*\.bbappend"
+ BBMASK += "lzma"
+
+ .. note::
+
+ When specifying a directory name, use the trailing slash character
+ to ensure you match just that directory name.
+
+ BBMULTICONFIG
+ Enables BitBake to perform multiple configuration builds and lists
+ each separate configuration (multiconfig). You can use this variable
+ to cause BitBake to build multiple targets where each target has a
+ separate configuration. Define ``BBMULTICONFIG`` in your
+ ``conf/local.conf`` configuration file.
+
+ As an example, the following line specifies three multiconfigs, each
+ having a separate configuration file: ::
+
+ BBMULTIFONFIG = "configA configB configC"
+
+ Each configuration file you use must reside in the
+ build directory within a directory named ``conf/multiconfig`` (e.g.
+ build_directory\ ``/conf/multiconfig/configA.conf``).
+
+ For information on how to use ``BBMULTICONFIG`` in an environment
+ that supports building targets with multiple configurations, see the
+ ":ref:`bitbake-user-manual/bitbake-user-manual-intro:executing a multiple configuration build`"
+ section.
+
+ BBPATH
+ Used by BitBake to locate class (``.bbclass``) and configuration
+ (``.conf``) files. This variable is analogous to the ``PATH``
+ variable.
+
+ If you run BitBake from a directory outside of the build directory,
+ you must be sure to set ``BBPATH`` to point to the build directory.
+ Set the variable as you would any environment variable and then run
+ BitBake: ::
+
+ $ BBPATH="build_directory"
+ $ export BBPATH
+ $ bitbake target
+
+ BBSERVER
+ Points to the server that runs memory-resident BitBake. The variable
+ is only used when you employ memory-resident BitBake.
+
+ BBTARGETS
+ Allows you to use a configuration file to add to the list of
+ command-line target recipes you want to build.
+
+ BBVERSIONS
+ Allows a single recipe to build multiple versions of a project from a
+ single recipe file. You also able to specify conditional metadata
+ using the :term:`OVERRIDES` mechanism for a
+ single version or for an optionally named range of versions.
+
+ For more information on ``BBVERSIONS``, see the
+ ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variants - class extension mechanism`"
+ section.
+
+ BITBAKE_UI
+ Used to specify the UI module to use when running BitBake. Using this
+ variable is equivalent to using the ``-u`` command-line option.
+
+ .. note::
+
+ You must set this variable in the external environment in order
+ for it to work.
+
+ BUILDNAME
+ A name assigned to the build. The name defaults to a datetime stamp
+ of when the build was started but can be defined by the metadata.
+
+ BZRDIR
+ The directory in which files checked out of a Bazaar system are
+ stored.
+
+ CACHE
+ Specifies the directory BitBake uses to store a cache of the metadata
+ so it does not need to be parsed every time BitBake is started.
+
+ CVSDIR
+ The directory in which files checked out under the CVS system are
+ stored.
+
+ DEFAULT_PREFERENCE
+ Specifies a weak bias for recipe selection priority.
+
+ The most common usage of this is variable is to set it to "-1" within
+ a recipe for a development version of a piece of software. Using the
+ variable in this way causes the stable version of the recipe to build
+ by default in the absence of ``PREFERRED_VERSION`` being used to
+ build the development version.
+
+ .. note::
+
+ The bias provided by DEFAULT_PREFERENCE is weak and is overridden by
+ :term:`BBFILE_PRIORITY` if that variable is different between two
+ layers that contain different versions of the same recipe.
+
+ DEPENDS
+ Lists a recipe's build-time dependencies (i.e. other recipe files).
+
+ Consider this simple example for two recipes named "a" and "b" that
+ produce similarly named packages. In this example, the ``DEPENDS``
+ statement appears in the "a" recipe: ::
+
+ DEPENDS = "b"
+
+ Here, the dependency is such that the ``do_configure`` task for recipe "a"
+ depends on the ``do_populate_sysroot`` task of recipe "b". This means
+ anything that recipe "b" puts into sysroot is available when recipe "a" is
+ configuring itself.
+
+ For information on runtime dependencies, see the :term:`RDEPENDS`
+ variable.
+
+ DESCRIPTION
+ A long description for the recipe.
+
+ DL_DIR
+ The central download directory used by the build process to store
+ downloads. By default, ``DL_DIR`` gets files suitable for mirroring for
+ everything except Git repositories. If you want tarballs of Git
+ repositories, use the :term:`BB_GENERATE_MIRROR_TARBALLS` variable.
+
+ EXCLUDE_FROM_WORLD
+ Directs BitBake to exclude a recipe from world builds (i.e.
+ ``bitbake world``). During world builds, BitBake locates, parses and
+ builds all recipes found in every layer exposed in the
+ ``bblayers.conf`` configuration file.
+
+ To exclude a recipe from a world build using this variable, set the
+ variable to "1" in the recipe.
+
+ .. note::
+
+ Recipes added to ``EXCLUDE_FROM_WORLD`` may still be built during a world
+ build in order to satisfy dependencies of other recipes. Adding a
+ recipe to ``EXCLUDE_FROM_WORLD`` only ensures that the recipe is not
+ explicitly added to the list of build targets in a world build.
+
+ FAKEROOT
+ Contains the command to use when running a shell script in a fakeroot
+ environment. The ``FAKEROOT`` variable is obsolete and has been
+ replaced by the other ``FAKEROOT*`` variables. See these entries in
+ the glossary for more information.
+
+ FAKEROOTBASEENV
+ Lists environment variables to set when executing the command defined
+ by :term:`FAKEROOTCMD` that starts the
+ bitbake-worker process in the fakeroot environment.
+
+ FAKEROOTCMD
+ Contains the command that starts the bitbake-worker process in the
+ fakeroot environment.
+
+ FAKEROOTDIRS
+ Lists directories to create before running a task in the fakeroot
+ environment.
+
+ FAKEROOTENV
+ Lists environment variables to set when running a task in the
+ fakeroot environment. For additional information on environment
+ variables and the fakeroot environment, see the
+ :term:`FAKEROOTBASEENV` variable.
+
+ FAKEROOTNOENV
+ Lists environment variables to set when running a task that is not in
+ the fakeroot environment. For additional information on environment
+ variables and the fakeroot environment, see the
+ :term:`FAKEROOTENV` variable.
+
+ FETCHCMD
+ Defines the command the BitBake fetcher module executes when running
+ fetch operations. You need to use an override suffix when you use the
+ variable (e.g. ``FETCHCMD_git`` or ``FETCHCMD_svn``).
+
+ FILE
+ Points at the current file. BitBake sets this variable during the
+ parsing process to identify the file being parsed. BitBake also sets
+ this variable when a recipe is being executed to identify the recipe
+ file.
+
+ FILESPATH
+ Specifies directories BitBake uses when searching for patches and
+ files. The "local" fetcher module uses these directories when
+ handling ``file://`` URLs. The variable behaves like a shell ``PATH``
+ environment variable. The value is a colon-separated list of
+ directories that are searched left-to-right in order.
+
+ GITDIR
+ The directory in which a local copy of a Git repository is stored
+ when it is cloned.
+
+ HGDIR
+ The directory in which files checked out of a Mercurial system are
+ stored.
+
+ HOMEPAGE
+ Website where more information about the software the recipe is
+ building can be found.
+
+ INHERIT
+ Causes the named class or classes to be inherited globally. Anonymous
+ functions in the class or classes are not executed for the base
+ configuration and in each individual recipe. The OpenEmbedded build
+ system ignores changes to ``INHERIT`` in individual recipes.
+
+ For more information on ``INHERIT``, see the
+ ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`"
+ section.
+
+ LAYERDEPENDS
+ Lists the layers, separated by spaces, upon which this recipe
+ depends. Optionally, you can specify a specific layer version for a
+ dependency by adding it to the end of the layer name with a colon,
+ (e.g. "anotherlayer:3" to be compared against
+ :term:`LAYERVERSION`\ ``_anotherlayer`` in
+ this case). BitBake produces an error if any dependency is missing or
+ the version numbers do not match exactly (if specified).
+
+ You use this variable in the ``conf/layer.conf`` file. You must also
+ use the specific layer name as a suffix to the variable (e.g.
+ ``LAYERDEPENDS_mylayer``).
+
+ LAYERDIR
+ When used inside the ``layer.conf`` configuration file, this variable
+ provides the path of the current layer. This variable is not
+ available outside of ``layer.conf`` and references are expanded
+ immediately when parsing of the file completes.
+
+ LAYERDIR_RE
+ When used inside the ``layer.conf`` configuration file, this variable
+ provides the path of the current layer, escaped for use in a regular
+ expression (:term:`BBFILE_PATTERN`). This
+ variable is not available outside of ``layer.conf`` and references
+ are expanded immediately when parsing of the file completes.
+
+ LAYERVERSION
+ Optionally specifies the version of a layer as a single number. You
+ can use this variable within
+ :term:`LAYERDEPENDS` for another layer in
+ order to depend on a specific version of the layer.
+
+ You use this variable in the ``conf/layer.conf`` file. You must also
+ use the specific layer name as a suffix to the variable (e.g.
+ ``LAYERDEPENDS_mylayer``).
+
+ LICENSE
+ The list of source licenses for the recipe.
+
+ MIRRORS
+ Specifies additional paths from which BitBake gets source code. When
+ the build system searches for source code, it first tries the local
+ download directory. If that location fails, the build system tries
+ locations defined by :term:`PREMIRRORS`, the
+ upstream source, and then locations specified by ``MIRRORS`` in that
+ order.
+
+ MULTI_PROVIDER_WHITELIST
+ Allows you to suppress BitBake warnings caused when building two
+ separate recipes that provide the same output.
+
+ BitBake normally issues a warning when building two different recipes
+ where each provides the same output. This scenario is usually
+ something the user does not want. However, cases do exist where it
+ makes sense, particularly in the ``virtual/*`` namespace. You can use
+ this variable to suppress BitBake's warnings.
+
+ To use the variable, list provider names (e.g. recipe names,
+ ``virtual/kernel``, and so forth).
+
+ OVERRIDES
+ BitBake uses ``OVERRIDES`` to control what variables are overridden
+ after BitBake parses recipes and configuration files.
+
+ Following is a simple example that uses an overrides list based on
+ machine architectures: OVERRIDES = "arm:x86:mips:powerpc" You can
+ find information on how to use ``OVERRIDES`` in the
+ ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax
+ (overrides)`" section.
+
+ P4DIR
+ The directory in which a local copy of a Perforce depot is stored
+ when it is fetched.
+
+ PACKAGES
+ The list of packages the recipe creates.
+
+ PACKAGES_DYNAMIC
+ A promise that your recipe satisfies runtime dependencies for
+ optional modules that are found in other recipes.
+ ``PACKAGES_DYNAMIC`` does not actually satisfy the dependencies, it
+ only states that they should be satisfied. For example, if a hard,
+ runtime dependency (:term:`RDEPENDS`) of another
+ package is satisfied during the build through the
+ ``PACKAGES_DYNAMIC`` variable, but a package with the module name is
+ never actually produced, then the other package will be broken.
+
+ PE
+ The epoch of the recipe. By default, this variable is unset. The
+ variable is used to make upgrades possible when the versioning scheme
+ changes in some backwards incompatible way.
+
+ PERSISTENT_DIR
+ Specifies the directory BitBake uses to store data that should be
+ preserved between builds. In particular, the data stored is the data
+ that uses BitBake's persistent data API and the data used by the PR
+ Server and PR Service.
+
+ PF
+ Specifies the recipe or package name and includes all version and
+ revision numbers (i.e. ``eglibc-2.13-r20+svnr15508/`` and
+ ``bash-4.2-r1/``).
+
+ PN
+ The recipe name.
+
+ PR
+ The revision of the recipe.
+
+ PREFERRED_PROVIDER
+ Determines which recipe should be given preference when multiple
+ recipes provide the same item. You should always suffix the variable
+ with the name of the provided item, and you should set it to the
+ :term:`PN` of the recipe to which you want to give
+ precedence. Some examples: ::
+
+ PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+ PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
+ PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
+
+ PREFERRED_PROVIDERS
+ Determines which recipe should be given preference for cases where
+ multiple recipes provide the same item. Functionally,
+ ``PREFERRED_PROVIDERS`` is identical to
+ :term:`PREFERRED_PROVIDER`. However, the ``PREFERRED_PROVIDERS`` variable
+ lets you define preferences for multiple situations using the following
+ form: ::
+
+ PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..."
+
+ This form is a convenient replacement for the following: ::
+
+ PREFERRED_PROVIDER_xxx = "yyy"
+ PREFERRED_PROVIDER_aaa = "bbb"
+
+ PREFERRED_VERSION
+ If there are multiple versions of recipes available, this variable
+ determines which recipe should be given preference. You must always
+ suffix the variable with the :term:`PN` you want to
+ select, and you should set :term:`PV` accordingly for
+ precedence.
+
+ The ``PREFERRED_VERSION`` variable supports limited wildcard use
+ through the "``%``" character. You can use the character to match any
+ number of characters, which can be useful when specifying versions
+ that contain long revision numbers that potentially change. Here are
+ two examples: ::
+
+ PREFERRED_VERSION_python = "2.7.3"
+ PREFERRED_VERSION_linux-yocto = "4.12%"
+
+ .. important::
+
+ The use of the " % " character is limited in that it only works at the
+ end of the string. You cannot use the wildcard character in any other
+ location of the string.
+
+ PREMIRRORS
+ Specifies additional paths from which BitBake gets source code. When
+ the build system searches for source code, it first tries the local
+ download directory. If that location fails, the build system tries
+ locations defined by ``PREMIRRORS``, the upstream source, and then
+ locations specified by :term:`MIRRORS` in that order.
+
+ Typically, you would add a specific server for the build system to
+ attempt before any others by adding something like the following to
+ your configuration: ::
+
+ PREMIRRORS_prepend = "\
+ git://.*/.* http://www.yoctoproject.org/sources/ \n \
+ ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+ http://.*/.* http://www.yoctoproject.org/sources/ \n \
+ https://.*/.* http://www.yoctoproject.org/sources/ \n"
+
+ These changes cause the build system to intercept Git, FTP, HTTP, and
+ HTTPS requests and direct them to the ``http://`` sources mirror. You can
+ use ``file://`` URLs to point to local directories or network shares as
+ well.
+
+ PROVIDES
+ A list of aliases by which a particular recipe can be known. By
+ default, a recipe's own ``PN`` is implicitly already in its
+ ``PROVIDES`` list. If a recipe uses ``PROVIDES``, the additional
+ aliases are synonyms for the recipe and can be useful satisfying
+ dependencies of other recipes during the build as specified by
+ ``DEPENDS``.
+
+ Consider the following example ``PROVIDES`` statement from a recipe
+ file ``libav_0.8.11.bb``: ::
+
+ PROVIDES += "libpostproc"
+
+ The ``PROVIDES`` statement results in the "libav" recipe also being known
+ as "libpostproc".
+
+ In addition to providing recipes under alternate names, the
+ ``PROVIDES`` mechanism is also used to implement virtual targets. A
+ virtual target is a name that corresponds to some particular
+ functionality (e.g. a Linux kernel). Recipes that provide the
+ functionality in question list the virtual target in ``PROVIDES``.
+ Recipes that depend on the functionality in question can include the
+ virtual target in :term:`DEPENDS` to leave the
+ choice of provider open.
+
+ Conventionally, virtual targets have names on the form
+ "virtual/function" (e.g. "virtual/kernel"). The slash is simply part
+ of the name and has no syntactical significance.
+
+ PRSERV_HOST
+ The network based :term:`PR` service host and port.
+
+ Following is an example of how the ``PRSERV_HOST`` variable is set: ::
+
+ PRSERV_HOST = "localhost:0"
+
+ You must set the variable if you want to automatically start a local PR
+ service. You can set ``PRSERV_HOST`` to other values to use a remote PR
+ service.
+
+ PV
+ The version of the recipe.
+
+ RDEPENDS
+ Lists a package's runtime dependencies (i.e. other packages) that
+ must be installed in order for the built package to run correctly. If
+ a package in this list cannot be found during the build, you will get
+ a build error.
+
+ Because the ``RDEPENDS`` variable applies to packages being built,
+ you should always use the variable in a form with an attached package
+ name. For example, suppose you are building a development package
+ that depends on the ``perl`` package. In this case, you would use the
+ following ``RDEPENDS`` statement: ::
+
+ RDEPENDS_${PN}-dev += "perl"
+
+ In the example, the development package depends on the ``perl`` package.
+ Thus, the ``RDEPENDS`` variable has the ``${PN}-dev`` package name as part
+ of the variable.
+
+ BitBake supports specifying versioned dependencies. Although the
+ syntax varies depending on the packaging format, BitBake hides these
+ differences from you. Here is the general syntax to specify versions
+ with the ``RDEPENDS`` variable: ::
+
+ RDEPENDS_${PN} = "package (operator version)"
+
+ For ``operator``, you can specify the following: ::
+
+ =
+ <
+ >
+ <=
+ >=
+
+ For example, the following sets up a dependency on version 1.2 or
+ greater of the package ``foo``: ::
+
+ RDEPENDS_${PN} = "foo (>= 1.2)"
+
+ For information on build-time dependencies, see the :term:`DEPENDS`
+ variable.
+
+ REPODIR
+ The directory in which a local copy of a ``google-repo`` directory is
+ stored when it is synced.
+
+ RPROVIDES
+ A list of package name aliases that a package also provides. These
+ aliases are useful for satisfying runtime dependencies of other
+ packages both during the build and on the target (as specified by
+ ``RDEPENDS``).
+
+ As with all package-controlling variables, you must always use the
+ variable in conjunction with a package name override. Here is an
+ example: ::
+
+ RPROVIDES_${PN} = "widget-abi-2"
+
+ RRECOMMENDS
+ A list of packages that extends the usability of a package being
+ built. The package being built does not depend on this list of
+ packages in order to successfully build, but needs them for the
+ extended usability. To specify runtime dependencies for packages, see
+ the ``RDEPENDS`` variable.
+
+ BitBake supports specifying versioned recommends. Although the syntax
+ varies depending on the packaging format, BitBake hides these
+ differences from you. Here is the general syntax to specify versions
+ with the ``RRECOMMENDS`` variable: ::
+
+ RRECOMMENDS_${PN} = "package (operator version)"
+
+ For ``operator``, you can specify the following: ::
+
+ =
+ <
+ >
+ <=
+ >=
+
+ For example, the following sets up a recommend on version
+ 1.2 or greater of the package ``foo``: ::
+
+ RRECOMMENDS_${PN} = "foo (>= 1.2)"
+
+ SECTION
+ The section in which packages should be categorized.
+
+ SRC_URI
+ The list of source files - local or remote. This variable tells
+ BitBake which bits to pull for the build and how to pull them. For
+ example, if the recipe or append file needs to fetch a single tarball
+ from the Internet, the recipe or append file uses a ``SRC_URI`` entry
+ that specifies that tarball. On the other hand, if the recipe or
+ append file needs to fetch a tarball and include a custom file, the
+ recipe or append file needs an ``SRC_URI`` variable that specifies
+ all those sources.
+
+ The following list explains the available URI protocols:
+
+ - ``file://`` : Fetches files, which are usually files shipped
+ with the metadata, from the local machine. The path is relative to
+ the :term:`FILESPATH` variable.
+
+ - ``bzr://`` : Fetches files from a Bazaar revision control
+ repository.
+
+ - ``git://`` : Fetches files from a Git revision control
+ repository.
+
+ - ``osc://`` : Fetches files from an OSC (OpenSUSE Build service)
+ revision control repository.
+
+ - ``repo://`` : Fetches files from a repo (Git) repository.
+
+ - ``http://`` : Fetches files from the Internet using HTTP.
+
+ - ``https://`` : Fetches files from the Internet using HTTPS.
+
+ - ``ftp://`` : Fetches files from the Internet using FTP.
+
+ - ``cvs://`` : Fetches files from a CVS revision control
+ repository.
+
+ - ``hg://`` : Fetches files from a Mercurial (``hg``) revision
+ control repository.
+
+ - ``p4://`` : Fetches files from a Perforce (``p4``) revision
+ control repository.
+
+ - ``ssh://`` : Fetches files from a secure shell.
+
+ - ``svn://`` : Fetches files from a Subversion (``svn``) revision
+ control repository.
+
+ Here are some additional options worth mentioning:
+
+ - ``unpack`` : Controls whether or not to unpack the file if it is
+ an archive. The default action is to unpack the file.
+
+ - ``subdir`` : Places the file (or extracts its contents) into the
+ specified subdirectory. This option is useful for unusual tarballs
+ or other archives that do not have their files already in a
+ subdirectory within the archive.
+
+ - ``name`` : Specifies a name to be used for association with
+ ``SRC_URI`` checksums when you have more than one file specified
+ in ``SRC_URI``.
+
+ - ``downloadfilename`` : Specifies the filename used when storing
+ the downloaded file.
+
+ SRCDATE
+ The date of the source code used to build the package. This variable
+ applies only if the source was fetched from a Source Code Manager
+ (SCM).
+
+ SRCREV
+ The revision of the source code used to build the package. This
+ variable applies only when using Subversion, Git, Mercurial and
+ Bazaar. If you want to build a fixed revision and you want to avoid
+ performing a query on the remote repository every time BitBake parses
+ your recipe, you should specify a ``SRCREV`` that is a full revision
+ identifier and not just a tag.
+
+ SRCREV_FORMAT
+ Helps construct valid :term:`SRCREV` values when
+ multiple source controlled URLs are used in
+ :term:`SRC_URI`.
+
+ The system needs help constructing these values under these
+ circumstances. Each component in the ``SRC_URI`` is assigned a name
+ and these are referenced in the ``SRCREV_FORMAT`` variable. Consider
+ an example with URLs named "machine" and "meta". In this case,
+ ``SRCREV_FORMAT`` could look like "machine_meta" and those names
+ would have the SCM versions substituted into each position. Only one
+ ``AUTOINC`` placeholder is added and if needed. And, this placeholder
+ is placed at the start of the returned string.
+
+ STAMP
+ Specifies the base path used to create recipe stamp files. The path
+ to an actual stamp file is constructed by evaluating this string and
+ then appending additional information.
+
+ STAMPCLEAN
+ Specifies the base path used to create recipe stamp files. Unlike the
+ :term:`STAMP` variable, ``STAMPCLEAN`` can contain
+ wildcards to match the range of files a clean operation should
+ remove. BitBake uses a clean operation to remove any other stamps it
+ should be removing when creating a new stamp.
+
+ SUMMARY
+ A short summary for the recipe, which is 72 characters or less.
+
+ SVNDIR
+ The directory in which files checked out of a Subversion system are
+ stored.
+
+ T
+ Points to a directory were BitBake places temporary files, which
+ consist mostly of task logs and scripts, when building a particular
+ recipe.
+
+ TOPDIR
+ Points to the build directory. BitBake automatically sets this
+ variable.