MIRRORS/poky
1
0
Fork 0
mirror of git://git.yoctoproject.org/poky.git synced 2025-07-19 12:59:02 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs: replace `FOO by :term:FOO` where possible

Browse Source 
If a variable has a glossary entry and some rST files write about those
variables, it's better to point to the glossary entry instead of just
highlighting it by surrounding it with two tick quotes.

This was automated by the following python script:
"""
import re
from pathlib import Path

with open('objects.inv.txt', 'r') as f:
    objects = f.readlines()

with open('bitbake-objects.inv.txt', 'r') as f:
    objects = objects + f.readlines()

re_term = re.compile(r'variables.html#term-([A-Z_0-9]*)')
terms = []

for obj in objects:
    match = re_term.search(obj)
    if match and match.group(1):
        terms.append(match.group(1))

for rst in Path('.').rglob('*.rst'):
    with open(rst, 'r') as f:
        content = "".joing(f.readlines())
    for term in terms:
        content = re.sub(r'``({})``(?!.*\s*[~-]+)'.format(term), r':term:`\1`', content)

    with open(rst, 'w') as f:
        f.write(content)
"""

(From yocto-docs rev: ba49d9babfcb84bc5c26a68c8c3880a1d9c236d3)

Signed-off-by: Quentin Schulz <foss@0leil.net>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Quentin Schulz 2021-05-27 20:41:17 +02:00 committed by Richard Purdie
parent 7a9b74e9d2
commit 7d3f57cfd2
38 changed files with 1087 additions and 1087 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/brief-yoctoprojectqs/index.rst
View File

@ -332,7 +332,7 @@ Follow these steps to add a hardware layer:
#. **Change the Configuration to Build for a Specific Machine:** The
:term:`MACHINE` variable in the
``local.conf`` file specifies the machine for the build. For this
example, set the ``MACHINE`` variable to ``cyclone5``. These
example, set the :term:`MACHINE` variable to ``cyclone5``. These
configurations are used:
https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf.

16
documentation/bsp-guide/bsp.rst
View File

@ -95,11 +95,11 @@ layer and from it build an image. Here is an example::
.. note::
Ordering and :term:`BBFILE_PRIORITY` for the layers listed in ``BBLAYERS``
Ordering and :term:`BBFILE_PRIORITY` for the layers listed in :term:`BBLAYERS`
matter. For example, if multiple layers define a machine configuration, the
OpenEmbedded build system uses the last layer searched given similar layer
priorities. The build system works from the top-down through the layers
listed in ``BBLAYERS``.
listed in :term:`BBLAYERS`.
Some BSPs require or depend on additional layers beyond the BSP's root
layer in order to be functional. In this case, you need to specify these
@ -685,7 +685,7 @@ statements as follows::
.. note::
When the preferred provider is assumed by default, the ``PREFERRED_PROVIDER``
When the preferred provider is assumed by default, the :term:`PREFERRED_PROVIDER`
statement does not appear in the ``"bsp_root_name".conf`` file.
You would use the ``linux-yocto_4.4.bbappend`` file to append specific
@ -1121,15 +1121,15 @@ list describes them in order of preference:
how to use these variables.
If you build as you normally would, without specifying any recipes in
the ``LICENSE_FLAGS_WHITELIST``, the build stops and provides you
the :term:`LICENSE_FLAGS_WHITELIST`, the build stops and provides you
with the list of recipes that you have tried to include in the image
that need entries in the ``LICENSE_FLAGS_WHITELIST``. Once you enter
that need entries in the :term:`LICENSE_FLAGS_WHITELIST`. Once you enter
the appropriate license flags into the whitelist, restart the build
to continue where it left off. During the build, the prompt will not
appear again since you have satisfied the requirement.
Once the appropriate license flags are on the white list in the
``LICENSE_FLAGS_WHITELIST`` variable, you can build the encumbered
:term:`LICENSE_FLAGS_WHITELIST` variable, you can build the encumbered
image with no change at all to the normal build process.
#. *Get a Pre-Built Version of the BSP:* You can get this type of BSP by
@ -1142,7 +1142,7 @@ list describes them in order of preference:
click-through license agreements presented by the website. If you
want to build the image yourself using the recipes contained within
the BSP tarball, you will still need to create an appropriate
``LICENSE_FLAGS_WHITELIST`` to match the encumbered recipes in the
:term:`LICENSE_FLAGS_WHITELIST` to match the encumbered recipes in the
BSP.
.. note::
@ -1405,7 +1405,7 @@ Project Reference Manual.
The BeagleBone development board requires an SPL to boot and that SPL
file type must be MLO. Consequently, the machine configuration needs
to define ``SPL_BINARY`` as ``MLO``.
to define :term:`SPL_BINARY` as ``MLO``.
.. note::

386
documentation/dev-manual/common-tasks.rst
View File

File diff suppressed because it is too large Load Diff

56
documentation/kernel-dev/advanced.rst
View File

