MIRRORS/poky
1
0
Fork 0
mirror of git://git.yoctoproject.org/poky.git synced 2025-07-19 21:09:03 +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 #. **Change the Configuration to Build for a Specific Machine:** The
:term:`MACHINE` variable in the :term:`MACHINE` variable in the
``local.conf`` file specifies the machine for the build. For this ``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: configurations are used:
https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf. 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:: .. 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 matter. For example, if multiple layers define a machine configuration, the
OpenEmbedded build system uses the last layer searched given similar layer OpenEmbedded build system uses the last layer searched given similar layer
priorities. The build system works from the top-down through the layers 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 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 layer in order to be functional. In this case, you need to specify these
@ -685,7 +685,7 @@ statements as follows::
.. note:: .. 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. statement does not appear in the ``"bsp_root_name".conf`` file.
You would use the ``linux-yocto_4.4.bbappend`` file to append specific 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. how to use these variables.
If you build as you normally would, without specifying any recipes in 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 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 the appropriate license flags into the whitelist, restart the build
to continue where it left off. During the build, the prompt will not to continue where it left off. During the build, the prompt will not
appear again since you have satisfied the requirement. appear again since you have satisfied the requirement.
Once the appropriate license flags are on the white list in the 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. 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 #. *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 click-through license agreements presented by the website. If you
want to build the image yourself using the recipes contained within want to build the image yourself using the recipes contained within
the BSP tarball, you will still need to create an appropriate 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. BSP.
.. note:: .. note::
@ -1405,7 +1405,7 @@ Project Reference Manual.
The BeagleBone development board requires an SPL to boot and that SPL The BeagleBone development board requires an SPL to boot and that SPL
file type must be MLO. Consequently, the machine configuration needs file type must be MLO. Consequently, the machine configuration needs
to define ``SPL_BINARY`` as ``MLO``. to define :term:`SPL_BINARY` as ``MLO``.
.. note:: .. 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 Every linux-yocto style recipe must define the
:term:`KMACHINE` variable. This :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`. which is used by :term:`BitBake`.
However, in some cases, the variable might instead refer to the 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 using the same BSP description. Multiple Corei7-based BSPs could share
the same "intel-corei7-64" value for ``KMACHINE``. It is important to the same "intel-corei7-64" value for :term:`KMACHINE`. It is important to
realize that ``KMACHINE`` is just for kernel mapping, while ``MACHINE`` realize that :term:`KMACHINE` is just for kernel mapping, while :term:`MACHINE`
is the machine type within a BSP Layer. Even with this distinction, is the machine type within a BSP Layer. Even with this distinction,
however, these two variables can hold the same value. See the however, these two variables can hold the same value. See the
":ref:`kernel-dev/advanced:bsp descriptions`" section for more information. ":ref:`kernel-dev/advanced:bsp descriptions`" section for more information.
@ -66,7 +66,7 @@ to indicate the branch.
.. note:: .. 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:: with a machine override as shown here from the ``meta-yocto-bsp`` layer::
KBRANCH_edgerouter = "standard/edgerouter" KBRANCH_edgerouter = "standard/edgerouter"
@ -81,8 +81,8 @@ variables:
:term:`LINUX_KERNEL_TYPE` :term:`LINUX_KERNEL_TYPE`
defines the kernel type to be used in assembling the configuration. If defines the kernel type to be used in assembling the configuration. If
you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to "standard". you do not specify a :term:`LINUX_KERNEL_TYPE`, it defaults to "standard".
Together with ``KMACHINE``, ``LINUX_KERNEL_TYPE`` defines the search Together with :term:`KMACHINE`, :term:`LINUX_KERNEL_TYPE` defines the search
arguments used by the kernel tools to find the appropriate description arguments used by the kernel tools to find the appropriate description
within the kernel Metadata with which to build out the sources and within the kernel Metadata with which to build out the sources and
configuration. The linux-yocto recipes define "standard", "tiny", 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. section for more information on kernel types.
During the build, the kern-tools search for the BSP description file 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 variables passed in from the recipe. The tools use the first BSP
description they find that matches both variables. If the tools cannot find description they find that matches both variables. If the tools cannot find
a match, they issue a warning. a match, they issue a warning.
The tools first search for the ``KMACHINE`` and then for the The tools first search for the :term:`KMACHINE` and then for the
``LINUX_KERNEL_TYPE``. If the tools cannot find a partial match, they :term:`LINUX_KERNEL_TYPE`. If the tools cannot find a partial match, they
will use the sources from the ``KBRANCH`` and any configuration will use the sources from the :term:`KBRANCH` and any configuration
specified in the :term:`SRC_URI`. specified in the :term:`SRC_URI`.
You can use the You can use the
:term:`KERNEL_FEATURES` :term:`KERNEL_FEATURES`
variable to include features (configuration fragments, patches, or both) variable to include features (configuration fragments, patches, or both)
that are not already included by the ``KMACHINE`` and that are not already included by the :term:`KMACHINE` and
``LINUX_KERNEL_TYPE`` variable combination. For example, to include a :term:`LINUX_KERNEL_TYPE` variable combination. For example, to include a
feature specified as "features/netfilter/netfilter.scc", specify:: feature specified as "features/netfilter/netfilter.scc", specify::
KERNEL_FEATURES += "features/netfilter/netfilter.scc" KERNEL_FEATURES += "features/netfilter/netfilter.scc"
@ -116,7 +116,7 @@ specify::
KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc" KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc"
The value of 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 within the kernel Metadata itself. The examples here are taken from the
``yocto-kernel-cache`` repository. Each branch of this repository ``yocto-kernel-cache`` repository. Each branch of this repository
contains "features" and "cfg" subdirectories at the top-level. For more 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 Typically, features are less granular than configuration fragments and
are more likely than configuration fragments and patches to be the types 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 Linux kernel recipe. See the
":ref:`kernel-dev/advanced:using kernel metadata in a recipe`" section earlier ":ref:`kernel-dev/advanced:using kernel metadata in a recipe`" section earlier
in the manual. 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 example supports the "beaglebone" machine for the "standard" kernel and
the "arm" architecture. 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 type description file. Thus, if you do not have the
kernel type defined in your kernel Metadata as it is here, you only need kernel type defined in your kernel Metadata as it is here, you only need
to ensure that the to ensure that the
:term:`LINUX_KERNEL_TYPE` :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. description file match.
To separate your kernel policy from your hardware configuration, you To separate your kernel policy from your hardware configuration, you
@ -657,7 +657,7 @@ Notice again the three critical variables:
:term:`KMACHINE`, :term:`KMACHINE`,
:term:`KTYPE`, and :term:`KTYPE`, and
:term:`KARCH`. Of these variables, only :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 Kernel Metadata Location
======================== ========================
@ -693,7 +693,7 @@ directory hierarchy below
a linux-yocto recipe or for a Linux kernel recipe derived by copying and a linux-yocto recipe or for a Linux kernel recipe derived by copying and
modifying modifying
``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to ``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`\ ``}``. ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``.
See the ":ref:`kernel-dev/common:modifying an existing recipe`" See the ":ref:`kernel-dev/common:modifying an existing recipe`"
section for more information. 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 ``include``, ``patch``, or ``kconf`` commands. Because of this, it is
necessary to bump the recipe :term:`PR` necessary to bump the recipe :term:`PR`
value when changing the content of files not explicitly listed in the 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 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:: form from your kernel append file::
SRC_URI_append_myplatform = " \ 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 reside in a separate repository. The OpenEmbedded build system adds the
Metadata to the build as a "type=kmeta" repository through the Metadata to the build as a "type=kmeta" repository through the
:term:`SRC_URI` variable. As an :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:: ``linux-yocto_4.12.bb`` kernel recipe::
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH}; \ 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 ``${KMETA}``, in this context, is simply used to name the directory into
which the Git fetcher places the Metadata. This behavior is no different 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). see the previous section).
You can keep kernel Metadata in a "kernel-cache", which is a directory You can keep kernel Metadata in a "kernel-cache", which is a directory
containing configuration fragments. As with any Metadata kept outside 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 the "type=kmeta" attribute. Doing so makes the kernel Metadata available
during the configuration phase. 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 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 ``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 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. commit.
Organizing Your Source 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 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 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" KBRANCH = "mynewbranch"

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