@ -46,15 +46,15 @@ linux-yocto recipe.
Every linux-yocto style recipe must define the
:term:`KMACHINE` variable. This
variable is typically set to the same value as the ``MACHINE`` variable,
variable is typically set to the same value as the :term:`MACHINE` variable,
which is used by :term:`BitBake`.
However, in some cases, the variable might instead refer to the
underlying platform of the ``MACHINE``.
underlying platform of the :term:`MACHINE`.
Multiple BSPs can reuse the same ``KMACHINE`` name if they are built
Multiple BSPs can reuse the same :term:`KMACHINE` name if they are built
using the same BSP description. Multiple Corei7-based BSPs could share
the same "intel-corei7-64" value for ``KMACHINE``. It is important to
realize that ``KMACHINE`` is just for kernel mapping, while ``MACHINE``
the same "intel-corei7-64" value for :term:`KMACHINE`. It is important to
realize that :term:`KMACHINE` is just for kernel mapping, while :term:`MACHINE`
is the machine type within a BSP Layer. Even with this distinction,
however, these two variables can hold the same value. See the
":ref:`kernel-dev/advanced:bsp descriptions`" section for more information.
@ -66,7 +66,7 @@ to indicate the branch.
.. note::
You can use the ``KBRANCH`` value to define an alternate branch typically
You can use the :term:`KBRANCH` value to define an alternate branch typically
with a machine override as shown here from the ``meta-yocto-bsp`` layer::
KBRANCH_edgerouter = "standard/edgerouter"
@ -81,8 +81,8 @@ variables:
:term:`LINUX_KERNEL_TYPE`
defines the kernel type to be used in assembling the configuration. If
you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to "standard".
Together with ``KMACHINE``, ``LINUX_KERNEL_TYPE`` defines the search
you do not specify a :term:`LINUX_KERNEL_TYPE`, it defaults to "standard".
Together with :term:`KMACHINE`, :term:`LINUX_KERNEL_TYPE` defines the search
arguments used by the kernel tools to find the appropriate description
within the kernel Metadata with which to build out the sources and
configuration. The linux-yocto recipes define "standard", "tiny", and
@ -90,21 +90,21 @@ configuration. The linux-yocto recipes define "standard", "tiny", and
section for more information on kernel types.
During the build, the kern-tools search for the BSP description file
that most closely matches the ``KMACHINE`` and ``LINUX_KERNEL_TYPE``
that most closely matches the :term:`KMACHINE` and :term:`LINUX_KERNEL_TYPE`
variables passed in from the recipe. The tools use the first BSP
description they find that matches both variables. If the tools cannot find
a match, they issue a warning.
The tools first search for the ``KMACHINE`` and then for the
``LINUX_KERNEL_TYPE``. If the tools cannot find a partial match, they
will use the sources from the ``KBRANCH`` and any configuration
The tools first search for the :term:`KMACHINE` and then for the
:term:`LINUX_KERNEL_TYPE`. If the tools cannot find a partial match, they
will use the sources from the :term:`KBRANCH` and any configuration
specified in the :term:`SRC_URI`.
You can use the
:term:`KERNEL_FEATURES`
variable to include features (configuration fragments, patches, or both)
that are not already included by the ``KMACHINE`` and
``LINUX_KERNEL_TYPE`` variable combination. For example, to include a
that are not already included by the :term:`KMACHINE` and
:term:`LINUX_KERNEL_TYPE` variable combination. For example, to include a
feature specified as "features/netfilter/netfilter.scc", specify::
KERNEL_FEATURES += "features/netfilter/netfilter.scc"
@ -116,7 +116,7 @@ specify::
KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc"
The value of
the entries in ``KERNEL_FEATURES`` are dependent on their location
the entries in :term:`KERNEL_FEATURES` are dependent on their location
within the kernel Metadata itself. The examples here are taken from the
``yocto-kernel-cache`` repository. Each branch of this repository
contains "features" and "cfg" subdirectories at the top-level. For more
@ -344,7 +344,7 @@ as how an additional feature description file is included with the
Typically, features are less granular than configuration fragments and
are more likely than configuration fragments and patches to be the types
of things you want to specify in the ``KERNEL_FEATURES`` variable of the
of things you want to specify in the :term:`KERNEL_FEATURES` variable of the
Linux kernel recipe. See the
":ref:`kernel-dev/advanced:using kernel metadata in a recipe`" section earlier
in the manual.
@ -509,12 +509,12 @@ description as meeting the criteria set by the recipe being built. This
example supports the "beaglebone" machine for the "standard" kernel and
the "arm" architecture.
Be aware that there is no hard link between the ``KTYPE`` variable and a kernel
Be aware that there is no hard link between the :term:`KTYPE` variable and a kernel
type description file. Thus, if you do not have the
kernel type defined in your kernel Metadata as it is here, you only need
to ensure that the
:term:`LINUX_KERNEL_TYPE`
variable in the kernel recipe and the ``KTYPE`` variable in the BSP
variable in the kernel recipe and the :term:`KTYPE` variable in the BSP
description file match.
To separate your kernel policy from your hardware configuration, you
@ -657,7 +657,7 @@ Notice again the three critical variables:
:term:`KMACHINE`,
:term:`KTYPE`, and
:term:`KARCH`. Of these variables, only
``KTYPE`` has changed to specify the "tiny" kernel type.
:term:`KTYPE` has changed to specify the "tiny" kernel type.
Kernel Metadata Location
========================
@ -693,7 +693,7 @@ directory hierarchy below
a linux-yocto recipe or for a Linux kernel recipe derived by copying and
modifying
``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to
a recipe in your layer, ``FILESEXTRAPATHS`` is typically set to
a recipe in your layer, :term:`FILESEXTRAPATHS` is typically set to
``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``.
See the ":ref:`kernel-dev/common:modifying an existing recipe`"
section for more information.
@ -718,10 +718,10 @@ and fetches any files referenced in the ``.scc`` files by the
``include``, ``patch``, or ``kconf`` commands. Because of this, it is
necessary to bump the recipe :term:`PR`
value when changing the content of files not explicitly listed in the
``SRC_URI``.
:term:`SRC_URI`.
If the BSP description is in recipe space, you cannot simply list the
``*.scc`` in the ``SRC_URI`` statement. You need to use the following
``*.scc`` in the :term:`SRC_URI` statement. You need to use the following
form from your kernel append file::
SRC_URI_append_myplatform = " \
@ -735,7 +735,7 @@ When stored outside of the recipe-space, the kernel Metadata files
reside in a separate repository. The OpenEmbedded build system adds the
Metadata to the build as a "type=kmeta" repository through the
:term:`SRC_URI` variable. As an
example, consider the following ``SRC_URI`` statement from the
example, consider the following :term:`SRC_URI` statement from the
``linux-yocto_4.12.bb`` kernel recipe::
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH}; \
@ -744,20 +744,20 @@ example, consider the following ``SRC_URI`` statement from the
``${KMETA}``, in this context, is simply used to name the directory into
which the Git fetcher places the Metadata. This behavior is no different
than any multi-repository ``SRC_URI`` statement used in a recipe (e.g.
than any multi-repository :term:`SRC_URI` statement used in a recipe (e.g.
see the previous section).
You can keep kernel Metadata in a "kernel-cache", which is a directory
containing configuration fragments. As with any Metadata kept outside
the recipe-space, you simply need to use the ``SRC_URI`` statement with
the recipe-space, you simply need to use the :term:`SRC_URI` statement with
the "type=kmeta" attribute. Doing so makes the kernel Metadata available
during the configuration phase.
If you modify the Metadata, you must not forget to update the ``SRCREV``
If you modify the Metadata, you must not forget to update the :term:`SRCREV`
statements in the kernel's recipe. In particular, you need to update the
``SRCREV_meta`` variable to match the commit in the ``KMETA`` branch you
wish to use. Changing the data in these branches and not updating the
``SRCREV`` statements to match will cause the build to fetch an older
:term:`SRCREV` statements to match will cause the build to fetch an older
commit.
Organizing Your Source
@ -820,7 +820,7 @@ patches into a feature.
Once you have a new branch, you can set up your kernel Metadata to use
the branch a couple different ways. In the recipe, you can specify the
new branch as the ``KBRANCH`` to use for the board as follows::
new branch as the :term:`KBRANCH` to use for the board as follows::
KBRANCH = "mynewbranch"

52
documentation/kernel-dev/common.rst
View File

@ -70,7 +70,7 @@ section:
:term:`MACHINE` variable is set to
"qemux86-64", which is fine if you are building for the QEMU emulator
in 64-bit mode. However, if you are not, you need to set the
``MACHINE`` variable appropriately in your ``conf/local.conf`` file
:term:`MACHINE` variable appropriately in your ``conf/local.conf`` file
found in the
:term:`Build Directory` (i.e.
``poky/build`` in this example).
@ -248,7 +248,7 @@ section:
:term:`MACHINE` variable is set to
"qemux86-64", which is fine if you are building for the QEMU emulator
in 64-bit mode. However, if you are not, you need to set the
``MACHINE`` variable appropriately in your ``conf/local.conf`` file
:term:`MACHINE` variable appropriately in your ``conf/local.conf`` file
found in the
:term:`Build Directory` (i.e.
``poky/build`` in this example).
@ -474,7 +474,7 @@ variable as follows::
The path ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``
expands to "linux-yocto" in the current directory for this example. If
you add any new files that modify the kernel recipe and you have
extended ``FILESPATH`` as described above, you must place the files in
extended :term:`FILESPATH` as described above, you must place the files in
your layer in the following area::
your-layer/recipes-kernel/linux/linux-yocto/
@ -553,7 +553,7 @@ the append file.
For example, suppose you had some configuration options in a file called
``network_configs.cfg``. You can place that file inside a directory
named ``linux-yocto`` and then add a ``SRC_URI`` statement such as the
named ``linux-yocto`` and then add a :term:`SRC_URI` statement such as the
following to the append file. When the OpenEmbedded build system builds
the kernel, the configuration options are picked up and applied.
::
@ -563,7 +563,7 @@ the kernel, the configuration options are picked up and applied.
To group related configurations into multiple files, you perform a
similar procedure. Here is an example that groups separate
configurations specifically for Ethernet and graphics into their own
files and adds the configurations by using a ``SRC_URI`` statement like
files and adds the configurations by using a :term:`SRC_URI` statement like
the following in your append file::
SRC_URI += "file://myconfig.cfg \
@ -643,7 +643,7 @@ following lines to the linux-yocto ``.bbappend`` file in your layer::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://defconfig"
The ``SRC_URI`` tells the build system how to search
The :term:`SRC_URI` tells the build system how to search
for the file, while the
:term:`FILESEXTRAPATHS`
extends the :term:`FILESPATH`
@ -684,7 +684,7 @@ with the following content (without indentation)::
CONFIG_SERIAL_CORE_CONSOLE=y
Next, include this
configuration fragment and extend the ``FILESPATH`` variable in your
configuration fragment and extend the :term:`FILESPATH` variable in your
``.bbappend`` file::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@ -722,7 +722,7 @@ form::
KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file"
Here is an example
that assigns the ``KBUILD_DEFCONFIG`` variable based on "raspberrypi2"
that assigns the :term:`KBUILD_DEFCONFIG` variable based on "raspberrypi2"
and provides the path to the "in-tree" ``defconfig`` file to be used for
a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset::
@ -734,7 +734,7 @@ Aside from modifying your kernel recipe and providing your own
a kernel's ``linux-``\ `machine`\ ``.inc`` file). In other words, if the
build system detects a statement that identifies an "out-of-tree"
``defconfig`` file, that statement will override your
``KBUILD_DEFCONFIG`` variable.
:term:`KBUILD_DEFCONFIG` variable.
See the
:term:`KBUILD_DEFCONFIG`
@ -1349,10 +1349,10 @@ be picked up and applied when the kernel is built::
SRC_URI += "file://myconfig.cfg"
As mentioned earlier, you can group related configurations into multiple
files and name them all in the ``SRC_URI`` statement as well. For
files and name them all in the :term:`SRC_URI` statement as well. For
example, you could group separate configurations specifically for
Ethernet and graphics into their own files and add those by using a
``SRC_URI`` statement like the following in your append file::
:term:`SRC_URI` statement like the following in your append file::
SRC_URI += "file://myconfig.cfg \
file://eth.cfg \
@ -1628,11 +1628,11 @@ Here are some basic steps you can use to work with your own sources:
appropriate for your project:
- :term:`SRC_URI`: The
``SRC_URI`` should specify a Git repository that uses one of the
:term:`SRC_URI` should specify a Git repository that uses one of the
supported Git fetcher protocols (i.e. ``file``, ``git``, ``http``,
and so forth). The ``SRC_URI`` variable should also specify either
and so forth). The :term:`SRC_URI` variable should also specify either
a ``defconfig`` file or some configuration fragment files. The
skeleton recipe provides an example ``SRC_URI`` as a syntax
skeleton recipe provides an example :term:`SRC_URI` as a syntax
reference.
- :term:`LINUX_VERSION`:
@ -1650,16 +1650,16 @@ Here are some basic steps you can use to work with your own sources:
indicate to the OpenEmbedded build system that the recipe has
changed.
- :term:`PV`: The default ``PV``
- :term:`PV`: The default :term:`PV`
assignment is typically adequate. It combines the
``LINUX_VERSION`` with the Source Control Manager (SCM) revision
:term:`LINUX_VERSION` with the Source Control Manager (SCM) revision
as derived from the :term:`SRCPV`
variable. The combined results are a string with the following
form::
3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
While lengthy, the extra verbosity in ``PV`` helps ensure you are
While lengthy, the extra verbosity in :term:`PV` helps ensure you are
using the exact sources from which you intend to build.
- :term:`COMPATIBLE_MACHINE`:
@ -1773,7 +1773,7 @@ information to build modules. If your module ``Makefile`` uses a
different variable, you might want to override the
:ref:`ref-tasks-compile` step, or
create a patch to the ``Makefile`` to work with the more typical
``KERNEL_SRC`` or ``KERNEL_PATH`` variables.
:term:`KERNEL_SRC` or :term:`KERNEL_PATH` variables.
After you have prepared your recipe, you will likely want to include the
module in your images. To do this, see the documentation for the
@ -1886,23 +1886,23 @@ build stops. Kernel features are the last elements processed for
configuring and patching the kernel. Therefore, adding features in this
manner is a way to enforce specific features are present and enabled
without needing to do a full audit of any other layer's additions to the
``SRC_URI`` statement.
:term:`SRC_URI` statement.
You add a kernel feature by providing the feature as part of the
``KERNEL_FEATURES`` variable and by providing the path to the feature's
:term:`KERNEL_FEATURES` variable and by providing the path to the feature's
``.scc`` file, which is relative to the root of the kernel Metadata. The
OpenEmbedded build system searches all forms of kernel Metadata on the
``SRC_URI`` statement regardless of whether the Metadata is in the
:term:`SRC_URI` statement regardless of whether the Metadata is in the
"kernel-cache", system kernel Metadata, or a recipe-space Metadata (i.e.
part of the kernel recipe). See the
":ref:`kernel-dev/advanced:kernel metadata location`" section for
additional information.
When you specify the feature's ``.scc`` file on the ``SRC_URI``
When you specify the feature's ``.scc`` file on the :term:`SRC_URI`
statement, the OpenEmbedded build system adds the directory of that
``.scc`` file along with all its subdirectories to the kernel feature
search path. Because subdirectories are searched, you can reference a
single ``.scc`` file in the ``SRC_URI`` statement to reference multiple
single ``.scc`` file in the :term:`SRC_URI` statement to reference multiple
kernel features.
Consider the following example that adds the "test.scc" feature to the
@ -1910,7 +1910,7 @@ build.
1. *Create the Feature File:* Create a ``.scc`` file and locate it just
as you would any other patch file, ``.cfg`` file, or fetcher item you
specify in the ``SRC_URI`` statement.
specify in the :term:`SRC_URI` statement.
.. note::
@ -1937,7 +1937,7 @@ build.
a similarly named configuration fragment file ``test.cfg``.
2. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the
recipe's ``SRC_URI`` statement::
recipe's :term:`SRC_URI` statement::
SRC_URI_append = " file://test.scc"
@ -1945,7 +1945,7 @@ build.
appended to the existing path.
3. *Specify the Feature as a Kernel Feature:* Use the
``KERNEL_FEATURES`` statement to specify the feature as a kernel
:term:`KERNEL_FEATURES` statement to specify the feature as a kernel
feature::
KERNEL_FEATURES_append = " test.scc"

2
documentation/kernel-dev/faq.rst
View File

@ -68,7 +68,7 @@ How do I change the Linux kernel command line?
----------------------------------------------
The Linux kernel command line is
typically specified in the machine config using the ``APPEND`` variable.
typically specified in the machine config using the :term:`APPEND` variable.
For example, you can add some helpful debug information doing the
following::

2
documentation/kernel-dev/maint-appx.rst
View File

@ -104,7 +104,7 @@ patch, or BSP:
repository organized under the "Yocto Linux Kernel" heading in the
:yocto_git:`Yocto Project Source Repositories <>`.
- Areas pointed to by ``SRC_URI`` statements found in kernel recipes.
- Areas pointed to by :term:`SRC_URI` statements found in kernel recipes.
For a typical build, the target of the search is a feature
description in an ``.scc`` file whose name follows this format (e.g.

4
documentation/migration-guides/migration-1.3.rst
View File

@ -125,7 +125,7 @@ Image recipes that previously included ``apps-console-core`` in
:term:`IMAGE_FEATURES` should now include ``splash``
instead to enable the boot-up splash screen. Retaining
``apps-console-core`` will still include the splash screen but generates a
warning. The ``apps-x11-core`` and ``apps-x11-games`` ``IMAGE_FEATURES``
warning. The ``apps-x11-core`` and ``apps-x11-games`` :term:`IMAGE_FEATURES`
features have been removed.
.. _migration-1.3-removed-recipes:
@ -185,7 +185,7 @@ include :term:`PE` as part of the filename::
KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
Because the ``PE`` variable is not set by default, these binary files
Because the :term:`PE` variable is not set by default, these binary files
could result with names that include two dash characters. Here is an
example::

14
documentation/migration-guides/migration-1.4.rst
View File

@ -28,7 +28,7 @@ Differences include the following:
and uninstall script functions ``pkg_preinst``, ``pkg_postinst``,
``pkg_prerm``, and ``pkg_postrm`` should always have a package name
override. For example, use ``RDEPENDS_${PN}`` for the main package
instead of ``RDEPENDS``. BitBake uses more strict checks when it
instead of :term:`RDEPENDS`. BitBake uses more strict checks when it
parses recipes.
.. _migration-1.4-build-behavior:
@ -53,10 +53,10 @@ Differences include the following:
:term:`SRC_URI`, the build system now uses
:term:`FILESOVERRIDES` instead of
:term:`OVERRIDES` for the directory names. In
general, the values previously in ``OVERRIDES`` are now in
``FILESOVERRIDES`` as well. However, if you relied upon an additional
value you previously added to ``OVERRIDES``, you might now need to
add it to ``FILESOVERRIDES`` unless you are already adding it through
general, the values previously in :term:`OVERRIDES` are now in
:term:`FILESOVERRIDES` as well. However, if you relied upon an additional
value you previously added to :term:`OVERRIDES`, you might now need to
add it to :term:`FILESOVERRIDES` unless you are already adding it through
the :term:`MACHINEOVERRIDES` or
:term:`DISTROOVERRIDES` variables, as
appropriate. For more related changes, see the
@ -105,7 +105,7 @@ Variables
The following variables have changed:
- ``SANITY_TESTED_DISTROS``: This variable now uses a distribution
- :term:`SANITY_TESTED_DISTROS`: This variable now uses a distribution
ID, which is composed of the host distributor ID followed by the
release. Previously,
:term:`SANITY_TESTED_DISTROS` was
@ -114,7 +114,7 @@ The following variables have changed:
you are not specifically setting this variable, or if you are
specifically setting it to "".
- ``SRC_URI``: The ``${``\ :term:`PN`\ ``}``,
- :term:`SRC_URI`: The ``${``\ :term:`PN`\ ``}``,
``${``\ :term:`PF`\ ``}``,
``${``\ :term:`P`\ ``}``, and ``FILE_DIRNAME`` directories
have been dropped from the default value of the

22
documentation/migration-guides/migration-1.5.rst
View File

@ -68,7 +68,7 @@ The following changes have been made that relate to BitBake:
- ``${``\ :term:`P`\ ``}`` and
``${``\ :term:`PF`\ ``}`` are no longer added to
:term:`PROVIDES` by default in ``bitbake.conf``.
These version-specific ``PROVIDES`` items were seldom used.
These version-specific :term:`PROVIDES` items were seldom used.
Attempting to use them could result in two versions being built
simultaneously rather than just one version due to the way BitBake
resolves dependencies.
@ -84,9 +84,9 @@ The following changes have been made to the package QA checks:
:term:`WARN_QA` values in your configuration, check
that they contain all of the issues that you wish to be reported.
Previous Yocto Project versions contained a bug that meant that any
item not mentioned in ``ERROR_QA`` or ``WARN_QA`` would be treated as
item not mentioned in :term:`ERROR_QA` or :term:`WARN_QA` would be treated as
a warning. Consequently, several important items were not already in
the default value of ``WARN_QA``. All of the possible QA checks are
the default value of :term:`WARN_QA`. All of the possible QA checks are
now documented in the ":ref:`insane.bbclass <ref-classes-insane>`"
section.
@ -97,7 +97,7 @@ The following changes have been made to the package QA checks:
- If you are using the ``buildhistory`` class, the check for the package
version going backwards is now controlled using a standard QA check.
Thus, if you have customized your ``ERROR_QA`` or ``WARN_QA`` values
Thus, if you have customized your :term:`ERROR_QA` or :term:`WARN_QA` values
and still wish to have this check performed, you should add
"version-going-backwards" to your value for one or the other
variables depending on how you wish it to be handled. See the
@ -129,7 +129,7 @@ The following directory changes exist:
- When buildhistory is enabled, its output is now written under the
:term:`Build Directory` rather than
:term:`TMPDIR`. Doing so makes it easier to delete
``TMPDIR`` and preserve the build history. Additionally, data for
:term:`TMPDIR` and preserve the build history. Additionally, data for
produced SDKs is now split by :term:`IMAGE_NAME`.
- The ``pkgdata`` directory produced as part of the packaging process
@ -157,20 +157,20 @@ major issue in the way the values are used.
The following changes have been made that relate to
:term:`IMAGE_FEATURES`:
- The value of ``IMAGE_FEATURES`` is now validated to ensure invalid
- The value of :term:`IMAGE_FEATURES` is now validated to ensure invalid
feature items are not added. Some users mistakenly add package names
to this variable instead of using
:term:`IMAGE_INSTALL` in order to have the
package added to the image, which does not work. This change is
intended to catch those kinds of situations. Valid ``IMAGE_FEATURES``
intended to catch those kinds of situations. Valid :term:`IMAGE_FEATURES`
are drawn from ``PACKAGE_GROUP`` definitions,
:term:`COMPLEMENTARY_GLOB` and a new
"validitems" varflag on ``IMAGE_FEATURES``. The "validitems" varflag
"validitems" varflag on :term:`IMAGE_FEATURES`. The "validitems" varflag
change allows additional features to be added if they are not
provided using the previous two mechanisms.
- The previously deprecated "apps-console-core" ``IMAGE_FEATURES`` item
is no longer supported. Add "splash" to ``IMAGE_FEATURES`` if you
- The previously deprecated "apps-console-core" :term:`IMAGE_FEATURES` item
is no longer supported. Add "splash" to :term:`IMAGE_FEATURES` if you
wish to have the splash screen enabled, since this is all that
apps-console-core was doing.
@ -285,7 +285,7 @@ Following are changes to ``udev``:
``udev-extraconf`` to your image.
- ``udev`` no longer brings in ``pciutils-ids`` or ``usbutils-ids``
through ``RRECOMMENDS``. These are not needed by ``udev`` itself and
through :term:`RRECOMMENDS`. These are not needed by ``udev`` itself and
removing them saves around 350KB.
.. _migration-1.5-removed-renamed-recipes:

12
documentation/migration-guides/migration-1.6.rst
View File

@ -61,7 +61,7 @@ If you do not specify a branch, BitBake looks in the default "master" branch.
Alternatively, if you need to bypass this check (e.g. if you are
fetching a revision corresponding to a tag that is not on any branch),
you can add ";nobranch=1" to the end of the URL within ``SRC_URI``.
you can add ";nobranch=1" to the end of the URL within :term:`SRC_URI`.
.. _migration-1.6-bitbake-deps:
@ -134,9 +134,9 @@ OpenEmbedded build system variables, see the ":doc:`/ref-manual/variables`" Chap
:term:`TMPDIR` can no longer be on an NFS mount. NFS does
not offer full POSIX locking and inode consistency and can cause
unexpected issues if used to store ``TMPDIR``.
unexpected issues if used to store :term:`TMPDIR`.
The check for this occurs on startup. If ``TMPDIR`` is detected on an
The check for this occurs on startup. If :term:`TMPDIR` is detected on an
NFS mount, an error occurs.
.. _migration-1.6-variable-changes-PRINC:
@ -274,7 +274,7 @@ In addition to ``core-image-basic`` being renamed,
Licensing
---------
The top-level ``LICENSE`` file has been changed to better describe the
The top-level :term:`LICENSE` file has been changed to better describe the
license of the various components of :term:`OpenEmbedded-Core (OE-Core)`. However,
the licensing itself remains unchanged.
@ -284,7 +284,7 @@ recipes point to this file within
``${COREBASE}/LICENSE``) and thus the accompanying checksum must be
changed from 3f40d7994397109285ec7b81fdeb3b58 to
4d92cd373abda3937c2bc47fbc49d690. A better alternative is to have
``LIC_FILES_CHKSUM`` point to a file describing the license that is
:term:`LIC_FILES_CHKSUM` point to a file describing the license that is
distributed with the source that the recipe is building, if possible,
rather than pointing to ``${COREBASE}/LICENSE``.
@ -297,7 +297,7 @@ The "-fpermissive" option has been removed from the default
:term:`CFLAGS` value. You need to take action on
individual recipes that fail when building with this option. You need to
either patch the recipes to fix the issues reported by the compiler, or
you need to add "-fpermissive" to ``CFLAGS`` in the recipes.
you need to add "-fpermissive" to :term:`CFLAGS` in the recipes.
.. _migration-1.6-custom-images:

4
documentation/migration-guides/migration-1.7.rst
View File

@ -140,9 +140,9 @@ part of the variable name. This change not only simplifies usage but
also allows the values of these variables to be appropriately
incorporated into task signatures and thus trigger the appropriate tasks
to re-execute when changed. You should replace any references to
``module_autoload_*`` with ``KERNEL_MODULE_AUTOLOAD``, and add any
``module_autoload_*`` with :term:`KERNEL_MODULE_AUTOLOAD`, and add any
modules for which ``module_conf_*`` is specified to
``KERNEL_MODULE_PROBECONF``.
:term:`KERNEL_MODULE_PROBECONF`.
.. _migration-1.7-qa-check-changes:

4
documentation/migration-guides/migration-1.8.rst
View File

@ -153,8 +153,8 @@ The following QA Check and Validation Changes have occurred:
instead of ``${D}``.
- :term:`S` now needs to be set to a valid value within a
recipe. If ``S`` is not set in the recipe, the directory is not
automatically created. If ``S`` does not point to a directory that
recipe. If :term:`S` is not set in the recipe, the directory is not
automatically created. If :term:`S` does not point to a directory that
exists at the time the :ref:`ref-tasks-unpack` task
finishes, a warning will be shown.

4
documentation/migration-guides/migration-2.0.rst
View File

@ -25,7 +25,7 @@ and the porting guide at
https://gcc.gnu.org/gcc-5/porting_to.html.
Alternatively, you can switch back to GCC 4.9 or 4.8 by setting
``GCCVERSION`` in your configuration, as follows::
:term:`GCCVERSION` in your configuration, as follows::
GCCVERSION = "4.9%"
@ -244,7 +244,7 @@ The following QA checks have been added:
- Added an "invalid-packageconfig" check for any options specified in
:term:`PACKAGECONFIG` that do not match any
``PACKAGECONFIG`` option defined for the recipe.
:term:`PACKAGECONFIG` option defined for the recipe.
.. _migration-2.0-miscellaneous:

8
documentation/migration-guides/migration-2.1.rst
View File