@ -70,7 +70,7 @@ section:
:term:`MACHINE` variable is set to :term:`MACHINE` variable is set to
"qemux86-64", which is fine if you are building for the QEMU emulator "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 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 found in the
:term:`Build Directory` (i.e. :term:`Build Directory` (i.e.
``poky/build`` in this example). ``poky/build`` in this example).
@ -248,7 +248,7 @@ section:
:term:`MACHINE` variable is set to :term:`MACHINE` variable is set to
"qemux86-64", which is fine if you are building for the QEMU emulator "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 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 found in the
:term:`Build Directory` (i.e. :term:`Build Directory` (i.e.
``poky/build`` in this example). ``poky/build`` in this example).
@ -474,7 +474,7 @@ variable as follows::
The path ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}`` The path ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``
expands to "linux-yocto" in the current directory for this example. If 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 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 in the following area::
your-layer/recipes-kernel/linux/linux-yocto/ 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 For example, suppose you had some configuration options in a file called
``network_configs.cfg``. You can place that file inside a directory ``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 following to the append file. When the OpenEmbedded build system builds
the kernel, the configuration options are picked up and applied. 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 To group related configurations into multiple files, you perform a
similar procedure. Here is an example that groups separate similar procedure. Here is an example that groups separate
configurations specifically for Ethernet and graphics into their own 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:: the following in your append file::
SRC_URI += "file://myconfig.cfg \ SRC_URI += "file://myconfig.cfg \
@ -643,7 +643,7 @@ following lines to the linux-yocto ``.bbappend`` file in your layer::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://defconfig" 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 for the file, while the
:term:`FILESEXTRAPATHS` :term:`FILESEXTRAPATHS`
extends the :term:`FILESPATH` extends the :term:`FILESPATH`
@ -684,7 +684,7 @@ with the following content (without indentation)::
CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_SERIAL_CORE_CONSOLE=y
Next, include this Next, include this
configuration fragment and extend the ``FILESPATH`` variable in your configuration fragment and extend the :term:`FILESPATH` variable in your
``.bbappend`` file:: ``.bbappend`` file::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@ -722,7 +722,7 @@ form::
KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file" KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file"
Here is an example 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 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:: 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 a kernel's ``linux-``\ `machine`\ ``.inc`` file). In other words, if the
build system detects a statement that identifies an "out-of-tree" build system detects a statement that identifies an "out-of-tree"
``defconfig`` file, that statement will override your ``defconfig`` file, that statement will override your
``KBUILD_DEFCONFIG`` variable. :term:`KBUILD_DEFCONFIG` variable.
See the See the
:term:`KBUILD_DEFCONFIG` :term:`KBUILD_DEFCONFIG`
@ -1349,10 +1349,10 @@ be picked up and applied when the kernel is built::
SRC_URI += "file://myconfig.cfg" SRC_URI += "file://myconfig.cfg"
As mentioned earlier, you can group related configurations into multiple 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 example, you could group separate configurations specifically for
Ethernet and graphics into their own files and add those by using a 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 \ SRC_URI += "file://myconfig.cfg \
file://eth.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: appropriate for your project:
- :term:`SRC_URI`: The - :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``, 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 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. reference.
- :term:`LINUX_VERSION`: - :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 indicate to the OpenEmbedded build system that the recipe has
changed. changed.
- :term:`PV`: The default ``PV`` - :term:`PV`: The default :term:`PV`
assignment is typically adequate. It combines the 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` as derived from the :term:`SRCPV`
variable. The combined results are a string with the following variable. The combined results are a string with the following
form:: form::
3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2 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. using the exact sources from which you intend to build.
- :term:`COMPATIBLE_MACHINE`: - :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 different variable, you might want to override the
:ref:`ref-tasks-compile` step, or :ref:`ref-tasks-compile` step, or
create a patch to the ``Makefile`` to work with the more typical 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 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 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 configuring and patching the kernel. Therefore, adding features in this
manner is a way to enforce specific features are present and enabled 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 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 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 ``.scc`` file, which is relative to the root of the kernel Metadata. The
OpenEmbedded build system searches all forms of kernel Metadata on 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. "kernel-cache", system kernel Metadata, or a recipe-space Metadata (i.e.
part of the kernel recipe). See the part of the kernel recipe). See the
":ref:`kernel-dev/advanced:kernel metadata location`" section for ":ref:`kernel-dev/advanced:kernel metadata location`" section for
additional information. 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 statement, the OpenEmbedded build system adds the directory of that
``.scc`` file along with all its subdirectories to the kernel feature ``.scc`` file along with all its subdirectories to the kernel feature
search path. Because subdirectories are searched, you can reference a 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. kernel features.
Consider the following example that adds the "test.scc" feature to the 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 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 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:: .. note::
@ -1937,7 +1937,7 @@ build.
a similarly named configuration fragment file ``test.cfg``. a similarly named configuration fragment file ``test.cfg``.
2. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the 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" SRC_URI_append = " file://test.scc"
@ -1945,7 +1945,7 @@ build.
appended to the existing path. appended to the existing path.
3. *Specify the Feature as a Kernel Feature:* Use the 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:: feature::
KERNEL_FEATURES_append = " test.scc" 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 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 For example, you can add some helpful debug information doing the
following:: 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 repository organized under the "Yocto Linux Kernel" heading in the
:yocto_git:`Yocto Project Source Repositories <>`. :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 For a typical build, the target of the search is a feature
description in an ``.scc`` file whose name follows this format (e.g. 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`` :term:`IMAGE_FEATURES` should now include ``splash``
instead to enable the boot-up splash screen. Retaining instead to enable the boot-up splash screen. Retaining
``apps-console-core`` will still include the splash screen but generates a ``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. features have been removed.
.. _migration-1.3-removed-recipes: .. _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}" 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 could result with names that include two dash characters. Here is an
example:: 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``, and uninstall script functions ``pkg_preinst``, ``pkg_postinst``,
``pkg_prerm``, and ``pkg_postrm`` should always have a package name ``pkg_prerm``, and ``pkg_postrm`` should always have a package name
override. For example, use ``RDEPENDS_${PN}`` for the main package 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. parses recipes.
.. _migration-1.4-build-behavior: .. _migration-1.4-build-behavior:
@ -53,10 +53,10 @@ Differences include the following:
:term:`SRC_URI`, the build system now uses :term:`SRC_URI`, the build system now uses
:term:`FILESOVERRIDES` instead of :term:`FILESOVERRIDES` instead of
:term:`OVERRIDES` for the directory names. In :term:`OVERRIDES` for the directory names. In
general, the values previously in ``OVERRIDES`` are now in general, the values previously in :term:`OVERRIDES` are now in
``FILESOVERRIDES`` as well. However, if you relied upon an additional :term:`FILESOVERRIDES` as well. However, if you relied upon an additional
value you previously added to ``OVERRIDES``, you might now need to value you previously added to :term:`OVERRIDES`, you might now need to
add it to ``FILESOVERRIDES`` unless you are already adding it through add it to :term:`FILESOVERRIDES` unless you are already adding it through
the :term:`MACHINEOVERRIDES` or the :term:`MACHINEOVERRIDES` or
:term:`DISTROOVERRIDES` variables, as :term:`DISTROOVERRIDES` variables, as
appropriate. For more related changes, see the appropriate. For more related changes, see the
@ -105,7 +105,7 @@ Variables
The following variables have changed: 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 ID, which is composed of the host distributor ID followed by the
release. Previously, release. Previously,
:term:`SANITY_TESTED_DISTROS` was :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 you are not specifically setting this variable, or if you are
specifically setting it to "". specifically setting it to "".
- ``SRC_URI``: The ``${``\ :term:`PN`\ ``}``, - :term:`SRC_URI`: The ``${``\ :term:`PN`\ ``}``,
``${``\ :term:`PF`\ ``}``, ``${``\ :term:`PF`\ ``}``,
``${``\ :term:`P`\ ``}``, and ``FILE_DIRNAME`` directories ``${``\ :term:`P`\ ``}``, and ``FILE_DIRNAME`` directories
have been dropped from the default value of the 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:`P`\ ``}`` and
``${``\ :term:`PF`\ ``}`` are no longer added to ``${``\ :term:`PF`\ ``}`` are no longer added to
:term:`PROVIDES` by default in ``bitbake.conf``. :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 Attempting to use them could result in two versions being built
simultaneously rather than just one version due to the way BitBake simultaneously rather than just one version due to the way BitBake
resolves dependencies. 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 :term:`WARN_QA` values in your configuration, check
that they contain all of the issues that you wish to be reported. that they contain all of the issues that you wish to be reported.
Previous Yocto Project versions contained a bug that meant that any 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 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>`" now documented in the ":ref:`insane.bbclass <ref-classes-insane>`"
section. 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 - If you are using the ``buildhistory`` class, the check for the package
version going backwards is now controlled using a standard QA check. 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 and still wish to have this check performed, you should add
"version-going-backwards" to your value for one or the other "version-going-backwards" to your value for one or the other
variables depending on how you wish it to be handled. See the 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 - When buildhistory is enabled, its output is now written under the
:term:`Build Directory` rather than :term:`Build Directory` rather than
:term:`TMPDIR`. Doing so makes it easier to delete :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`. produced SDKs is now split by :term:`IMAGE_NAME`.
- The ``pkgdata`` directory produced as part of the packaging process - 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 The following changes have been made that relate to
:term:`IMAGE_FEATURES`: :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 feature items are not added. Some users mistakenly add package names
to this variable instead of using to this variable instead of using
:term:`IMAGE_INSTALL` in order to have the :term:`IMAGE_INSTALL` in order to have the
package added to the image, which does not work. This change is 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, are drawn from ``PACKAGE_GROUP`` definitions,
:term:`COMPLEMENTARY_GLOB` and a new :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 change allows additional features to be added if they are not
provided using the previous two mechanisms. provided using the previous two mechanisms.
- The previously deprecated "apps-console-core" ``IMAGE_FEATURES`` item - The previously deprecated "apps-console-core" :term:`IMAGE_FEATURES` item
is no longer supported. Add "splash" to ``IMAGE_FEATURES`` if you is no longer supported. Add "splash" to :term:`IMAGE_FEATURES` if you
wish to have the splash screen enabled, since this is all that wish to have the splash screen enabled, since this is all that
apps-console-core was doing. apps-console-core was doing.
@ -285,7 +285,7 @@ Following are changes to ``udev``:
``udev-extraconf`` to your image. ``udev-extraconf`` to your image.
- ``udev`` no longer brings in ``pciutils-ids`` or ``usbutils-ids`` - ``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. removing them saves around 350KB.
.. _migration-1.5-removed-renamed-recipes: .. _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 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), 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: .. _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 :term:`TMPDIR` can no longer be on an NFS mount. NFS does
not offer full POSIX locking and inode consistency and can cause 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. NFS mount, an error occurs.
.. _migration-1.6-variable-changes-PRINC: .. _migration-1.6-variable-changes-PRINC:
@ -274,7 +274,7 @@ In addition to ``core-image-basic`` being renamed,
Licensing 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, license of the various components of :term:`OpenEmbedded-Core (OE-Core)`. However,
the licensing itself remains unchanged. the licensing itself remains unchanged.
@ -284,7 +284,7 @@ recipes point to this file within
``${COREBASE}/LICENSE``) and thus the accompanying checksum must be ``${COREBASE}/LICENSE``) and thus the accompanying checksum must be
changed from 3f40d7994397109285ec7b81fdeb3b58 to changed from 3f40d7994397109285ec7b81fdeb3b58 to
4d92cd373abda3937c2bc47fbc49d690. A better alternative is to have 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, distributed with the source that the recipe is building, if possible,
rather than pointing to ``${COREBASE}/LICENSE``. 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 :term:`CFLAGS` value. You need to take action on
individual recipes that fail when building with this option. You need to 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 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: .. _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 also allows the values of these variables to be appropriately
incorporated into task signatures and thus trigger the appropriate tasks incorporated into task signatures and thus trigger the appropriate tasks
to re-execute when changed. You should replace any references to 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 modules for which ``module_conf_*`` is specified to
``KERNEL_MODULE_PROBECONF``. :term:`KERNEL_MODULE_PROBECONF`.
.. _migration-1.7-qa-check-changes: .. _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}``. instead of ``${D}``.
- :term:`S` now needs to be set to a valid value within a - :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 recipe. If :term:`S` is not set in the recipe, the directory is not
automatically created. If ``S`` does not point to a directory that automatically created. If :term:`S` does not point to a directory that
exists at the time the :ref:`ref-tasks-unpack` task exists at the time the :ref:`ref-tasks-unpack` task
finishes, a warning will be shown. 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. https://gcc.gnu.org/gcc-5/porting_to.html.
Alternatively, you can switch back to GCC 4.9 or 4.8 by setting 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%" GCCVERSION = "4.9%"
@ -244,7 +244,7 @@ The following QA checks have been added:
- Added an "invalid-packageconfig" check for any options specified in - Added an "invalid-packageconfig" check for any options specified in
:term:`PACKAGECONFIG` that do not match any :term:`PACKAGECONFIG` that do not match any
``PACKAGECONFIG`` option defined for the recipe. :term:`PACKAGECONFIG` option defined for the recipe.
.. _migration-2.0-miscellaneous: .. _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 now assumes lower-case characters in order to give a slight performance
boost during parsing. In practical terms, this requirement means that boost during parsing. In practical terms, this requirement means that
anything that ends up in :term:`OVERRIDES` must now anything that ends up in :term:`OVERRIDES` must now
appear in lower-case characters (e.g. values for ``MACHINE``, appear in lower-case characters (e.g. values for :term:`MACHINE`,
``TARGET_ARCH``, ``DISTRO``, and also recipe names if :term:`TARGET_ARCH`, :term:`DISTRO`, and also recipe names if
``_pn-``\ recipename overrides are to be effective). ``_pn-``\ recipename overrides are to be effective).
.. _migration-2.1-expand-parameter-to-getvar-and-getvarflag-now-mandatory: .. _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 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 must edit any recipe that relies upon this old default by either setting
``EXTRA_OEMAKE`` back to "-e MAKEFLAGS=" or by explicitly setting any ``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 typically only needed when a Makefile sets a default value for a
variable that is inappropriate for cross-compilation using the "=" variable that is inappropriate for cross-compilation using the "="
operator rather than the "?=" operator. operator rather than the "?=" operator.
@ -376,7 +376,7 @@ These additional changes exist:
run-postinsts run-postinsts
With the Yocto Project 2.1 release, these packages are 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 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 of a package manager (e.g. if users need to be added, modified, or
removed at runtime). 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 OpenEmbedded :term:`LDFLAGS`. This change could result in
seeing some "No GNU_HASH in the elf binary" QA issues when building such 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 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. 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 However, sometimes making this fix is as simple as adding the following
to the recipe:: to the recipe::
@ -291,7 +291,7 @@ The following changes took place for BitBake:
:term:`SRC_URI` parameters to specify these. This :term:`SRC_URI` parameters to specify these. This
change is more in-line with how the other fetchers work for source change is more in-line with how the other fetchers work for source
control systems. Recipes that fetch from Perforce will need to be 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``. within ``SRC_URI``.
- Some of BitBake's internal code structures for accessing the recipe - 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 to cause any problems for most users. However, the setscene
verification function as pointed to by verification function as pointed to by
``BB_SETSCENE_VERIFY_FUNCTION`` needed to change signature. ``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 has been added allowing multiple versions of BitBake to work with
suitably written metadata, which includes OpenEmbedded-Core and Poky. suitably written metadata, which includes OpenEmbedded-Core and Poky.
Anyone with custom BitBake task scheduler code might also need to 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 As an example, see the ``dbus`` recipe. You will see that this recipe
has a ``pkg_postinst`` that calls ``systemctl`` if "systemd" is in has a ``pkg_postinst`` that calls ``systemctl`` if "systemd" is in
:term:`DISTRO_FEATURES`. In the example, :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``. which is also conditional on "systemd" being in ``DISTRO_FEATURES``.
- Examine Recipes that Use ``SSTATEPOSTINSTFUNCS``: You need to - 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 removed because the script was found to be deleting files it should
not have, which lead to broken build trees. Rather than trying to not have, which lead to broken build trees. Rather than trying to
delete portions of :term:`TMPDIR` and getting it wrong, 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. from shared state (sstate) on subsequent builds.
- ``wipe-sysroot``: The ``wipe-sysroot`` script has been removed as - ``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 section in the BitBake
User Manual for additional information. 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 Removed: Because the mechanism they were part of is no longer
necessary with recipe-specific sysroots, the 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. variables have been removed.
.. _migration-2.3-absolute-symlinks: .. _migration-2.3-absolute-symlinks:
@ -426,10 +426,10 @@ The following miscellaneous changes have occurred:
- If the :term:`DISTRO_VERSION` value contains - If the :term:`DISTRO_VERSION` value contains
the value of the :term:`DATE` variable, which is the 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 excluded from ``/etc/issue`` and ``/etc/issue.net``, which is
displayed at the login prompt, in order to avoid conflicts with 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 ``base-files`` recipe is restored from shared state (sstate) rather
than rebuilt. than rebuilt.
@ -451,7 +451,7 @@ The following miscellaneous changes have occurred:
tools. tools.
- The ``USE_LDCONFIG`` variable has been replaced with the "ldconfig" - 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" USE_LDCONFIG = "0"
@ -494,12 +494,12 @@ The following miscellaneous changes have occurred:
information. information.
- All native and nativesdk recipes now use a separate - 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. 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 :term:`DISTRO_FEATURES_NATIVE` added to
an intersection of ``DISTRO_FEATURES`` and an intersection of :term:`DISTRO_FEATURES` and
:term:`DISTRO_FEATURES_FILTER_NATIVE`. :term:`DISTRO_FEATURES_FILTER_NATIVE`.
For nativesdk recipes, the corresponding variables are 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 - The ``ionice`` program is now packaged in a separate
"util-linux-ionice" package. The main ``util-linux`` package has a "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. ``util-linux-ionice`` package.
- ``initscripts``: The ``sushell`` program is now packaged in a - ``initscripts``: The ``sushell`` program is now packaged in a
@ -71,7 +71,7 @@ occurred:
systems to pull ``sushell`` in when ``selinux`` is enabled. The systems to pull ``sushell`` in when ``selinux`` is enabled. The
change also eliminates needing to pull in the entire ``initscripts`` change also eliminates needing to pull in the entire ``initscripts``
package. The main ``initscripts`` package has a runtime dependency 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``. ``DISTRO_FEATURES``.
- ``glib-2.0``: The ``glib-2.0`` package now has a recommended - ``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``. ``IMAGE_FSTYPES``.
- Recipes with an unconditional dependency on ``libpam`` are only - 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 truly optional then it is recommended that the dependency be
conditional upon ``pam`` being in ``DISTRO_FEATURES``. 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: The following changes have been made:
- Name variables (e.g. :term:`IMAGE_NAME`) use a new - Name variables (e.g. :term:`IMAGE_NAME`) use a new
``IMAGE_VERSION_SUFFIX`` variable instead of :term:`IMAGE_VERSION_SUFFIX` variable instead of
:term:`DATETIME`. Using ``IMAGE_VERSION_SUFFIX`` :term:`DATETIME`. Using :term:`IMAGE_VERSION_SUFFIX`
allows easier and more direct changes. 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:: configuration file as follows::
IMAGE_VERSION_SUFFIX = "-${DATETIME}" IMAGE_VERSION_SUFFIX = "-${DATETIME}"
@ -212,19 +212,19 @@ The following changes have been made:
The :term:`SERIAL_CONSOLE` variable has been The :term:`SERIAL_CONSOLE` variable has been
functionally replaced by the functionally replaced by the
:term:`SERIAL_CONSOLES` variable for some time. :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. 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 However, for the sake of future compatibility, it is recommended that
you replace all instances of ``SERIAL_CONSOLE`` with you replace all instances of :term:`SERIAL_CONSOLE` with
``SERIAL_CONSOLES``. :term:`SERIAL_CONSOLES`.
.. note:: .. 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 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: .. _migration-2.6-poky-sets-unknown-configure-option-to-qa-error:
@ -387,14 +387,14 @@ QEMU (i.e. "qemu-usermode" is in
default). default).
If you wish to disable Python profile-guided optimization regardless of 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 :term:`PACKAGECONFIG` for the ``python3`` recipe
does not contain "pgo". You could accomplish the latter using the does not contain "pgo". You could accomplish the latter using the
following at the configuration level:: following at the configuration level::
PACKAGECONFIG_remove_pn-python3 = "pgo" 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. for the ``python3`` recipe.
.. _migration-2.6-miscellaneous-changes: .. _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 package_name\ ``-src``). If you are currently using ``dbg-pkgs`` in
:term:`IMAGE_FEATURES` to bring in debug :term:`IMAGE_FEATURES` to bring in debug
symbols and you still need the sources, you must now also add 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 target portion of the SDK by default, unless you have set your own
value for :term:`SDKIMAGE_FEATURES` that value for :term:`SDKIMAGE_FEATURES` that
does not include ``src-pkgs``. 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 - 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 dynamically set based upon license files found in
``${COMMON_LICENSE_DIR}`` and ``${LICENSE_PATH}``. ``${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 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, ``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 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 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, 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. be monitoring.
In addition, pseudo's behaviour on mismatches has now been changed - rather 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`` 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. 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 One useful scenario for using the ``conf/site.conf`` file is to
extend your :term:`BBPATH` variable extend your :term:`BBPATH` variable
to include the path to a ``conf/site.conf``. Then, when BitBake looks 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 and applies your common configurations found in the file. To override
configurations in a particular build directory, alter the similar configurations in a particular build directory, alter the similar
configurations within that build directory's ``conf/local.conf`` 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` BitBake uses the :term:`SRC_URI`
variable to point to source files regardless of their location. Each 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 Another area that plays a significant role in where source files come
from is pointed to by the 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 a cache that can hold previously downloaded source. You can also
instruct the OpenEmbedded build system to create tarballs from Git instruct the OpenEmbedded build system to create tarballs from Git
repositories, which is not the default behavior, and store them in the 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` :term:`BB_GENERATE_MIRROR_TARBALLS`
variable. 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 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 your Build Directory. Doing so allows you to safely delete the Build
Directory if needed without fear of removing any downloaded source file. 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 architecture of the built package or packages. Depending on the
eventual destination of the package or packages (i.e. machine eventual destination of the package or packages (i.e. machine
architecture, :term:`Build Host`, SDK, or 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. description for details.
- :term:`TARGET_OS`: The operating - :term:`TARGET_OS`: The operating
@ -756,7 +756,7 @@ Build Directory's hierarchy:
- :term:`PN`: The name of the recipe used - :term:`PN`: The name of the recipe used
to build the package. This variable can have multiple meanings. 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. the name of the recipe.
- :term:`WORKDIR`: The location - :term:`WORKDIR`: The location
@ -773,7 +773,7 @@ Build Directory's hierarchy:
files for a given recipe. files for a given recipe.
- :term:`BPN`: The name of the 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. the ``PN`` variable but with common prefixes and suffixes removed.
- :term:`PV`: The version of the - :term:`PV`: The version of the
@ -803,13 +803,13 @@ and the :term:`FILESPATH` variable
to locate applicable patch files. to locate applicable patch files.
Default processing for patch files assumes the files have either 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 to change the way the build system recognizes patch files. See the
:ref:`ref-tasks-patch` task for more :ref:`ref-tasks-patch` task for more
information. information.
BitBake finds and applies multiple patches for a single recipe in the 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 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 search for patch files. Once found, patches are applied to the recipe's
source files, which are located in the 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. :ref:`ref-tasks-compile` task.
Compilation occurs in the directory pointed to by the Compilation occurs in the directory pointed to by the
:term:`B` variable. Realize that 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. :term:`S` directory.
- *do_install*: After compilation completes, BitBake executes the - *do_install*: After compilation completes, BitBake executes the
:ref:`ref-tasks-install` task. :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` holding area pointed to by the :term:`D`
variable. Packaging occurs later using files from this holding variable. Packaging occurs later using files from this holding
directory. directory.
@ -928,7 +928,7 @@ the analysis and package splitting process use several areas:
- :term:`PKGDATA_DIR`: A shared, - :term:`PKGDATA_DIR`: A shared,
global-state directory that holds packaging metadata generated during global-state directory that holds packaging metadata generated during
the packaging process. The packaging process copies metadata from 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. available.
- :term:`STAGING_DIR_HOST`: - :term:`STAGING_DIR_HOST`:
@ -1008,7 +1008,7 @@ actually install:
With :term:`IMAGE_ROOTFS` With :term:`IMAGE_ROOTFS`
pointing to the location of the filesystem under construction and the 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. install, the root file system is created.
Package installation is under control of the package manager (e.g. 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 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 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 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. support compression.
As an example, a dynamically created task when creating a particular 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 do_image_type
So, if the 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:: generated task would be as follows::
do_image_ext4 do_image_ext4
@ -1171,9 +1171,9 @@ the task is rerun.
the sstate cache mechanism adds is a way to cache task output that the sstate cache mechanism adds is a way to cache task output that
can then be shared between build machines. can then be shared between build machines.
Since ``STAMPS_DIR`` is usually a subdirectory of ``TMPDIR``, removing Since :term:`STAMPS_DIR` is usually a subdirectory of :term:`TMPDIR`, removing
``TMPDIR`` will also remove ``STAMPS_DIR``, which means tasks will :term:`TMPDIR` will also remove :term:`STAMPS_DIR`, which means tasks will
properly be rerun to repopulate ``TMPDIR``. properly be rerun to repopulate :term:`TMPDIR`.
If you want some task to always be considered "out of date", you can 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>` 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`: - :term:`TOOLCHAIN_HOST_TASK`:
Lists packages that make up the host part of the SDK (i.e. the part 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 ``bitbake -c populate_sdk imagename`` to create the SDK, a set of
default packages apply. This variable allows you to add more default packages apply. This variable allows you to add more
packages. packages.
@ -1614,7 +1614,7 @@ them if they are deemed to be valid.
:term:`PR` information as part of :term:`PR` information as part of
the shared state packages. Consequently, there are considerations that the shared state packages. Consequently, there are considerations that
affect maintaining shared state feeds. For information on how the 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`" information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
section in the Yocto Project Development Tasks Manual. 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 build host. However, cross packages generate output for the target
architecture. architecture.
The checksum therefore needs to exclude ``WORKDIR``. The simplistic The checksum therefore needs to exclude :term:`WORKDIR`. The simplistic
approach for excluding the work directory is to set ``WORKDIR`` to some approach for excluding the work directory is to set :term:`WORKDIR` to some
fixed value and create the checksum for the "run" script. fixed value and create the checksum for the "run" script.
Another problem results from the "run" scripts containing functions that 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 dependencies, and then creates a checksum for the data used as the input
to the task. 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 ignored. For these situations, you can instruct the build process to
ignore a dependency by using a line like the following:: ignore a dependency by using a line like the following::
@ -1707,7 +1707,7 @@ following::
PACKAGE_ARCHS[vardeps] = "MACHINE" PACKAGE_ARCHS[vardeps] = "MACHINE"
This example explicitly 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 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 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" 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 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 files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This
results in any metadata change that changes the task hash, automatically causing 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 - ``BBHASHDEPS_``\ filename\ ``:``\ taskname: The task dependencies for
each task. each task.
- ``BB_TASKHASH``: The hash of the currently running task. - :term:`BB_TASKHASH`: The hash of the currently running task.
Shared State 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 ``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 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 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. instead, skipping the ``do_deploy`` task.
- The following task definition is glue logic needed to make the - 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 - ``sstate-inputdirs`` and ``sstate-outputdirs`` can also be used with
multiple directories. For example, the following declares multiple directories. For example, the following declares
``PKGDESTWORK`` and ``SHLIBWORK`` as shared state input directories, :term:`PKGDESTWORK` and ``SHLIBWORK`` as shared state input directories,
which populates the shared state cache, and ``PKGDATA_DIR`` and which populates the shared state cache, and :term:`PKGDATA_DIR` and
``SHLIBSDIR`` as the corresponding shared state output directories:: ``SHLIBSDIR`` as the corresponding shared state output directories::
do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}" 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 subdirectories, where the subdirectory names are based on the first two
characters of the hash. characters of the hash.
If the shared state directory structure for a mirror has the same structure 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. system to map to the appropriate subdirectory.
The shared state package validity can be detected just by looking at the 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 Simultaneously, all executables and shared libraries installed by the
recipe are inspected to see what shared libraries they link against. 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) queried to see if some package (likely from a different recipe)
contains the shared library. If such a package is found, a runtime contains the shared library. If such a package is found, a runtime
dependency is added from the package that depends on the shared 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 The automatically added runtime dependency also includes a version
restriction. This version restriction specifies that at least the restriction. This version restriction specifies that at least the
current version of the package that provides the shared library must 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 This forces an upgrade of the package containing the shared library
when installing the package that depends on the library, if needed. 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 pkg-config modules (``*.pc`` files) installed by the recipe are
located. For each module, the package that contains the module is located. For each module, the package that contains the module is
registered as providing the module. The resulting module-to-package 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. ``do_packagedata`` task.
Simultaneously, all pkg-config modules installed by the recipe are Simultaneously, all pkg-config modules installed by the recipe are
inspected to see what other pkg-config modules they depend on. A inspected to see what other pkg-config modules they depend on. A
module is seen as depending on another module if it contains a module is seen as depending on another module if it contains a
"Requires:" line that specifies the other module. For each module "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 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 is added from the package that depends on the module to the package
that contains the module. 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>`\ ``]`` of a ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
declaration, which guarantees that the required declaration, which guarantees that the required
shared-library/module-to-package mapping information will be available 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 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 ``do_package_write_*`` tasks to
have different signatures for the machines with different tunings. have different signatures for the machines with different tunings.
Additionally, unnecessary rebuilds occur every time an image for a 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 By default, all recipes inherit the :ref:`base <ref-classes-base>` and
:ref:`package <ref-classes-package>` classes, which enable :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 - :ref:`ref-tasks-configure` - Regenerates the
configure script (using ``autoreconf``) and then launches it with a configure script (using ``autoreconf``) and then launches it with a
standard set of arguments used during cross-compilation. You can pass 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` or :term:`PACKAGECONFIG_CONFARGS`
variables. variables.
@ -168,7 +168,7 @@ example use for this class.
the "subpath" parameter limits the checkout to a specific subpath 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 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 are extracted into the subdirectory expected by the default value of
``S``:: :term:`S`::
SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}" 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 :term:`USER_CLASSES` variable from your
``local.conf`` file. Consequently, you do not have to do anything to ``local.conf`` file. Consequently, you do not have to do anything to
enable the class. However, if you want to disable the class, simply 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: .. _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 add the task at the appropriate place, which is usually after
:ref:`ref-tasks-compile` or :ref:`ref-tasks-compile` or
:ref:`ref-tasks-install`. The class then takes care of :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: .. _ref-classes-devshell:
@ -474,7 +474,7 @@ The class
currently only supports creating a development variant of the target currently only supports creating a development variant of the target
recipe, not ``native`` or ``nativesdk`` variants. 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 support for ``native`` and ``nativesdk`` variants. Consequently, this
functionality can be added in a future release. 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 ``externalsrc`` class, you use the
:term:`EXTERNALSRC` and :term:`EXTERNALSRC` and
:term:`EXTERNALSRC_BUILD` variables to :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 By default, this class expects the source code to support recipe builds
that use the :term:`B` variable to point to the directory in that use the :term:`B` variable to point to the directory in
which the OpenEmbedded build system places the generated objects built which the OpenEmbedded build system places the generated objects built
from the recipes. By default, the ``B`` directory is set to the from the recipes. By default, the :term:`B` directory is set to the
following, which is separate from the source directory (``S``):: following, which is separate from the source directory (:term:`S`)::
${WORKDIR}/${BPN}/{PV}/ ${WORKDIR}/${BPN}/{PV}/
@ -689,8 +689,8 @@ introspection. This functionality is only enabled if the
.. note:: .. note::
This functionality is backfilled by default and, if not applicable, This functionality is backfilled by default and, if not applicable,
should be disabled through ``DISTRO_FEATURES_BACKFILL_CONSIDERED`` or should be disabled through :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED` or
``MACHINE_FEATURES_BACKFILL_CONSIDERED``, respectively. :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`, respectively.
.. _ref-classes-grub-efi: .. _ref-classes-grub-efi:
@ -838,7 +838,7 @@ using an empty :term:`PARALLEL_MAKE` variable.
Inheriting the ``icecc`` class changes all sstate signatures. Inheriting the ``icecc`` class changes all sstate signatures.
Consequently, if a development team has a dedicated build system that Consequently, if a development team has a dedicated build system that
populates :term:`SSTATE_MIRRORS` and they want to 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. system need to either inherit the ``icecc`` class or nobody should.
At the distribution level, you can inherit the ``icecc`` class to be 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 ``rootfs*.bbclass`` files (depending on the package format used) and
then one or more image files are created. 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. 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. install into the image.
For information on customizing images, see the For information on customizing images, see the
@ -916,7 +916,7 @@ The ``image_types`` class also handles conversion and compression of images.
.. note:: .. note::
To build a VMware VMDK image, you need to add "wic.vmdk" to 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. Image ("vdi") and QEMU Copy On Write Version 2 ("qcow2") images.
.. _ref-classes-image-live: .. _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 are meant to detect real or potential problems in the packaged
output. So exercise caution when disabling these checks. 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: ``ERROR_QA`` variables:
- ``already-stripped:`` Checks that produced binaries have not - ``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] = "..." 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 file containing these paths is incorrect since ``libtool`` adds the
correct sysroot prefix when using the files automatically itself. correct sysroot prefix when using the files automatically itself.
- ``ldflags:`` Ensures that the binaries were linked with the - ``ldflags:`` Ensures that the binaries were linked with the
:term:`LDFLAGS` options provided by the build system. :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. passed to the linker command.
- ``libdir:`` Checks for libraries being installed into incorrect - ``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 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`. undefined during :ref:`ref-tasks-package`.
- ``pkgvarcheck:`` Checks through the variables - ``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 - ``pn-overrides:`` Checks that a recipe does not have a name
(:term:`PN`) value that appears in (:term:`PN`) value that appears in
:term:`OVERRIDES`. If a recipe is named such that :term:`OVERRIDES`. If a recipe is named such that
its ``PN`` value matches something already in ``OVERRIDES`` (e.g. its :term:`PN` value matches something already in :term:`OVERRIDES` (e.g.
``PN`` happens to be the same as :term:`MACHINE` or :term:`PN` happens to be the same as :term:`MACHINE` or
:term:`DISTRO`), it can have unexpected consequences. :term:`DISTRO`), it can have unexpected consequences.
For example, assignments such as ``FILES_${PN} = "xyz"`` effectively For example, assignments such as ``FILES_${PN} = "xyz"`` effectively
turn into ``FILES = "xyz"``. 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" SOURCE_MIRROR_URL = "http://example.com/my-source-mirror"
You can specify only a single URL You can specify only a single URL
in ``SOURCE_MIRROR_URL``. in :term:`SOURCE_MIRROR_URL`.
.. _ref-classes-package: .. _ref-classes-package:
@ -1749,7 +1749,7 @@ package-specific classes:
use this class. use this class.
You can control the list of resulting package formats by using the 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`. configuration file, which is located in the :term:`Build Directory`.
When defining the variable, you can When defining the variable, you can
specify one or more package types. Since images are generated from 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. complete build of the package with all dependencies previously built.
The reason for this discrepancy is because the RPM package manager The reason for this discrepancy is because the RPM package manager
creates and processes more :term:`Metadata` than the IPK package 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. "package_ipk" if you are building smaller systems.
Before making your package manager decision, however, you should Before making your package manager decision, however, you should
@ -1852,7 +1852,7 @@ variable in the ``local.conf`` file.
.. note:: .. note::
You cannot specify the ``package_tar`` class first using the 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. file formats for your image or SDK.
.. _ref-classes-packagedata: .. _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 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 so forth). It is highly recommended that all package group recipes
inherit this class. 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 recipe, enabling ``rm_work`` will potentially result in your changes to
the source being lost. To exclude some recipes from having their work 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 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:: can also be set in your ``local.conf`` file. Here is an example::
RM_WORK_EXCLUDE += "busybox glibc" 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 values available. The ``meta/site directory`` contains test results
sorted into different categories such as architecture, endianness, and sorted into different categories such as architecture, endianness, and
the ``libc`` used. Site information provides a list of files containing 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. Autotools automatically picks up.
The class also provides variables like ``SITEINFO_ENDIANNESS`` and The class also provides variables like :term:`SITEINFO_ENDIANNESS` and
``SITEINFO_BITS`` that can be used elsewhere in the metadata. :term:`SITEINFO_BITS` that can be used elsewhere in the metadata.
.. _ref-classes-sstate: .. _ref-classes-sstate:
@ -2363,7 +2363,7 @@ stages:
.. note:: .. note::
Additionally, a recipe can customize the files further by 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. variable.
A shared state (sstate) object is built from these files and the 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 recommended for general use, the files do allow some issues such
as user creation and module indexes to be addressed. 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"``), (e.g. ``do_unpack[depends] += "tar-native:do_populate_sysroot"``),
the sysroot creation function ``extend_recipe_sysroot`` is also added the sysroot creation function ``extend_recipe_sysroot`` is also added
as a pre-function for those tasks whose dependencies are not through 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 When installing dependencies into the sysroot, the code traverses the
dependency graph and processes dependencies in exactly the same way 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 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. before a package is removed and started when the package is installed.
Three variables control this class: ``INITSCRIPT_PACKAGES``, Three variables control this class: :term:`INITSCRIPT_PACKAGES`,
``INITSCRIPT_NAME`` and ``INITSCRIPT_PARAMS``. See the variable links :term:`INITSCRIPT_NAME` and :term:`INITSCRIPT_PARAMS`. See the variable links
for details. for details.
.. _ref-classes-useradd: .. _ref-classes-useradd:
@ -2790,9 +2790,9 @@ additional information.
.. note:: .. note::
You do not use the ``useradd-staticids`` class directly. You either enable 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 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. directory will correct this condition.
.. _ref-classes-utility-tasks: .. _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 but the package is being marked as machine-specific in all cases, how do
I prevent this? 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 but make sure the package is manually marked as machine-specific for the
case that needs it. The code that handles 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. ``meta/classes/base.bbclass`` file.
**Q:** I'm behind a firewall and need to use a proxy server. How do I do **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` :term:`IMAGE_ROOTFS_EXTRA_SPACE`
variable to add additional free space to the image. The build system variable to add additional free space to the image. The build system
adds this space to the image after it determines its 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? **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? **Q:** How do I use an external toolchain?
**A:** The toolchain configuration is very flexible and customizable. It **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 controls which ``tcmode-*.inc`` file to include from the
``meta/conf/distro/include`` directory within the :term:`Source Directory`. ``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. OpenEmbedded build system to use its internally built toolchain (i.e.
``tcmode-default.inc``). However, other patterns are accepted. In ``tcmode-default.inc``). However, other patterns are accepted. In
particular, "external-\*" refers to external toolchains. One example is particular, "external-\*" refers to external toolchains. One example is
@ -325,7 +325,7 @@ Here is another technique::
BB_FETCH_PREMIRRORONLY = "1" BB_FETCH_PREMIRRORONLY = "1"
This statement 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. Again, this technique is useful for reproducing builds.
Here is another technique:: 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. Finally, consider an example where you are behind an HTTP-only firewall.
You could make the following changes to the ``local.conf`` configuration 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 = "\ PREMIRRORS_prepend = "\
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ 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 These changes would cause the build system to successfully fetch source
over HTTP and any network accesses to anything other than the 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 The build system also honors the standard shell environment variables
``http_proxy``, ``ftp_proxy``, ``https_proxy``, and ``all_proxy`` to ``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 Features provide a mechanism for working out which packages should be
included in the generated images. Distributions can select which 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 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. 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 set in the machine configuration file and specifies the hardware
features for a given machine. 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 - *ssh-server-openssh:* Installs the OpenSSH SSH server, which is more
full-featured than Dropbear. Note that if both the OpenSSH SSH server full-featured than Dropbear. Note that if both the OpenSSH SSH server
and the Dropbear minimal SSH server are present in 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. will not be installed.
- *tools-debug:* Installs debugging tools such as ``strace`` and - *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 - *The "pulseaudio" distro feature option*: Previously, PulseAudio
support was enabled within the Qt and GStreamer frameworks. Because support was enabled within the Qt and GStreamer frameworks. Because
of this, the feature is backfilled and thus enabled for all distros 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 ``meta/conf/bitbake.conf`` file. However, your distro needs to
disable the feature. You can disable the feature without affecting disable the feature. You can disable the feature without affecting
other existing distro configurations that need PulseAudio support by 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 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 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. feature for that particular distro.
- *The "rtc" machine feature option*: Previously, real time clock (RTC) - *The "rtc" machine feature option*: Previously, real time clock (RTC)
support was enabled for all target devices. Because of this, the support was enabled for all target devices. Because of this, the
feature is backfilled and thus enabled for all machines through 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 ``meta/conf/bitbake.conf`` file. However, your target device does not
have this capability. You can disable RTC support for your device have this capability. You can disable RTC support for your device
without affecting other machines that need RTC support by adding the 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 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 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. 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 A file-level dependency has been identified from the specified
package on the specified files, but there is no explicit package on the specified files, but there is no explicit
corresponding entry in :term:`RDEPENDS`. If 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 declared in the recipe to ensure the packages providing them are
built. built.
@ -104,7 +104,7 @@ Errors and Warnings
:term:`RDEPENDS` value being added at the packaging :term:`RDEPENDS` value being added at the packaging
stage rather than up front, which is usually automatic based on the stage rather than up front, which is usually automatic based on the
contents of the package. In most cases, you should change the recipe 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: .. _qa-check-dev-so:
@ -152,7 +152,7 @@ Errors and Warnings
not explicitly add the ``.debug`` directory to the ``-dbg`` package. not explicitly add the ``.debug`` directory to the ``-dbg`` package.
If this is the case, add the ``.debug`` directory explicitly to If this is the case, add the ``.debug`` directory explicitly to
``FILES_${PN}-dbg``. See :term:`FILES` for additional ``FILES_${PN}-dbg``. See :term:`FILES` for additional
information on ``FILES``. information on :term:`FILES`.
   