@ -28,8 +28,8 @@ characters. This practice is now a requirement as BitBake's datastore
now assumes lower-case characters in order to give a slight performance
boost during parsing. In practical terms, this requirement means that
anything that ends up in :term:`OVERRIDES` must now
appear in lower-case characters (e.g. values for ``MACHINE``,
``TARGET_ARCH``, ``DISTRO``, and also recipe names if
appear in lower-case characters (e.g. values for :term:`MACHINE`,
:term:`TARGET_ARCH`, :term:`DISTRO`, and also recipe names if
``_pn-``\ recipename overrides are to be effective).
.. _migration-2.1-expand-parameter-to-getvar-and-getvarflag-now-mandatory:
@ -68,7 +68,7 @@ was a historical accident that has required many classes (e.g.
to work with sensible build systems. When upgrading to the release, you
must edit any recipe that relies upon this old default by either setting
``EXTRA_OEMAKE`` back to "-e MAKEFLAGS=" or by explicitly setting any
required variable value overrides using ``EXTRA_OEMAKE``, which is
required variable value overrides using :term:`EXTRA_OEMAKE`, which is
typically only needed when a Makefile sets a default value for a
variable that is inappropriate for cross-compilation using the "="
operator rather than the "?=" operator.
@ -376,7 +376,7 @@ These additional changes exist:
run-postinsts
With the Yocto Project 2.1 release, these packages are
only removed if "read-only-rootfs" is in ``IMAGE_FEATURES``, since
only removed if "read-only-rootfs" is in :term:`IMAGE_FEATURES`, since
they might still be needed for a read-write image even in the absence
of a package manager (e.g. if users need to be added, modified, or
removed at runtime).

6
documentation/migration-guides/migration-2.2.rst
View File

@ -239,7 +239,7 @@ to catch recipes that are building software without using the
OpenEmbedded :term:`LDFLAGS`. This change could result in
seeing some "No GNU_HASH in the elf binary" QA issues when building such
recipes. You need to fix these recipes so that they use the expected
``LDFLAGS``. Depending on how the software is built, the build system
:term:`LDFLAGS`. Depending on how the software is built, the build system
used by the software (e.g. a Makefile) might need to be patched.
However, sometimes making this fix is as simple as adding the following
to the recipe::
@ -291,7 +291,7 @@ The following changes took place for BitBake:
:term:`SRC_URI` parameters to specify these. This
change is more in-line with how the other fetchers work for source
control systems. Recipes that fetch from Perforce will need to be
updated to use ``SRCREV`` in place of specifying the source revision
updated to use :term:`SRCREV` in place of specifying the source revision
within ``SRC_URI``.
- Some of BitBake's internal code structures for accessing the recipe
@ -308,7 +308,7 @@ The following changes took place for BitBake:
to cause any problems for most users. However, the setscene
verification function as pointed to by
``BB_SETSCENE_VERIFY_FUNCTION`` needed to change signature.
Consequently, a new variable named ``BB_SETSCENE_VERIFY_FUNCTION2``
Consequently, a new variable named :term:`BB_SETSCENE_VERIFY_FUNCTION2`
has been added allowing multiple versions of BitBake to work with
suitably written metadata, which includes OpenEmbedded-Core and Poky.
Anyone with custom BitBake task scheduler code might also need to

20
documentation/migration-guides/migration-2.3.rst
View File

@ -35,7 +35,7 @@ Consider the following:
As an example, see the ``dbus`` recipe. You will see that this recipe
has a ``pkg_postinst`` that calls ``systemctl`` if "systemd" is in
:term:`DISTRO_FEATURES`. In the example,
``systemd-systemctl-native`` is added to ``PACKAGE_WRITE_DEPS``,
``systemd-systemctl-native`` is added to :term:`PACKAGE_WRITE_DEPS`,
which is also conditional on "systemd" being in ``DISTRO_FEATURES``.
- Examine Recipes that Use ``SSTATEPOSTINSTFUNCS``: You need to
@ -136,7 +136,7 @@ The following changes to scripts took place:
removed because the script was found to be deleting files it should
not have, which lead to broken build trees. Rather than trying to
delete portions of :term:`TMPDIR` and getting it wrong,
it is recommended that you delete ``TMPDIR`` and have it restored
it is recommended that you delete :term:`TMPDIR` and have it restored
from shared state (sstate) on subsequent builds.
- ``wipe-sysroot``: The ``wipe-sysroot`` script has been removed as
@ -200,10 +200,10 @@ The following changes took place for BitBake:
section in the BitBake
User Manual for additional information.
- ``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2``
- ``BB_SETSCENE_VERIFY_FUNCTION`` and :term:`BB_SETSCENE_VERIFY_FUNCTION2`
Removed: Because the mechanism they were part of is no longer
necessary with recipe-specific sysroots, the
``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2``
``BB_SETSCENE_VERIFY_FUNCTION`` and :term:`BB_SETSCENE_VERIFY_FUNCTION2`
variables have been removed.
.. _migration-2.3-absolute-symlinks:
@ -426,10 +426,10 @@ The following miscellaneous changes have occurred:
- If the :term:`DISTRO_VERSION` value contains
the value of the :term:`DATE` variable, which is the
default between Poky releases, the ``DATE`` value is explicitly
default between Poky releases, the :term:`DATE` value is explicitly
excluded from ``/etc/issue`` and ``/etc/issue.net``, which is
displayed at the login prompt, in order to avoid conflicts with
Multilib enabled. Regardless, the ``DATE`` value is inaccurate if the
Multilib enabled. Regardless, the :term:`DATE` value is inaccurate if the
``base-files`` recipe is restored from shared state (sstate) rather
than rebuilt.
@ -451,7 +451,7 @@ The following miscellaneous changes have occurred:
tools.
- The ``USE_LDCONFIG`` variable has been replaced with the "ldconfig"
``DISTRO_FEATURES`` feature. Distributions that previously set::
:term:`DISTRO_FEATURES` feature. Distributions that previously set::
USE_LDCONFIG = "0"
@ -494,12 +494,12 @@ The following miscellaneous changes have occurred:
information.
- All native and nativesdk recipes now use a separate
``DISTRO_FEATURES`` value instead of sharing the value used by
:term:`DISTRO_FEATURES` value instead of sharing the value used by
recipes for the target, in order to avoid unnecessary rebuilds.
The ``DISTRO_FEATURES`` for ``native`` recipes is
The :term:`DISTRO_FEATURES` for ``native`` recipes is
:term:`DISTRO_FEATURES_NATIVE` added to
an intersection of ``DISTRO_FEATURES`` and
an intersection of :term:`DISTRO_FEATURES` and
:term:`DISTRO_FEATURES_FILTER_NATIVE`.
For nativesdk recipes, the corresponding variables are

4
documentation/migration-guides/migration-2.4.rst
View File

@ -63,7 +63,7 @@ occurred:
- The ``ionice`` program is now packaged in a separate
"util-linux-ionice" package. The main ``util-linux`` package has a
recommended runtime dependency (i.e. ``RRECOMMENDS``) on the
recommended runtime dependency (i.e. :term:`RRECOMMENDS`) on the
``util-linux-ionice`` package.
- ``initscripts``: The ``sushell`` program is now packaged in a
@ -71,7 +71,7 @@ occurred:
systems to pull ``sushell`` in when ``selinux`` is enabled. The
change also eliminates needing to pull in the entire ``initscripts``
package. The main ``initscripts`` package has a runtime dependency
(i.e. ``RDEPENDS``) on the ``sushell`` package when "selinux" is in
(i.e. :term:`RDEPENDS`) on the ``sushell`` package when "selinux" is in
``DISTRO_FEATURES``.
- ``glib-2.0``: The ``glib-2.0`` package now has a recommended

2
documentation/migration-guides/migration-2.5.rst
View File

@ -281,7 +281,7 @@ The following are additional changes:
``IMAGE_FSTYPES``.
- Recipes with an unconditional dependency on ``libpam`` are only
buildable with ``pam`` in ``DISTRO_FEATURES``. If the dependency is
buildable with ``pam`` in :term:`DISTRO_FEATURES`. If the dependency is
truly optional then it is recommended that the dependency be
conditional upon ``pam`` being in ``DISTRO_FEATURES``.

22
documentation/migration-guides/migration-2.6.rst
View File

@ -156,11 +156,11 @@ Image/Kernel Artifact Naming Changes
The following changes have been made:
- Name variables (e.g. :term:`IMAGE_NAME`) use a new
``IMAGE_VERSION_SUFFIX`` variable instead of
:term:`DATETIME`. Using ``IMAGE_VERSION_SUFFIX``
:term:`IMAGE_VERSION_SUFFIX` variable instead of
:term:`DATETIME`. Using :term:`IMAGE_VERSION_SUFFIX`
allows easier and more direct changes.
The ``IMAGE_VERSION_SUFFIX`` variable is set in the ``bitbake.conf``
The :term:`IMAGE_VERSION_SUFFIX` variable is set in the ``bitbake.conf``
configuration file as follows::
IMAGE_VERSION_SUFFIX = "-${DATETIME}"
@ -212,19 +212,19 @@ The following changes have been made:
The :term:`SERIAL_CONSOLE` variable has been
functionally replaced by the
:term:`SERIAL_CONSOLES` variable for some time.
With the Yocto Project 2.6 release, ``SERIAL_CONSOLE`` has been
With the Yocto Project 2.6 release, :term:`SERIAL_CONSOLE` has been
officially deprecated.
``SERIAL_CONSOLE`` will continue to work as before for the 2.6 release.
:term:`SERIAL_CONSOLE` will continue to work as before for the 2.6 release.
However, for the sake of future compatibility, it is recommended that
you replace all instances of ``SERIAL_CONSOLE`` with
``SERIAL_CONSOLES``.
you replace all instances of :term:`SERIAL_CONSOLE` with
:term:`SERIAL_CONSOLES`.
.. note::
The only difference in usage is that ``SERIAL_CONSOLES``
The only difference in usage is that :term:`SERIAL_CONSOLES`
expects entries to be separated using semicolons as compared to
``SERIAL_CONSOLE``, which expects spaces.
:term:`SERIAL_CONSOLE`, which expects spaces.
.. _migration-2.6-poky-sets-unknown-configure-option-to-qa-error:
@ -387,14 +387,14 @@ QEMU (i.e. "qemu-usermode" is in
default).
If you wish to disable Python profile-guided optimization regardless of
the value of ``MACHINE_FEATURES``, then ensure that
the value of :term:`MACHINE_FEATURES`, then ensure that
:term:`PACKAGECONFIG` for the ``python3`` recipe
does not contain "pgo". You could accomplish the latter using the
following at the configuration level::
PACKAGECONFIG_remove_pn-python3 = "pgo"
Alternatively, you can set ``PACKAGECONFIG`` using an append file
Alternatively, you can set :term:`PACKAGECONFIG` using an append file
for the ``python3`` recipe.
.. _migration-2.6-miscellaneous-changes:

2
documentation/migration-guides/migration-2.7.rst
View File

@ -91,7 +91,7 @@ This section provides information about packaging changes.
package_name\ ``-src``). If you are currently using ``dbg-pkgs`` in
:term:`IMAGE_FEATURES` to bring in debug
symbols and you still need the sources, you must now also add
``src-pkgs`` to ``IMAGE_FEATURES``. Source packages remain in the
``src-pkgs`` to :term:`IMAGE_FEATURES`. Source packages remain in the
target portion of the SDK by default, unless you have set your own
value for :term:`SDKIMAGE_FEATURES` that
does not include ``src-pkgs``.

2
documentation/migration-guides/migration-3.1.rst
View File

@ -260,7 +260,7 @@ Miscellaneous changes
---------------------
- The undocumented ``SRC_DISTRIBUTE_LICENSES`` variable has now been
removed in favour of a new ``AVAILABLE_LICENSES`` variable which is
removed in favour of a new :term:`AVAILABLE_LICENSES` variable which is
dynamically set based upon license files found in
``${COMMON_LICENSE_DIR}`` and ``${LICENSE_PATH}``.

6
documentation/migration-guides/migration-3.2.rst
View File

@ -62,10 +62,10 @@ There is a possible complication where some existing recipe may break, for
example, a recipe was found to be writing to ``${B}/install`` for
``make install`` in ``do_install`` and since ``${B}`` is listed as not to be tracked,
there were errors trying to ``chown root`` for files in this location. Another
example was the ``tcl`` recipe where the source directory ``S`` is set to a
example was the ``tcl`` recipe where the source directory :term:`S` is set to a
subdirectory of the source tree but files were written out to the directory
structure above that subdirectory. For these types of cases in your own recipes,
extend ``PSEUDO_IGNORE_PATHS`` to cover additional paths that pseudo should not
extend :term:`PSEUDO_IGNORE_PATHS` to cover additional paths that pseudo should not
be monitoring.
In addition, pseudo's behaviour on mismatches has now been changed - rather
@ -207,7 +207,7 @@ files into a subdirectory and reference that instead.
deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
----------------------------------------------------------
``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of ``DEPLOYDIR`` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
Most recipes and classes that inherit the ``deploy`` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` - these should be refactored to use ``do_deploy_prepend`` instead.

72
documentation/overview-manual/concepts.rst
View File

@ -332,7 +332,7 @@ created by an autobuilder:
One useful scenario for using the ``conf/site.conf`` file is to
extend your :term:`BBPATH` variable
to include the path to a ``conf/site.conf``. Then, when BitBake looks
for Metadata using ``BBPATH``, it finds the ``conf/site.conf`` file
for Metadata using :term:`BBPATH`, it finds the ``conf/site.conf`` file
and applies your common configurations found in the file. To override
configurations in a particular build directory, alter the similar
configurations within that build directory's ``conf/local.conf``
@ -532,7 +532,7 @@ to build software. A combination of the two is also possible.
BitBake uses the :term:`SRC_URI`
variable to point to source files regardless of their location. Each
recipe must have a ``SRC_URI`` variable that points to the source.
recipe must have a :term:`SRC_URI` variable that points to the source.
Another area that plays a significant role in where source files come
from is pointed to by the
@ -540,13 +540,13 @@ from is pointed to by the
a cache that can hold previously downloaded source. You can also
instruct the OpenEmbedded build system to create tarballs from Git
repositories, which is not the default behavior, and store them in the
``DL_DIR`` by using the
:term:`DL_DIR` by using the
:term:`BB_GENERATE_MIRROR_TARBALLS`
variable.
Judicious use of a ``DL_DIR`` directory can save the build system a trip
Judicious use of a :term:`DL_DIR` directory can save the build system a trip
across the Internet when looking for files. A good method for using a
download directory is to have ``DL_DIR`` point to an area outside of
download directory is to have :term:`DL_DIR` point to an area outside of
your Build Directory. Doing so allows you to safely delete the Build
Directory if needed without fear of removing any downloaded source file.
@ -747,7 +747,7 @@ Build Directory's hierarchy:
architecture of the built package or packages. Depending on the
eventual destination of the package or packages (i.e. machine
architecture, :term:`Build Host`, SDK, or
specific machine), ``PACKAGE_ARCH`` varies. See the variable's
specific machine), :term:`PACKAGE_ARCH` varies. See the variable's
description for details.
- :term:`TARGET_OS`: The operating
@ -756,7 +756,7 @@ Build Directory's hierarchy:
- :term:`PN`: The name of the recipe used
to build the package. This variable can have multiple meanings.
However, when used in the context of input files, ``PN`` represents
However, when used in the context of input files, :term:`PN` represents
the name of the recipe.
- :term:`WORKDIR`: The location
@ -773,7 +773,7 @@ Build Directory's hierarchy:
files for a given recipe.
- :term:`BPN`: The name of the recipe
used to build the package. The ``BPN`` variable is a version of
used to build the package. The :term:`BPN` variable is a version of
the ``PN`` variable but with common prefixes and suffixes removed.
- :term:`PV`: The version of the
@ -803,13 +803,13 @@ and the :term:`FILESPATH` variable
to locate applicable patch files.
Default processing for patch files assumes the files have either
``*.patch`` or ``*.diff`` file types. You can use ``SRC_URI`` parameters
``*.patch`` or ``*.diff`` file types. You can use :term:`SRC_URI` parameters
to change the way the build system recognizes patch files. See the
:ref:`ref-tasks-patch` task for more
information.
BitBake finds and applies multiple patches for a single recipe in the
order in which it locates the patches. The ``FILESPATH`` variable
order in which it locates the patches. The :term:`FILESPATH` variable
defines the default set of directories that the build system uses to
search for patch files. Once found, patches are applied to the recipe's
source files, which are located in the
@ -877,12 +877,12 @@ This step in the build process consists of the following tasks:
:ref:`ref-tasks-compile` task.
Compilation occurs in the directory pointed to by the
:term:`B` variable. Realize that the
``B`` directory is, by default, the same as the
:term:`B` directory is, by default, the same as the
:term:`S` directory.
- *do_install*: After compilation completes, BitBake executes the
:ref:`ref-tasks-install` task.
This task copies files from the ``B`` directory and places them in a
This task copies files from the :term:`B` directory and places them in a
holding area pointed to by the :term:`D`
variable. Packaging occurs later using files from this holding
directory.
@ -928,7 +928,7 @@ the analysis and package splitting process use several areas:
- :term:`PKGDATA_DIR`: A shared,
global-state directory that holds packaging metadata generated during
the packaging process. The packaging process copies metadata from
``PKGDESTWORK`` to the ``PKGDATA_DIR`` area where it becomes globally
:term:`PKGDESTWORK` to the :term:`PKGDATA_DIR` area where it becomes globally
available.
- :term:`STAGING_DIR_HOST`:
@ -1008,7 +1008,7 @@ actually install:
With :term:`IMAGE_ROOTFS`
pointing to the location of the filesystem under construction and the
``PACKAGE_INSTALL`` variable providing the final list of packages to
:term:`PACKAGE_INSTALL` variable providing the final list of packages to
install, the root file system is created.
Package installation is under control of the package manager (e.g.
@ -1057,7 +1057,7 @@ based on the image types specified in the
The process turns everything into an image file or a set of image files
and can compress the root filesystem image to reduce the overall size of
the image. The formats used for the root filesystem depend on the
``IMAGE_FSTYPES`` variable. Compression depends on whether the formats
:term:`IMAGE_FSTYPES` variable. Compression depends on whether the formats
support compression.
As an example, a dynamically created task when creating a particular
@ -1066,7 +1066,7 @@ image type would take the following form::
do_image_type
So, if the type
as specified by the ``IMAGE_FSTYPES`` were ``ext4``, the dynamically
as specified by the :term:`IMAGE_FSTYPES` were ``ext4``, the dynamically
generated task would be as follows::
do_image_ext4
@ -1171,9 +1171,9 @@ the task is rerun.
the sstate cache mechanism adds is a way to cache task output that
can then be shared between build machines.
Since ``STAMPS_DIR`` is usually a subdirectory of ``TMPDIR``, removing
``TMPDIR`` will also remove ``STAMPS_DIR``, which means tasks will
properly be rerun to repopulate ``TMPDIR``.
Since :term:`STAMPS_DIR` is usually a subdirectory of :term:`TMPDIR`, removing
:term:`TMPDIR` will also remove :term:`STAMPS_DIR`, which means tasks will
properly be rerun to repopulate :term:`TMPDIR`.
If you want some task to always be considered "out of date", you can
mark it with the :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`
@ -1408,7 +1408,7 @@ This next list, shows the variables associated with a standard SDK:
- :term:`TOOLCHAIN_HOST_TASK`:
Lists packages that make up the host part of the SDK (i.e. the part
that runs on the ``SDKMACHINE``). When you use
that runs on the :term:`SDKMACHINE`). When you use
``bitbake -c populate_sdk imagename`` to create the SDK, a set of
default packages apply. This variable allows you to add more
packages.
@ -1614,7 +1614,7 @@ them if they are deemed to be valid.
:term:`PR` information as part of
the shared state packages. Consequently, there are considerations that
affect maintaining shared state feeds. For information on how the
build system works with packages and can track incrementing ``PR``
build system works with packages and can track incrementing :term:`PR`
information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
section in the Yocto Project Development Tasks Manual.
@ -1671,8 +1671,8 @@ objective of making native or cross packages relocatable.
build host. However, cross packages generate output for the target
architecture.
The checksum therefore needs to exclude ``WORKDIR``. The simplistic
approach for excluding the work directory is to set ``WORKDIR`` to some
The checksum therefore needs to exclude :term:`WORKDIR`. The simplistic
approach for excluding the work directory is to set :term:`WORKDIR` to some
fixed value and create the checksum for the "run" script.
Another problem results from the "run" scripts containing functions that
@ -1690,7 +1690,7 @@ contains code that first figures out the variable and function
dependencies, and then creates a checksum for the data used as the input
to the task.
Like the ``WORKDIR`` case, there can be situations where dependencies should be
Like the :term:`WORKDIR` case, there can be situations where dependencies should be
ignored. For these situations, you can instruct the build process to
ignore a dependency by using a line like the following::
@ -1707,7 +1707,7 @@ following::
PACKAGE_ARCHS[vardeps] = "MACHINE"
This example explicitly
adds the ``MACHINE`` variable as a dependency for ``PACKAGE_ARCHS``.
adds the :term:`MACHINE` variable as a dependency for :term:`PACKAGE_ARCHS`.
As an example, consider a case with in-line Python where BitBake is not
able to figure out dependencies. When running in debug mode (i.e. using
@ -1761,7 +1761,7 @@ through this setting in the ``bitbake.conf`` file::
BB_SIGNATURE_HANDLER ?= "OEBasicHash"
The "OEBasicHash" ``BB_SIGNATURE_HANDLER`` is the same
The "OEBasicHash" :term:`BB_SIGNATURE_HANDLER` is the same
as the "OEBasic" version but adds the task hash to the :ref:`stamp
files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This
results in any metadata change that changes the task hash, automatically causing
@ -1782,7 +1782,7 @@ the build. This information includes:
- ``BBHASHDEPS_``\ filename\ ``:``\ taskname: The task dependencies for
each task.
- ``BB_TASKHASH``: The hash of the currently running task.
- :term:`BB_TASKHASH`: The hash of the currently running task.
Shared State
------------
@ -1851,7 +1851,7 @@ The following list explains the previous example:
``do_deploy`` is in the shared state cache and its signature indicates
that the cached output is still valid (i.e. if no relevant task inputs
have changed), then the contents of the shared state cache copies
directly to ${``DEPLOY_DIR_IMAGE``} by the ``do_deploy_setscene`` task
directly to ${:term:`DEPLOY_DIR_IMAGE`} by the ``do_deploy_setscene`` task
instead, skipping the ``do_deploy`` task.
- The following task definition is glue logic needed to make the
@ -1897,8 +1897,8 @@ The following list explains the previous example:
- ``sstate-inputdirs`` and ``sstate-outputdirs`` can also be used with
multiple directories. For example, the following declares
``PKGDESTWORK`` and ``SHLIBWORK`` as shared state input directories,
which populates the shared state cache, and ``PKGDATA_DIR`` and
:term:`PKGDESTWORK` and ``SHLIBWORK`` as shared state input directories,
which populates the shared state cache, and :term:`PKGDATA_DIR` and
``SHLIBSDIR`` as the corresponding shared state output directories::
do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
@ -1925,7 +1925,7 @@ shared state files. Here is an example::
subdirectories, where the subdirectory names are based on the first two
characters of the hash.
If the shared state directory structure for a mirror has the same structure
as ``SSTATE_DIR``, you must specify "PATH" as part of the URI to enable the build
as :term:`SSTATE_DIR`, you must specify "PATH" as part of the URI to enable the build
system to map to the appropriate subdirectory.
The shared state package validity can be detected just by looking at the
@ -1976,7 +1976,7 @@ dependencies, you must manually declare the dependencies.
Simultaneously, all executables and shared libraries installed by the
recipe are inspected to see what shared libraries they link against.
For each shared library dependency that is found, ``PKGDATA_DIR`` is
For each shared library dependency that is found, :term:`PKGDATA_DIR` is
queried to see if some package (likely from a different recipe)
contains the shared library. If such a package is found, a runtime
dependency is added from the package that depends on the shared
@ -1985,7 +1985,7 @@ dependencies, you must manually declare the dependencies.
The automatically added runtime dependency also includes a version
restriction. This version restriction specifies that at least the
current version of the package that provides the shared library must
be used, as if "package (>= version)" had been added to ``RDEPENDS``.
be used, as if "package (>= version)" had been added to :term:`RDEPENDS`.
This forces an upgrade of the package containing the shared library
when installing the package that depends on the library, if needed.
@ -1999,14 +1999,14 @@ dependencies, you must manually declare the dependencies.
pkg-config modules (``*.pc`` files) installed by the recipe are
located. For each module, the package that contains the module is
registered as providing the module. The resulting module-to-package
mapping is saved globally in ``PKGDATA_DIR`` by the
mapping is saved globally in :term:`PKGDATA_DIR` by the
``do_packagedata`` task.
Simultaneously, all pkg-config modules installed by the recipe are
inspected to see what other pkg-config modules they depend on. A
module is seen as depending on another module if it contains a
"Requires:" line that specifies the other module. For each module
dependency, ``PKGDATA_DIR`` is queried to see if some package
dependency, :term:`PKGDATA_DIR` is queried to see if some package
contains the module. If such a package is found, a runtime dependency
is added from the package that depends on the module to the package
that contains the module.
@ -2046,7 +2046,7 @@ recipe in :term:`DEPENDS` through use
of a ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
declaration, which guarantees that the required
shared-library/module-to-package mapping information will be available
when needed as long as ``DEPENDS`` has been correctly set.
when needed as long as :term:`DEPENDS` has been correctly set.
Fakeroot and Pseudo
===================

74
documentation/ref-manual/classes.rst
View File

@ -50,7 +50,7 @@ splitting out of debug symbols during packaging).
``do_package_write_*`` tasks to
have different signatures for the machines with different tunings.
Additionally, unnecessary rebuilds occur every time an image for a
different ``MACHINE`` is built even when the recipe never changes.
different :term:`MACHINE` is built even when the recipe never changes.
By default, all recipes inherit the :ref:`base <ref-classes-base>` and
:ref:`package <ref-classes-package>` classes, which enable
@ -110,7 +110,7 @@ It's useful to have some idea of how the tasks defined by the
- :ref:`ref-tasks-configure` - Regenerates the
configure script (using ``autoreconf``) and then launches it with a
standard set of arguments used during cross-compilation. You can pass
additional parameters to ``configure`` through the ``EXTRA_OECONF``
additional parameters to ``configure`` through the :term:`EXTRA_OECONF`
or :term:`PACKAGECONFIG_CONFARGS`
variables.
@ -168,7 +168,7 @@ example use for this class.
the "subpath" parameter limits the checkout to a specific subpath
of the tree. Here is an example where ``${BP}`` is used so that the files
are extracted into the subdirectory expected by the default value of
``S``::
:term:`S`::
SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}"
@ -256,7 +256,7 @@ Collecting build statistics is enabled by default through the
:term:`USER_CLASSES` variable from your
``local.conf`` file. Consequently, you do not have to do anything to
enable the class. However, if you want to disable the class, simply
remove "buildstats" from the ``USER_CLASSES`` list.
remove "buildstats" from the :term:`USER_CLASSES` list.
.. _ref-classes-buildstats-summary:
@ -433,7 +433,7 @@ deployed to :term:`DEPLOYDIR`, and use ``addtask`` to
add the task at the appropriate place, which is usually after
:ref:`ref-tasks-compile` or
:ref:`ref-tasks-install`. The class then takes care of
staging the files from ``DEPLOYDIR`` to ``DEPLOY_DIR_IMAGE``.
staging the files from :term:`DEPLOYDIR` to :term:`DEPLOY_DIR_IMAGE`.
.. _ref-classes-devshell:
@ -474,7 +474,7 @@ The class
currently only supports creating a development variant of the target
recipe, not ``native`` or ``nativesdk`` variants.
The ``BBCLASSEXTEND`` syntax (i.e. ``devupstream:target``) provides
The :term:`BBCLASSEXTEND` syntax (i.e. ``devupstream:target``) provides
support for ``native`` and ``nativesdk`` variants. Consequently, this
functionality can be added in a future release.
@ -519,13 +519,13 @@ and to build it, respectively. When your recipe inherits the
``externalsrc`` class, you use the
:term:`EXTERNALSRC` and
:term:`EXTERNALSRC_BUILD` variables to
ultimately define ``S`` and ``B``.
ultimately define :term:`S` and :term:`B`.
By default, this class expects the source code to support recipe builds
that use the :term:`B` variable to point to the directory in
which the OpenEmbedded build system places the generated objects built
from the recipes. By default, the ``B`` directory is set to the
following, which is separate from the source directory (``S``)::
from the recipes. By default, the :term:`B` directory is set to the
following, which is separate from the source directory (:term:`S`)::
${WORKDIR}/${BPN}/{PV}/
@ -689,8 +689,8 @@ introspection. This functionality is only enabled if the
.. note::
This functionality is backfilled by default and, if not applicable,
should be disabled through ``DISTRO_FEATURES_BACKFILL_CONSIDERED`` or
``MACHINE_FEATURES_BACKFILL_CONSIDERED``, respectively.
should be disabled through :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED` or
:term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`, respectively.
.. _ref-classes-grub-efi:
@ -838,7 +838,7 @@ using an empty :term:`PARALLEL_MAKE` variable.
Inheriting the ``icecc`` class changes all sstate signatures.
Consequently, if a development team has a dedicated build system that
populates :term:`SSTATE_MIRRORS` and they want to
reuse sstate from ``SSTATE_MIRRORS``, then all developers and the build
reuse sstate from :term:`SSTATE_MIRRORS`, then all developers and the build
system need to either inherit the ``icecc`` class or nobody should.
At the distribution level, you can inherit the ``icecc`` class to be
@ -866,10 +866,10 @@ First, the root filesystem is created from packages using one of the
``rootfs*.bbclass`` files (depending on the package format used) and
then one or more image files are created.
- The ``IMAGE_FSTYPES`` variable controls the types of images to
- The :term:`IMAGE_FSTYPES` variable controls the types of images to
generate.
- The ``IMAGE_INSTALL`` variable controls the list of packages to
- The :term:`IMAGE_INSTALL` variable controls the list of packages to
install into the image.
For information on customizing images, see the
@ -916,7 +916,7 @@ The ``image_types`` class also handles conversion and compression of images.
.. note::
To build a VMware VMDK image, you need to add "wic.vmdk" to
``IMAGE_FSTYPES``. This would also be similar for Virtual Box Virtual Disk
:term:`IMAGE_FSTYPES`. This would also be similar for Virtual Box Virtual Disk
Image ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images.
.. _ref-classes-image-live:
@ -994,7 +994,7 @@ Please keep in mind that the QA checks
are meant to detect real or potential problems in the packaged
output. So exercise caution when disabling these checks.
Here are the tests you can list with the ``WARN_QA`` and
Here are the tests you can list with the :term:`WARN_QA` and
``ERROR_QA`` variables:
- ``already-stripped:`` Checks that produced binaries have not
@ -1127,13 +1127,13 @@ Here are the tests you can list with the ``WARN_QA`` and
PACKAGECONFIG[foo] = "..."
- ``la:`` Checks ``.la`` files for any ``TMPDIR`` paths. Any ``.la``
- ``la:`` Checks ``.la`` files for any :term:`TMPDIR` paths. Any ``.la``
file containing these paths is incorrect since ``libtool`` adds the
correct sysroot prefix when using the files automatically itself.
- ``ldflags:`` Ensures that the binaries were linked with the
:term:`LDFLAGS` options provided by the build system.
If this test fails, check that the ``LDFLAGS`` variable is being
If this test fails, check that the :term:`LDFLAGS` variable is being
passed to the linker command.
- ``libdir:`` Checks for libraries being installed into incorrect
@ -1173,7 +1173,7 @@ Here are the tests you can list with the ``WARN_QA`` and
invalid characters (i.e. characters other than 0-9, a-z, ., +, and
-).
- ``pkgv-undefined:`` Checks to see if the ``PKGV`` variable is
- ``pkgv-undefined:`` Checks to see if the :term:`PKGV` variable is
undefined during :ref:`ref-tasks-package`.
- ``pkgvarcheck:`` Checks through the variables
@ -1193,8 +1193,8 @@ Here are the tests you can list with the ``WARN_QA`` and
- ``pn-overrides:`` Checks that a recipe does not have a name
(:term:`PN`) value that appears in
:term:`OVERRIDES`. If a recipe is named such that
its ``PN`` value matches something already in ``OVERRIDES`` (e.g.
``PN`` happens to be the same as :term:`MACHINE` or
its :term:`PN` value matches something already in :term:`OVERRIDES` (e.g.
:term:`PN` happens to be the same as :term:`MACHINE` or
:term:`DISTRO`), it can have unexpected consequences.
For example, assignments such as ``FILES_${PN} = "xyz"`` effectively
turn into ``FILES = "xyz"``.
@ -1725,7 +1725,7 @@ To use this class, inherit it globally and specify
SOURCE_MIRROR_URL = "http://example.com/my-source-mirror"
You can specify only a single URL
in ``SOURCE_MIRROR_URL``.
in :term:`SOURCE_MIRROR_URL`.
.. _ref-classes-package:
@ -1749,7 +1749,7 @@ package-specific classes:
use this class.
You can control the list of resulting package formats by using the
``PACKAGE_CLASSES`` variable defined in your ``conf/local.conf``
:term:`PACKAGE_CLASSES` variable defined in your ``conf/local.conf``
configuration file, which is located in the :term:`Build Directory`.
When defining the variable, you can
specify one or more package types. Since images are generated from
@ -1770,7 +1770,7 @@ the same or similar package. This comparison takes into account a
complete build of the package with all dependencies previously built.
The reason for this discrepancy is because the RPM package manager
creates and processes more :term:`Metadata` than the IPK package
manager. Consequently, you might consider setting ``PACKAGE_CLASSES`` to
manager. Consequently, you might consider setting :term:`PACKAGE_CLASSES` to
"package_ipk" if you are building smaller systems.
Before making your package manager decision, however, you should
@ -1852,7 +1852,7 @@ variable in the ``local.conf`` file.
.. note::
You cannot specify the ``package_tar`` class first using the
``PACKAGE_CLASSES`` variable. You must use ``.deb``, ``.ipk``, or ``.rpm``
:term:`PACKAGE_CLASSES` variable. You must use ``.deb``, ``.ipk``, or ``.rpm``
file formats for your image or SDK.
.. _ref-classes-packagedata:
@ -1874,7 +1874,7 @@ This class is enabled by default because it is inherited by the
========================
The ``packagegroup`` class sets default values appropriate for package
group recipes (e.g. ``PACKAGES``, ``PACKAGE_ARCH``, ``ALLOW_EMPTY``, and
group recipes (e.g. :term:`PACKAGES`, :term:`PACKAGE_ARCH`, :term:`ALLOW_EMPTY`, and
so forth). It is highly recommended that all package group recipes
inherit this class.
@ -2193,7 +2193,7 @@ modifying and building source code out of the work directory for a
recipe, enabling ``rm_work`` will potentially result in your changes to
the source being lost. To exclude some recipes from having their work
directories deleted by ``rm_work``, you can add the names of the recipe
or recipes you are working on to the ``RM_WORK_EXCLUDE`` variable, which
or recipes you are working on to the :term:`RM_WORK_EXCLUDE` variable, which
can also be set in your ``local.conf`` file. Here is an example::
RM_WORK_EXCLUDE += "busybox glibc"
@ -2308,11 +2308,11 @@ results so these tests can be skipped over but still make the correct
values available. The ``meta/site directory`` contains test results
sorted into different categories such as architecture, endianness, and
the ``libc`` used. Site information provides a list of files containing
data relevant to the current build in the ``CONFIG_SITE`` variable that
data relevant to the current build in the :term:`CONFIG_SITE` variable that
Autotools automatically picks up.
The class also provides variables like ``SITEINFO_ENDIANNESS`` and
``SITEINFO_BITS`` that can be used elsewhere in the metadata.
The class also provides variables like :term:`SITEINFO_ENDIANNESS` and
:term:`SITEINFO_BITS` that can be used elsewhere in the metadata.
.. _ref-classes-sstate:
@ -2363,7 +2363,7 @@ stages:
.. note::
Additionally, a recipe can customize the files further by
declaring a processing function in the ``SYSROOT_PREPROCESS_FUNCS``
declaring a processing function in the :term:`SYSROOT_PREPROCESS_FUNCS`
variable.
A shared state (sstate) object is built from these files and the
@ -2405,11 +2405,11 @@ stages:
recommended for general use, the files do allow some issues such
as user creation and module indexes to be addressed.
Because recipes can have other dependencies outside of ``DEPENDS``
Because recipes can have other dependencies outside of :term:`DEPENDS`
(e.g. ``do_unpack[depends] += "tar-native:do_populate_sysroot"``),
the sysroot creation function ``extend_recipe_sysroot`` is also added
as a pre-function for those tasks whose dependencies are not through
``DEPENDS`` but operate similarly.
:term:`DEPENDS` but operate similarly.
When installing dependencies into the sysroot, the code traverses the
dependency graph and processes dependencies in exactly the same way
@ -2735,8 +2735,8 @@ initialization script on behalf of the package. The OpenEmbedded build
system takes care of details such as making sure the script is stopped
before a package is removed and started when the package is installed.
Three variables control this class: ``INITSCRIPT_PACKAGES``,
``INITSCRIPT_NAME`` and ``INITSCRIPT_PARAMS``. See the variable links
Three variables control this class: :term:`INITSCRIPT_PACKAGES`,
:term:`INITSCRIPT_NAME` and :term:`INITSCRIPT_PARAMS`. See the variable links
for details.
.. _ref-classes-useradd:
@ -2790,9 +2790,9 @@ additional information.
.. note::
You do not use the ``useradd-staticids`` class directly. You either enable
or disable the class by setting the ``USERADDEXTENSION`` variable. If you
or disable the class by setting the :term:`USERADDEXTENSION` variable. If you
enable or disable the class in a configured system, :term:`TMPDIR` might
contain incorrect ``uid`` and ``gid`` values. Deleting the ``TMPDIR``
contain incorrect ``uid`` and ``gid`` values. Deleting the :term:`TMPDIR`
directory will correct this condition.
.. _ref-classes-utility-tasks:

16
documentation/ref-manual/faq.rst
View File

@ -108,10 +108,10 @@ the team can place sources there so builds continue to work.
but the package is being marked as machine-specific in all cases, how do
I prevent this?
**A:** Set ``SRC_URI_OVERRIDES_PACKAGE_ARCH`` = "0" in the ``.bb`` file
**A:** Set :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` = "0" in the ``.bb`` file
but make sure the package is manually marked as machine-specific for the
case that needs it. The code that handles
``SRC_URI_OVERRIDES_PACKAGE_ARCH`` is in the
:term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` is in the
``meta/classes/base.bbclass`` file.
**Q:** I'm behind a firewall and need to use a proxy server. How do I do
@ -250,7 +250,7 @@ size, you need to set various configurations:
:term:`IMAGE_ROOTFS_EXTRA_SPACE`
variable to add additional free space to the image. The build system
adds this space to the image after it determines its
``IMAGE_ROOTFS_SIZE``.
:term:`IMAGE_ROOTFS_SIZE`.
**Q:** Why don't you support directories with spaces in the pathnames?
@ -262,11 +262,11 @@ situation changes, the team will not support spaces in pathnames.
**Q:** How do I use an external toolchain?
**A:** The toolchain configuration is very flexible and customizable. It
is primarily controlled with the ``TCMODE`` variable. This variable
is primarily controlled with the :term:`TCMODE` variable. This variable
controls which ``tcmode-*.inc`` file to include from the
``meta/conf/distro/include`` directory within the :term:`Source Directory`.
The default value of ``TCMODE`` is "default", which tells the
The default value of :term:`TCMODE` is "default", which tells the
OpenEmbedded build system to use its internally built toolchain (i.e.
``tcmode-default.inc``). However, other patterns are accepted. In
particular, "external-\*" refers to external toolchains. One example is
@ -325,7 +325,7 @@ Here is another technique::
BB_FETCH_PREMIRRORONLY = "1"
This statement
limits the build system to pulling source from the ``PREMIRRORS`` only.
limits the build system to pulling source from the :term:`PREMIRRORS` only.
Again, this technique is useful for reproducing builds.
Here is another technique::
@ -339,7 +339,7 @@ however, the technique can simply waste time during the build.
Finally, consider an example where you are behind an HTTP-only firewall.
You could make the following changes to the ``local.conf`` configuration
file as long as the ``PREMIRRORS`` server is current::
file as long as the :term:`PREMIRRORS` server is current::
PREMIRRORS_prepend = "\
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
@ -349,7 +349,7 @@ file as long as the ``PREMIRRORS`` server is current::
These changes would cause the build system to successfully fetch source
over HTTP and any network accesses to anything other than the
``PREMIRRORS`` would fail.
:term:`PREMIRRORS` would fail.
The build system also honors the standard shell environment variables
``http_proxy``, ``ftp_proxy``, ``https_proxy``, and ``all_proxy`` to

22
documentation/ref-manual/features.rst
View File

@ -10,10 +10,10 @@ can select, and a reference on feature backfilling.
Features provide a mechanism for working out which packages should be
included in the generated images. Distributions can select which
features they want to support through the ``DISTRO_FEATURES`` variable,
features they want to support through the :term:`DISTRO_FEATURES` variable,
which is set or appended to in a distribution's configuration file such
as ``poky.conf``, ``poky-tiny.conf``, ``poky-lsb.conf`` and so forth.
Machine features are set in the ``MACHINE_FEATURES`` variable, which is
Machine features are set in the :term:`MACHINE_FEATURES` variable, which is
set in the machine configuration file and specifies the hardware
features for a given machine.
@ -267,7 +267,7 @@ these valid features is as follows:
- *ssh-server-openssh:* Installs the OpenSSH SSH server, which is more
full-featured than Dropbear. Note that if both the OpenSSH SSH server
and the Dropbear minimal SSH server are present in
``IMAGE_FEATURES``, then OpenSSH will take precedence and Dropbear
:term:`IMAGE_FEATURES`, then OpenSSH will take precedence and Dropbear
will not be installed.
- *tools-debug:* Installs debugging tools such as ``strace`` and
@ -323,27 +323,27 @@ Here are two examples to help illustrate feature backfilling:
- *The "pulseaudio" distro feature option*: Previously, PulseAudio
support was enabled within the Qt and GStreamer frameworks. Because
of this, the feature is backfilled and thus enabled for all distros
through the ``DISTRO_FEATURES_BACKFILL`` variable in the
through the :term:`DISTRO_FEATURES_BACKFILL` variable in the
``meta/conf/bitbake.conf`` file. However, your distro needs to
disable the feature. You can disable the feature without affecting
other existing distro configurations that need PulseAudio support by
adding "pulseaudio" to ``DISTRO_FEATURES_BACKFILL_CONSIDERED`` in
adding "pulseaudio" to :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED` in
your distro's ``.conf`` file. Adding the feature to this variable
when it also exists in the ``DISTRO_FEATURES_BACKFILL`` variable
when it also exists in the :term:`DISTRO_FEATURES_BACKFILL` variable
prevents the build system from adding the feature to your
configuration's ``DISTRO_FEATURES``, effectively disabling the
configuration's :term:`DISTRO_FEATURES`, effectively disabling the
feature for that particular distro.
- *The "rtc" machine feature option*: Previously, real time clock (RTC)
support was enabled for all target devices. Because of this, the
feature is backfilled and thus enabled for all machines through the
``MACHINE_FEATURES_BACKFILL`` variable in the
:term:`MACHINE_FEATURES_BACKFILL` variable in the
``meta/conf/bitbake.conf`` file. However, your target device does not
have this capability. You can disable RTC support for your device
without affecting other machines that need RTC support by adding the
feature to your machine's ``MACHINE_FEATURES_BACKFILL_CONSIDERED``
feature to your machine's :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`
list in the machine's ``.conf`` file. Adding the feature to this
variable when it also exists in the ``MACHINE_FEATURES_BACKFILL``
variable when it also exists in the :term:`MACHINE_FEATURES_BACKFILL`
variable prevents the build system from adding the feature to your
configuration's ``MACHINE_FEATURES``, effectively disabling RTC
configuration's :term:`MACHINE_FEATURES`, effectively disabling RTC
support for that particular machine.

26
documentation/ref-manual/qa-checks.rst
View File

@ -88,7 +88,7 @@ Errors and Warnings
A file-level dependency has been identified from the specified
package on the specified files, but there is no explicit
corresponding entry in :term:`RDEPENDS`. If
particular files are required at runtime then ``RDEPENDS`` should be
particular files are required at runtime then :term:`RDEPENDS` should be
declared in the recipe to ensure the packages providing them are
built.
@ -104,7 +104,7 @@ Errors and Warnings
:term:`RDEPENDS` value being added at the packaging
stage rather than up front, which is usually automatic based on the
contents of the package. In most cases, you should change the recipe
to add an explicit ``RDEPENDS`` for the dependency.
to add an explicit :term:`RDEPENDS` for the dependency.
 
.. _qa-check-dev-so:
@ -152,7 +152,7 @@ Errors and Warnings
not explicitly add the ``.debug`` directory to the ``-dbg`` package.
If this is the case, add the ``.debug`` directory explicitly to
``FILES_${PN}-dbg``. See :term:`FILES` for additional
information on ``FILES``.
information on :term:`FILES`.
 
.. _qa-check-arch:
@ -235,9 +235,9 @@ Errors and Warnings
This indicates that binaries produced when building the recipe have
not been linked with the :term:`LDFLAGS` options
provided by the build system. Check to be sure that the ``LDFLAGS``
provided by the build system. Check to be sure that the :term:`LDFLAGS`
variable is being passed to the linker command. A common workaround
for this situation is to pass in ``LDFLAGS`` using
for this situation is to pass in :term:`LDFLAGS` using
:term:`TARGET_CC_ARCH` within the recipe as
follows::
@ -403,7 +403,7 @@ Errors and Warnings
If your recipe name does not match this, or you add packages to
:term:`PACKAGES` that do not conform to the
convention, then you will receive this error. Rename your recipe. Or,
if you have added a non-conforming package name to ``PACKAGES``,
if you have added a non-conforming package name to :term:`PACKAGES`,
change the package name appropriately.
 
@ -431,13 +431,13 @@ Errors and Warnings
The specified recipe has a name (:term:`PN`) value that
appears in :term:`OVERRIDES`. If a recipe is named
such that its ``PN`` value matches something already in ``OVERRIDES``
(e.g. ``PN`` happens to be the same as :term:`MACHINE`
such that its :term:`PN` value matches something already in :term:`OVERRIDES`
(e.g. :term:`PN` happens to be the same as :term:`MACHINE`
or :term:`DISTRO`), it can have unexpected
consequences. For example, assignments such as
``FILES_${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``.
Rename your recipe (or if ``PN`` is being set explicitly, change the
``PN`` value) so that the conflict does not occur. See
Rename your recipe (or if :term:`PN` is being set explicitly, change the
:term:`PN` value) so that the conflict does not occur. See
:term:`FILES` for additional information.
 
@ -464,7 +464,7 @@ Errors and Warnings
This check looks for instances of setting ``DEPENDS_${PN}``
which is erroneous (:term:`DEPENDS` is a recipe-wide variable and thus
it is not correct to specify it for a particular package, nor will such
an assignment actually work.) Set ``DEPENDS`` instead.
an assignment actually work.) Set :term:`DEPENDS` instead.
.. _qa-check-already-stripped:
@ -499,7 +499,7 @@ Errors and Warnings
Package names must appear only once in the
:term:`PACKAGES` variable. You might receive this
error if you are attempting to add a package to ``PACKAGES`` that is
error if you are attempting to add a package to :term:`PACKAGES` that is
already in the variable's value.
 
@ -523,7 +523,7 @@ Errors and Warnings
in an image later on in the build process. You need to do one of the
following:
- Add the files to ``FILES`` for the package you want them to appear
- Add the files to :term:`FILES` for the package you want them to appear
in (e.g. ``FILES_${``\ :term:`PN`\ ``}`` for the main
package).

16
documentation/ref-manual/structure.rst
View File

@ -251,9 +251,9 @@ variables are hard-coded for various reasons but such variables are
relatively rare.
At a minimum, you would normally edit this file to select the target
``MACHINE``, which package types you wish to use
:term:`MACHINE`, which package types you wish to use
(:term:`PACKAGE_CLASSES`), and the location from
which you want to access downloaded files (``DL_DIR``).
which you want to access downloaded files (:term:`DL_DIR`).
If ``local.conf`` is not present when you start the build, the
OpenEmbedded build system creates it from ``local.conf.sample`` when you
@ -336,7 +336,7 @@ the build.
This directory contains downloaded upstream source tarballs. You can
reuse the directory for multiple builds or move the directory to another
location. You can control the location of this directory through the
``DL_DIR`` variable.
:term:`DL_DIR` variable.
.. _structure-build-sstate-cache:
@ -346,7 +346,7 @@ location. You can control the location of this directory through the
This directory contains the shared state cache. You can reuse the
directory for multiple builds or move the directory to another location.
You can control the location of this directory through the
``SSTATE_DIR`` variable.
:term:`SSTATE_DIR` variable.
.. _structure-build-tmp:
@ -548,7 +548,7 @@ section in the Yocto Project Overview and Concepts Manual.
------------------
This directory contains general logs that are not otherwise placed using
the package's ``WORKDIR``. Examples of logs are the output from the
the package's :term:`WORKDIR`. Examples of logs are the output from the
``do_check_pkg`` or ``do_distro_check`` tasks. Running a build does not
necessarily mean this directory is created.
@ -569,7 +569,7 @@ It is worth considering the structure of a typical work directory. As an
example, consider ``linux-yocto-kernel-3.0`` on the machine ``qemux86``
built within the Yocto Project. For this package, a work directory of
``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred
to as the ``WORKDIR``, is created. Within this directory, the source is
to as the :term:`WORKDIR`, is created. Within this directory, the source is
unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt.
(See the ":ref:`dev-manual/common-tasks:using quilt in your workflow`" section in
the Yocto Project Development Tasks Manual for more information.) Within
@ -577,7 +577,7 @@ the ``linux-qemux86-standard-build`` directory, standard Quilt
directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and
standard Quilt commands can be used.
There are other directories generated within ``WORKDIR``. The most
There are other directories generated within :term:`WORKDIR`. The most
important directory is ``WORKDIR/temp/``, which has log files for each
task (``log.do_*.pid``) and contains the scripts BitBake runs for each
task (``run.do_*.pid``). The ``WORKDIR/image/`` directory is where "make
@ -709,7 +709,7 @@ support for a new machine to the Yocto Project, look in this directory.
The contents of this directory controls any distribution-specific
configurations. For the Yocto Project, the ``defaultsetup.conf`` is the
main file here. This directory includes the versions and the ``SRCDATE``
main file here. This directory includes the versions and the :term:`SRCDATE`
definitions for applications that are configured here. An example of an
alternative configuration might be ``poky-bleeding.conf``. Although this
file mainly inherits its configuration from Poky.

12
documentation/ref-manual/tasks.rst
View File

@ -57,7 +57,7 @@ the current working directory set to ``${``\ :term:`B`\ ``}``.
The default behavior of this task is to run ``oe_runmake clean`` if a
makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found and
:term:`CLEANBROKEN` is not set to "1". If no such
file is found or the ``CLEANBROKEN`` variable is set to "1", the
file is found or the :term:`CLEANBROKEN` variable is set to "1", the
``do_configure`` task does nothing.
.. _ref-tasks-configure_ptest_base:
@ -308,17 +308,17 @@ This recipe has two patch files located here::
poky/meta/recipes-connectivity/bluez5/bluez5
In the ``bluez5`` recipe, the ``SRC_URI`` statements point to the source
In the ``bluez5`` recipe, the :term:`SRC_URI` statements point to the source
and patch files needed to build the package.
.. note::
In the case for the ``bluez5_5.48.bb`` recipe, the ``SRC_URI`` statements
In the case for the ``bluez5_5.48.bb`` recipe, the :term:`SRC_URI` statements
are from an include file ``bluez5.inc``.
As mentioned earlier, the build system treats files whose file types are
``.patch`` and ``.diff`` as patch files. However, you can use the
"apply=yes" parameter with the ``SRC_URI`` statement to indicate any
"apply=yes" parameter with the :term:`SRC_URI` statement to indicate any
file as a patch file::
SRC_URI = " \
@ -329,7 +329,7 @@ file as a patch file::
Conversely, if you have a directory full of patch files and you want to
exclude some so that the ``do_patch`` task does not apply them during
the patch phase, you can use the "apply=no" parameter with the
``SRC_URI`` statement::
:term:`SRC_URI` statement::
SRC_URI = " \
git://path_to_repo/some_package \
@ -430,7 +430,7 @@ variable also plays a role in where unpacked source files ultimately
reside. For more information on how source files are unpacked, see the
":ref:`overview-manual/concepts:source fetching`"
section in the Yocto Project Overview and Concepts Manual and also see
the ``WORKDIR`` and ``S`` variable descriptions.
the :term:`WORKDIR` and :term:`S` variable descriptions.
Manually Called Tasks
=====================

6
documentation/ref-manual/terms.rst
View File

@ -97,11 +97,11 @@ universal, the list includes them just in case:
.. note::
By default, the Build Directory contains :term:`TMPDIR`, which is a
temporary directory the build system uses for its work. ``TMPDIR`` cannot
temporary directory the build system uses for its work. :term:`TMPDIR` cannot
be under NFS. Thus, by default, the Build Directory cannot be under
NFS. However, if you need the Build Directory to be under NFS, you can
set this up by setting ``TMPDIR`` in your ``local.conf`` file to use a local
drive. Doing so effectively separates ``TMPDIR`` from :term:`TOPDIR`, which is the
set this up by setting :term:`TMPDIR` in your ``local.conf`` file to use a local
drive. Doing so effectively separates :term:`TMPDIR` from :term:`TOPDIR`, which is the
Build Directory.
:term:`Build Host`

1184
documentation/ref-manual/variables.rst
View File

File diff suppressed because it is too large Load Diff

4
documentation/sdk-manual/appendix-customizing-standard.rst
View File

@ -17,10 +17,10 @@ and
variables control the set of packages adding to the SDK.
If you want to add individual packages to the toolchain that runs on the
host, simply add those packages to the ``TOOLCHAIN_HOST_TASK`` variable.
host, simply add those packages to the :term:`TOOLCHAIN_HOST_TASK` variable.
Similarly, if you want to add packages to the default set that is part
of the toolchain that runs on the target, add the packages to the
``TOOLCHAIN_TARGET_TASK`` variable.
:term:`TOOLCHAIN_TARGET_TASK` variable.
Adding API Documentation to the Standard SDK
============================================

24
documentation/sdk-manual/appendix-customizing.rst
View File

@ -35,13 +35,13 @@ build system applies them against ``local.conf`` and ``auto.conf``:
- Variables listed in
:term:`SDK_LOCAL_CONF_WHITELIST`
are included. Including a variable in the value of
``SDK_LOCAL_CONF_WHITELIST`` overrides either of the previous two
:term:`SDK_LOCAL_CONF_WHITELIST` overrides either of the previous two
filters. The default value is blank.
- Classes inherited globally with
:term:`INHERIT` that are listed in
:term:`SDK_INHERIT_BLACKLIST`
are disabled. Using ``SDK_INHERIT_BLACKLIST`` to disable these
are disabled. Using :term:`SDK_INHERIT_BLACKLIST` to disable these
classes is the typical method to disable classes that are problematic
or unnecessary in the SDK context. The default value blacklists the
:ref:`buildhistory <ref-classes-buildhistory>`
@ -95,7 +95,7 @@ adjustments:
- Disable the tasks if they are added by a class and you do not need
the functionality the class provides in the extensible SDK. To
disable the tasks, add the class to the ``SDK_INHERIT_BLACKLIST``
disable the tasks, add the class to the :term:`SDK_INHERIT_BLACKLIST`
variable as described in the previous section.
- Generally, you want to have a shared state mirror set up so users of
@ -142,12 +142,12 @@ section.
By default, this title is derived from
:term:`DISTRO_NAME` when it is
set. If the ``DISTRO_NAME`` variable is not set, the title is derived
set. If the :term:`DISTRO_NAME` variable is not set, the title is derived
from the :term:`DISTRO` variable.
The
:ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
class defines the default value of the ``SDK_TITLE`` variable as
class defines the default value of the :term:`SDK_TITLE` variable as
follows::
SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
@ -158,7 +158,7 @@ creates an SDK installer title that applies across your distribution. As
an example, assume you have your own layer for your distribution named
"meta-mydistro" and you are using the same type of file hierarchy as
does the default "poky" distribution. If so, you could update the
``SDK_TITLE`` variable in the
:term:`SDK_TITLE` variable in the
``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following
form::
@ -220,7 +220,7 @@ class as follows::
You can
change this default installation directory by specifically setting the
``SDKEXTPATH`` variable.
:term:`SDKEXTPATH` variable.
While there are several ways of setting this variable,
the method that makes the most sense is to set the variable in your
@ -229,7 +229,7 @@ default directory that applies across your distribution. As an example,
assume you have your own layer for your distribution named
"meta-mydistro" and you are using the same type of file hierarchy as
does the default "poky" distribution. If so, you could update the
``SDKEXTPATH`` variable in the
:term:`SDKEXTPATH` variable in the
``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following
form::
@ -284,11 +284,11 @@ source, you need to do a number of things:
SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
- Alternatively, if you just want to set the ``SSTATE_MIRRORS``
- Alternatively, if you just want to set the :term:`SSTATE_MIRRORS`
variable's value for the SDK alone, create a
``conf/sdk-extra.conf`` file either in your
:term:`Build Directory` or within any
layer and put your ``SSTATE_MIRRORS`` setting within that file.
layer and put your :term:`SSTATE_MIRRORS` setting within that file.
.. note::
@ -333,7 +333,7 @@ following::
See the :term:`SDK_INCLUDE_PKGDATA` variable for additional information.
Setting the ``SDK_INCLUDE_PKGDATA`` variable as shown causes the "world"
Setting the :term:`SDK_INCLUDE_PKGDATA` variable as shown causes the "world"
target to be built so that information for all of the recipes included
within it are available. Having these recipes available increases build
time significantly and increases the size of the SDK installer by 30-80
@ -358,7 +358,7 @@ You can explicitly control whether or not to include the toolchain when
you build an SDK by setting the
:term:`SDK_INCLUDE_TOOLCHAIN`
variable to "1". In particular, it is useful to include the toolchain
when you have set ``SDK_EXT_TYPE`` to "minimal", which by default,
when you have set :term:`SDK_EXT_TYPE` to "minimal", which by default,
excludes the toolchain. Also, it is helpful if you are building a small
SDK for use with an IDE or some other tool where you do not want to take
extra steps to install a toolchain.

50
documentation/sdk-manual/extensible.rst
View File

@ -438,7 +438,7 @@ command:
With this scenario, there is no ``srctree`` argument. Consequently, the
default behavior of the ``devtool modify`` command is to extract
the source files pointed to by the ``SRC_URI`` statements into a
the source files pointed to by the :term:`SRC_URI` statements into a
local Git structure. Furthermore, the location for the extracted
source is the default area within the ``devtool`` workspace. The
result is that the command sets up both the source code and an
@ -446,7 +446,7 @@ command:
original location.
Additionally, if you have any non-patch local files (i.e. files
referred to with ``file://`` entries in ``SRC_URI`` statement
referred to with ``file://`` entries in :term:`SRC_URI` statement
excluding ``*.patch/`` or ``*.diff``), these files are copied to
an ``oe-local-files`` folder under the newly created source tree.
Copying the files here gives you a convenient area from which you
@ -476,7 +476,7 @@ command:
devtool
command.
As with all extractions, the command uses the recipe's ``SRC_URI``
As with all extractions, the command uses the recipe's :term:`SRC_URI`
statements to locate the source files and any associated patch
files. Non-patch files are copied to an ``oe-local-files`` folder
under the newly created source tree.
@ -655,18 +655,18 @@ The following diagram shows the common development flow used with the
don't use "-V", the command upgrades the recipe to the latest
version.
If the source files pointed to by the ``SRC_URI`` statement in the
If the source files pointed to by the :term:`SRC_URI` statement in the
recipe are in a Git repository, you must provide the "-S" option and
specify a revision for the software.
Once ``devtool`` locates the recipe, it uses the ``SRC_URI`` variable
Once ``devtool`` locates the recipe, it uses the :term:`SRC_URI` variable
to locate the source code and any local patch files from other
developers. The result is that the command sets up the source code,
the new version of the recipe, and an append file all within the
workspace.
Additionally, if you have any non-patch local files (i.e. files
referred to with ``file://`` entries in ``SRC_URI`` statement
referred to with ``file://`` entries in :term:`SRC_URI` statement
excluding ``*.patch/`` or ``*.diff``), these files are copied to an
``oe-local-files`` folder under the newly created source tree.
Copying the files here gives you a convenient area from which you can
@ -676,7 +676,7 @@ The following diagram shows the common development flow used with the
2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
after upgrading the software to a new version. Conflicts occur
if your recipe specifies some patch files in ``SRC_URI`` that
if your recipe specifies some patch files in :term:`SRC_URI` that
conflict with changes made in the new version of the software. For
such cases, you need to resolve the conflicts by editing the source
and following the normal ``git rebase`` conflict resolution process.
@ -832,7 +832,7 @@ result from naming not being recognized or because the dependency simply
is not available. For cases where the dependency is not available, you
must use the ``devtool add`` command to add an additional recipe that
satisfies the dependency. Once you add that recipe, you need to update
the ``DEPENDS`` variable in the original recipe to include the new
the :term:`DEPENDS` variable in the original recipe to include the new
recipe.
If you need to add runtime dependencies, you can do so by adding the
@ -861,7 +861,7 @@ license. If so, the command sets the
:term:`LICENSE` value accordingly.
You should double-check the value added by the command against the
documentation or source files for the software you are building and, if
necessary, update that ``LICENSE`` value.
necessary, update that :term:`LICENSE` value.
The ``devtool add`` command also sets the
:term:`LIC_FILES_CHKSUM`
@ -869,16 +869,16 @@ value to point to all files that appear to be license-related. Realize
that license statements often appear in comments at the top of source
files or within the documentation. In such cases, the command does not
recognize those license statements. Consequently, you might need to
amend the ``LIC_FILES_CHKSUM`` variable to point to one or more of those
comments if present. Setting ``LIC_FILES_CHKSUM`` is particularly
amend the :term:`LIC_FILES_CHKSUM` variable to point to one or more of those
comments if present. Setting :term:`LIC_FILES_CHKSUM` is particularly
important for third-party software. The mechanism attempts to ensure
correct licensing should you upgrade the recipe to a newer upstream
version in future. Any change in licensing is detected and you receive
an error prompting you to check the license text again.
If the ``devtool add`` command cannot determine licensing information,
``devtool`` sets the ``LICENSE`` value to "CLOSED" and leaves the
``LIC_FILES_CHKSUM`` value unset. This behavior allows you to continue
``devtool`` sets the :term:`LICENSE` value to "CLOSED" and leaves the
:term:`LIC_FILES_CHKSUM` value unset. This behavior allows you to continue
with development even though the settings are unlikely to be correct in
all cases. You should check the documentation or source files for the
software you are building to determine the actual license.
@ -904,7 +904,7 @@ mind:
hardcoding tools within the toolchain such as ``gcc`` and ``g++``.
- The environment in which Make runs is set up with various standard
variables for compilation (e.g. ``CC``, ``CXX``, and so forth) in a
variables for compilation (e.g. :term:`CC`, :term:`CXX`, and so forth) in a
similar manner to the environment set up by the SDK's environment
setup script. One easy way to see these variables is to run the
``devtool build`` command on the recipe and then look in
@ -920,7 +920,7 @@ mind:
the command line, add the variable setting to
:term:`EXTRA_OEMAKE` or
:term:`PACKAGECONFIG_CONFARGS`
within the recipe. Here is an example using ``EXTRA_OEMAKE``::
within the recipe. Here is an example using :term:`EXTRA_OEMAKE`::
EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'"
@ -1086,20 +1086,20 @@ extras specified by
:term:`EXTRA_OECONF` or
:term:`PACKAGECONFIG_CONFARGS`
set within the recipe. If you wish to pass additional options, add them
to ``EXTRA_OECONF`` or ``PACKAGECONFIG_CONFARGS``. Other supported build
to :term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS`. Other supported build
tools have similar variables (e.g.
:term:`EXTRA_OECMAKE` for
CMake, :term:`EXTRA_OESCONS`
for Scons, and so forth). If you need to pass anything on the ``make``
command line, you can use ``EXTRA_OEMAKE`` or the
command line, you can use :term:`EXTRA_OEMAKE` or the
:term:`PACKAGECONFIG_CONFARGS`
variables to do so.
You can use the ``devtool configure-help`` command to help you set the
arguments listed in the previous paragraph. The command determines the
exact options being passed, and shows them to you along with any custom
arguments specified through ``EXTRA_OECONF`` or
``PACKAGECONFIG_CONFARGS``. If applicable, the command also shows you
arguments specified through :term:`EXTRA_OECONF` or
:term:`PACKAGECONFIG_CONFARGS`. If applicable, the command also shows you
the output of the configure script's "--help" option as a
reference.
@ -1151,16 +1151,16 @@ the ``oe-workdir/packages-split`` directory, which contains a
subdirectory for each package. Apart from some advanced cases, the
:term:`PACKAGES` and
:term:`FILES` variables controls
splitting. The ``PACKAGES`` variable lists all of the packages to be
produced, while the ``FILES`` variable specifies which files to include
splitting. The :term:`PACKAGES` variable lists all of the packages to be
produced, while the :term:`FILES` variable specifies which files to include
in each package by using an override to specify the package. For
example, ``FILES_${PN}`` specifies the files to go into the main package
(i.e. the main package has the same name as the recipe and
``${``\ :term:`PN`\ ``}`` evaluates to the
recipe name). The order of the ``PACKAGES`` value is significant. For
each installed file, the first package whose ``FILES`` value matches the
file is the package into which the file goes. Both the ``PACKAGES`` and
``FILES`` variables have default values. Consequently, you might find
recipe name). The order of the :term:`PACKAGES` value is significant. For
each installed file, the first package whose :term:`FILES` value matches the
file is the package into which the file goes. Both the :term:`PACKAGES` and
:term:`FILES` variables have default values. Consequently, you might find
you do not even need to set these variables in your recipe unless the
software the recipe is building installs files into non-standard
locations.

12
documentation/sdk-manual/working-projects.rst
View File

@ -278,9 +278,9 @@ example:
$ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
3. *Create the Makefile:* For this example, the Makefile contains
two lines that can be used to set the ``CC`` variable. One line is
two lines that can be used to set the :term:`CC` variable. One line is
identical to the value that is set when you run the SDK environment
setup script, and the other line sets ``CC`` to "gcc", the default
setup script, and the other line sets :term:`CC` to "gcc", the default
GNU compiler on the build host::
# CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux
@ -297,7 +297,7 @@ example:
4. *Make the Project:* Use the ``make`` command to create the binary
output file. Because variables are commented out in the Makefile, the
value used for ``CC`` is the value set when the SDK environment setup
value used for :term:`CC` is the value set when the SDK environment setup
file was run::
$ make
@ -306,10 +306,10 @@ example:
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin
From the results of the previous command, you can see that
the compiler used was the compiler established through the ``CC``
the compiler used was the compiler established through the :term:`CC`
variable defined in the setup script.
You can override the ``CC`` environment variable with the same
You can override the :term:`CC` environment variable with the same
variable as set from the Makefile by uncommenting the line in the
Makefile and running ``make`` again.
::
@ -333,7 +333,7 @@ example:
variable as part of the command line. Go into the Makefile and
re-insert the comment character so that running ``make`` uses the
established SDK compiler. However, when you run ``make``, use a
command-line argument to set ``CC`` to "gcc"::
command-line argument to set :term:`CC` to "gcc"::
$ make clean
rm -rf *.o

2
documentation/toaster-manual/setup-and-use.rst
View File

@ -625,7 +625,7 @@ To specify ``bash`` 3.2.48 as the version to build, enter
:scale: 75%
After clicking the "Add variable" button, the settings for
``PREFERRED_VERSION`` are added to the bottom of the BitBake variables
:term:`PREFERRED_VERSION` are added to the bottom of the BitBake variables
list. With these settings, the OpenEmbedded build system builds the
desired version of the recipe rather than the default version:

2
documentation/transitioning-to-a-custom-environment.rst
View File

@ -47,7 +47,7 @@ Transitioning to a custom environment for systems development
#. **Based on the layers you've chosen, make needed changes in your
configuration**.
For instance, you've chosen a machine type and added in the corresponding BSP
layer. You'll then need to change the value of the ``MACHINE`` variable in your
layer. You'll then need to change the value of the :term:`MACHINE` variable in your
configuration file (build/local.conf) to point to that same machine
type. There could be other layer-specific settings you need to change as
well. Each layer has a ``README`` document that you can look at for this type of