.. _qa-check-arch: .. _qa-check-arch:
@ -235,9 +235,9 @@ Errors and Warnings
This indicates that binaries produced when building the recipe have This indicates that binaries produced when building the recipe have
not been linked with the :term:`LDFLAGS` options 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 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 :term:`TARGET_CC_ARCH` within the recipe as
follows:: follows::
@ -403,7 +403,7 @@ Errors and Warnings
If your recipe name does not match this, or you add packages to If your recipe name does not match this, or you add packages to
:term:`PACKAGES` that do not conform to the :term:`PACKAGES` that do not conform to the
convention, then you will receive this error. Rename your recipe. Or, 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. change the package name appropriately.
   
@ -431,13 +431,13 @@ Errors and Warnings
The specified recipe has a name (:term:`PN`) value that The specified recipe has a name (:term:`PN`) value that
appears in :term:`OVERRIDES`. If a recipe is named appears in :term:`OVERRIDES`. If a recipe is named
such that its ``PN`` value matches something already in ``OVERRIDES`` such that its :term:`PN` value matches something already in :term:`OVERRIDES`
(e.g. ``PN`` happens to be the same as :term:`MACHINE` (e.g. :term:`PN` happens to be the same as :term:`MACHINE`
or :term:`DISTRO`), it can have unexpected or :term:`DISTRO`), it can have unexpected
consequences. For example, assignments such as consequences. For example, assignments such as
``FILES_${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``. ``FILES_${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``.
Rename your recipe (or if ``PN`` is being set explicitly, change the Rename your recipe (or if :term:`PN` is being set explicitly, change the
``PN`` value) so that the conflict does not occur. See :term:`PN` value) so that the conflict does not occur. See
:term:`FILES` for additional information. :term:`FILES` for additional information.
   
@ -464,7 +464,7 @@ Errors and Warnings
This check looks for instances of setting ``DEPENDS_${PN}`` This check looks for instances of setting ``DEPENDS_${PN}``
which is erroneous (:term:`DEPENDS` is a recipe-wide variable and thus 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 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: .. _qa-check-already-stripped:
@ -499,7 +499,7 @@ Errors and Warnings
Package names must appear only once in the Package names must appear only once in the
:term:`PACKAGES` variable. You might receive this :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. 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 in an image later on in the build process. You need to do one of the
following: 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 in (e.g. ``FILES_${``\ :term:`PN`\ ``}`` for the main
package). 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. relatively rare.
At a minimum, you would normally edit this file to select the target 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 (: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 If ``local.conf`` is not present when you start the build, the
OpenEmbedded build system creates it from ``local.conf.sample`` when you 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 This directory contains downloaded upstream source tarballs. You can
reuse the directory for multiple builds or move the directory to another reuse the directory for multiple builds or move the directory to another
location. You can control the location of this directory through the location. You can control the location of this directory through the
``DL_DIR`` variable. :term:`DL_DIR` variable.
.. _structure-build-sstate-cache: .. _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 This directory contains the shared state cache. You can reuse the
directory for multiple builds or move the directory to another location. directory for multiple builds or move the directory to another location.
You can control the location of this directory through the You can control the location of this directory through the
``SSTATE_DIR`` variable. :term:`SSTATE_DIR` variable.
.. _structure-build-tmp: .. _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 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 ``do_check_pkg`` or ``do_distro_check`` tasks. Running a build does not
necessarily mean this directory is created. 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`` example, consider ``linux-yocto-kernel-3.0`` on the machine ``qemux86``
built within the Yocto Project. For this package, a work directory of built within the Yocto Project. For this package, a work directory of
``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred ``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. 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 (See the ":ref:`dev-manual/common-tasks:using quilt in your workflow`" section in
the Yocto Project Development Tasks Manual for more information.) Within 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 directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and
standard Quilt commands can be used. 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 important directory is ``WORKDIR/temp/``, which has log files for each
task (``log.do_*.pid``) and contains the scripts BitBake runs 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 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 The contents of this directory controls any distribution-specific
configurations. For the Yocto Project, the ``defaultsetup.conf`` is the 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 definitions for applications that are configured here. An example of an
alternative configuration might be ``poky-bleeding.conf``. Although this alternative configuration might be ``poky-bleeding.conf``. Although this
file mainly inherits its configuration from Poky. 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 The default behavior of this task is to run ``oe_runmake clean`` if a
makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found and makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found and
:term:`CLEANBROKEN` is not set to "1". If no such :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. ``do_configure`` task does nothing.
.. _ref-tasks-configure_ptest_base: .. _ref-tasks-configure_ptest_base:
@ -308,17 +308,17 @@ This recipe has two patch files located here::
poky/meta/recipes-connectivity/bluez5/bluez5 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. and patch files needed to build the package.
.. note:: .. 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``. are from an include file ``bluez5.inc``.
As mentioned earlier, the build system treats files whose file types are As mentioned earlier, the build system treats files whose file types are
``.patch`` and ``.diff`` as patch files. However, you can use the ``.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:: file as a patch file::
SRC_URI = " \ 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 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 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 the patch phase, you can use the "apply=no" parameter with the
``SRC_URI`` statement:: :term:`SRC_URI` statement::
SRC_URI = " \ SRC_URI = " \
git://path_to_repo/some_package \ 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 reside. For more information on how source files are unpacked, see the
":ref:`overview-manual/concepts:source fetching`" ":ref:`overview-manual/concepts:source fetching`"
section in the Yocto Project Overview and Concepts Manual and also see 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 Manually Called Tasks
===================== =====================

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

@ -97,11 +97,11 @@ universal, the list includes them just in case:
.. note:: .. note::
By default, the Build Directory contains :term:`TMPDIR`, which is a 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 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 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 set this up by setting :term:`TMPDIR` in your ``local.conf`` file to use a local
drive. Doing so effectively separates ``TMPDIR`` from :term:`TOPDIR`, which is the drive. Doing so effectively separates :term:`TMPDIR` from :term:`TOPDIR`, which is the
Build Directory. Build Directory.
:term:`Build Host` :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. variables control the set of packages adding to the SDK.
If you want to add individual packages to the toolchain that runs on the 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 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 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 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 - Variables listed in
:term:`SDK_LOCAL_CONF_WHITELIST` :term:`SDK_LOCAL_CONF_WHITELIST`
are included. Including a variable in the value of 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. filters. The default value is blank.
- Classes inherited globally with - Classes inherited globally with
:term:`INHERIT` that are listed in :term:`INHERIT` that are listed in
:term:`SDK_INHERIT_BLACKLIST` :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 classes is the typical method to disable classes that are problematic
or unnecessary in the SDK context. The default value blacklists the or unnecessary in the SDK context. The default value blacklists the
:ref:`buildhistory <ref-classes-buildhistory>` :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 - 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 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. variable as described in the previous section.
- Generally, you want to have a shared state mirror set up so users of - 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 By default, this title is derived from
:term:`DISTRO_NAME` when it is :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. from the :term:`DISTRO` variable.
The The
:ref:`populate_sdk_base <ref-classes-populate-sdk-*>` :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:: follows::
SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" 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 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 "meta-mydistro" and you are using the same type of file hierarchy as
does the default "poky" distribution. If so, you could update the 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 ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following
form:: form::
@ -220,7 +220,7 @@ class as follows::
You can You can
change this default installation directory by specifically setting the change this default installation directory by specifically setting the
``SDKEXTPATH`` variable. :term:`SDKEXTPATH` variable.
While there are several ways of setting this variable, While there are several ways of setting this variable,
the method that makes the most sense is to set the variable in your 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 assume you have your own layer for your distribution named
"meta-mydistro" and you are using the same type of file hierarchy as "meta-mydistro" and you are using the same type of file hierarchy as
does the default "poky" distribution. If so, you could update the 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 ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following
form:: form::
@ -284,11 +284,11 @@ source, you need to do a number of things:
SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS" 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 variable's value for the SDK alone, create a
``conf/sdk-extra.conf`` file either in your ``conf/sdk-extra.conf`` file either in your
:term:`Build Directory` or within any :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:: .. note::
@ -333,7 +333,7 @@ following::
See the :term:`SDK_INCLUDE_PKGDATA` variable for additional information. 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 target to be built so that information for all of the recipes included
within it are available. Having these recipes available increases build within it are available. Having these recipes available increases build
time significantly and increases the size of the SDK installer by 30-80 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 you build an SDK by setting the
:term:`SDK_INCLUDE_TOOLCHAIN` :term:`SDK_INCLUDE_TOOLCHAIN`
variable to "1". In particular, it is useful to include the 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 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 SDK for use with an IDE or some other tool where you do not want to take
extra steps to install a toolchain. 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 With this scenario, there is no ``srctree`` argument. Consequently, the
default behavior of the ``devtool modify`` command is to extract 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 local Git structure. Furthermore, the location for the extracted
source is the default area within the ``devtool`` workspace. The source is the default area within the ``devtool`` workspace. The
result is that the command sets up both the source code and an result is that the command sets up both the source code and an
@ -446,7 +446,7 @@ command:
original location. original location.
Additionally, if you have any non-patch local files (i.e. files 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 excluding ``*.patch/`` or ``*.diff``), these files are copied to
an ``oe-local-files`` folder under the newly created source tree. an ``oe-local-files`` folder under the newly created source tree.
Copying the files here gives you a convenient area from which you Copying the files here gives you a convenient area from which you
@ -476,7 +476,7 @@ command:
devtool devtool
command. 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 statements to locate the source files and any associated patch
files. Non-patch files are copied to an ``oe-local-files`` folder files. Non-patch files are copied to an ``oe-local-files`` folder
under the newly created source tree. 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 don't use "-V", the command upgrades the recipe to the latest
version. 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 recipe are in a Git repository, you must provide the "-S" option and
specify a revision for the software. 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 to locate the source code and any local patch files from other
developers. The result is that the command sets up the source code, 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 the new version of the recipe, and an append file all within the
workspace. workspace.
Additionally, if you have any non-patch local files (i.e. files 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 excluding ``*.patch/`` or ``*.diff``), these files are copied to an
``oe-local-files`` folder under the newly created source tree. ``oe-local-files`` folder under the newly created source tree.
Copying the files here gives you a convenient area from which you can 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 2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
after upgrading the software to a new version. Conflicts occur 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 conflict with changes made in the new version of the software. For
such cases, you need to resolve the conflicts by editing the source such cases, you need to resolve the conflicts by editing the source
and following the normal ``git rebase`` conflict resolution process. 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 is not available. For cases where the dependency is not available, you
must use the ``devtool add`` command to add an additional recipe that must use the ``devtool add`` command to add an additional recipe that
satisfies the dependency. Once you add that recipe, you need to update 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. recipe.
If you need to add runtime dependencies, you can do so by adding the 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. :term:`LICENSE` value accordingly.
You should double-check the value added by the command against the You should double-check the value added by the command against the
documentation or source files for the software you are building and, if 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 The ``devtool add`` command also sets the
:term:`LIC_FILES_CHKSUM` :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 that license statements often appear in comments at the top of source
files or within the documentation. In such cases, the command does not files or within the documentation. In such cases, the command does not
recognize those license statements. Consequently, you might need to recognize those license statements. Consequently, you might need to
amend the ``LIC_FILES_CHKSUM`` variable to point to one or more of those amend the :term:`LIC_FILES_CHKSUM` variable to point to one or more of those
comments if present. Setting ``LIC_FILES_CHKSUM`` is particularly comments if present. Setting :term:`LIC_FILES_CHKSUM` is particularly
important for third-party software. The mechanism attempts to ensure important for third-party software. The mechanism attempts to ensure
correct licensing should you upgrade the recipe to a newer upstream correct licensing should you upgrade the recipe to a newer upstream
version in future. Any change in licensing is detected and you receive version in future. Any change in licensing is detected and you receive
an error prompting you to check the license text again. an error prompting you to check the license text again.
If the ``devtool add`` command cannot determine licensing information, If the ``devtool add`` command cannot determine licensing information,
``devtool`` sets the ``LICENSE`` value to "CLOSED" and leaves the ``devtool`` sets the :term:`LICENSE` value to "CLOSED" and leaves the
``LIC_FILES_CHKSUM`` value unset. This behavior allows you to continue :term:`LIC_FILES_CHKSUM` value unset. This behavior allows you to continue
with development even though the settings are unlikely to be correct in with development even though the settings are unlikely to be correct in
all cases. You should check the documentation or source files for the all cases. You should check the documentation or source files for the
software you are building to determine the actual license. software you are building to determine the actual license.
@ -904,7 +904,7 @@ mind:
hardcoding tools within the toolchain such as ``gcc`` and ``g++``. hardcoding tools within the toolchain such as ``gcc`` and ``g++``.
- The environment in which Make runs is set up with various standard - 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 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 setup script. One easy way to see these variables is to run the
``devtool build`` command on the recipe and then look in ``devtool build`` command on the recipe and then look in
@ -920,7 +920,7 @@ mind:
the command line, add the variable setting to the command line, add the variable setting to
:term:`EXTRA_OEMAKE` or :term:`EXTRA_OEMAKE` or
:term:`PACKAGECONFIG_CONFARGS` :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}'" EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'"
@ -1086,20 +1086,20 @@ extras specified by
:term:`EXTRA_OECONF` or :term:`EXTRA_OECONF` or
:term:`PACKAGECONFIG_CONFARGS` :term:`PACKAGECONFIG_CONFARGS`
set within the recipe. If you wish to pass additional options, add them 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. tools have similar variables (e.g.
:term:`EXTRA_OECMAKE` for :term:`EXTRA_OECMAKE` for
CMake, :term:`EXTRA_OESCONS` CMake, :term:`EXTRA_OESCONS`
for Scons, and so forth). If you need to pass anything on the ``make`` 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` :term:`PACKAGECONFIG_CONFARGS`
variables to do so. variables to do so.
You can use the ``devtool configure-help`` command to help you set the You can use the ``devtool configure-help`` command to help you set the
arguments listed in the previous paragraph. The command determines the arguments listed in the previous paragraph. The command determines the
exact options being passed, and shows them to you along with any custom exact options being passed, and shows them to you along with any custom
arguments specified through ``EXTRA_OECONF`` or arguments specified through :term:`EXTRA_OECONF` or
``PACKAGECONFIG_CONFARGS``. If applicable, the command also shows you :term:`PACKAGECONFIG_CONFARGS`. If applicable, the command also shows you
the output of the configure script's "--help" option as a the output of the configure script's "--help" option as a
reference. reference.
@ -1151,16 +1151,16 @@ the ``oe-workdir/packages-split`` directory, which contains a
subdirectory for each package. Apart from some advanced cases, the subdirectory for each package. Apart from some advanced cases, the
:term:`PACKAGES` and :term:`PACKAGES` and
:term:`FILES` variables controls :term:`FILES` variables controls
splitting. The ``PACKAGES`` variable lists all of the packages to be splitting. The :term:`PACKAGES` variable lists all of the packages to be
produced, while the ``FILES`` variable specifies which files to include produced, while the :term:`FILES` variable specifies which files to include
in each package by using an override to specify the package. For in each package by using an override to specify the package. For
example, ``FILES_${PN}`` specifies the files to go into the main package 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 (i.e. the main package has the same name as the recipe and
``${``\ :term:`PN`\ ``}`` evaluates to the ``${``\ :term:`PN`\ ``}`` evaluates to the
recipe name). The order of the ``PACKAGES`` value is significant. For recipe name). The order of the :term:`PACKAGES` value is significant. For
each installed file, the first package whose ``FILES`` value matches the each installed file, the first package whose :term:`FILES` value matches the
file is the package into which the file goes. Both the ``PACKAGES`` and file is the package into which the file goes. Both the :term:`PACKAGES` and
``FILES`` variables have default values. Consequently, you might find :term:`FILES` variables have default values. Consequently, you might find
you do not even need to set these variables in your recipe unless the you do not even need to set these variables in your recipe unless the
software the recipe is building installs files into non-standard software the recipe is building installs files into non-standard
locations. locations.

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

@ -278,9 +278,9 @@ example:
$ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
3. *Create the Makefile:* For this example, the Makefile contains 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 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:: GNU compiler on the build host::
# CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux # 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 4. *Make the Project:* Use the ``make`` command to create the binary
output file. Because variables are commented out in the Makefile, the 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:: file was run::
$ make $ 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 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 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. 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 variable as set from the Makefile by uncommenting the line in the
Makefile and running ``make`` again. Makefile and running ``make`` again.
:: ::
@ -333,7 +333,7 @@ example:
variable as part of the command line. Go into the Makefile and variable as part of the command line. Go into the Makefile and
re-insert the comment character so that running ``make`` uses the re-insert the comment character so that running ``make`` uses the
established SDK compiler. However, when you run ``make``, use a 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 $ make clean
rm -rf *.o 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% :scale: 75%
After clicking the "Add variable" button, the settings for 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 list. With these settings, the OpenEmbedded build system builds the
desired version of the recipe rather than the default version: 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 #. **Based on the layers you've chosen, make needed changes in your
configuration**. configuration**.
For instance, you've chosen a machine type and added in the corresponding BSP 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 configuration file (build/local.conf) to point to that same machine
type. There could be other layer-specific settings you need to change as 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 well. Each layer has a ``README`` document that you can look at for this type of