mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-06-08 15:29:50 +00:00
Code Issues Projects Releases Wiki Activity

sphinx: manual updates for some links

Browse Source 
Some links were not found by the regexp, especially because of they
are spanning across multiple lines. This patch is a manual fixup for
these patterns.

(From yocto-docs rev: 7a5cf8b372903d959d4a1f0882e6198f31f3cba5)

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Nicolas Dechesne
2020-07-27 17:38:09 +02:00
committed by Richard Purdie
parent 4bf6fc5281
commit 424567d629
34 changed files with 327 additions and 348 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/adt-manual/adt-command.rst
+2 -2
View File
@@ -6,8 +6,8 @@ Using the Command Line
Recall that earlier the manual discussed how to use an existing
toolchain tarball that had been installed into the default installation
directory, ``/opt/poky/DISTRO``, which is outside of the `Build
Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ (see the section
directory, ``/opt/poky/DISTRO``, which is outside of the :term:`Build Directory`
(see the section
"`Using a Cross-Toolchain
Tarball) <#using-an-existing-toolchain-tarball>`__". And, that sourcing
your architecture-specific environment setup script initializes a
documentation/adt-manual/adt-intro.rst
+7 -7
View File
@@ -12,8 +12,8 @@ application.
Fundamentally, the ADT consists of the following:
- An architecture-specific cross-toolchain and matching sysroot both
built by the `OpenEmbedded build
system <&YOCTO_DOCS_DEV_URL;#build-system-term>`__. The toolchain and
built by the :term:`OpenEmbedded Build System`.
The toolchain and
sysroot are based on a `Metadata <&YOCTO_DOCS_DEV_URL;#metadata>`__
configuration and extensions, which allows you to cross-develop on
the host machine for the target hardware.
@@ -33,8 +33,8 @@ Toolchain <&YOCTO_DOCS_DEV_URL;#cross-development-toolchain>`__ consists
of a cross-compiler, cross-linker, and cross-debugger that are used to
develop user-space applications for targeted hardware. This toolchain is
created either by running the ADT Installer script, a toolchain
installer script, or through a `Build
Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ that is based on
installer script, or through a :term:`Build Directory`
that is based on
your Metadata configuration or extension for your targeted device. The
cross-toolchain works with a matching target sysroot.
@@ -79,13 +79,13 @@ your application or image. QEMU is made available a number of ways:
- If you use the ADT Installer script to install ADT, you can specify
whether or not to install QEMU.
- If you have cloned the ``poky`` Git repository to create a `Source
Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__ and you have
- If you have cloned the ``poky`` Git repository to create a
:term:`Source Directory` and you have
sourced the environment setup script, QEMU is installed and
automatically available.
- If you have downloaded a Yocto Project release and unpacked it to
create a `Source Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__
create a :term:`Source Directory`
and you have sourced the environment setup script, QEMU is installed
and automatically available.
documentation/adt-manual/adt-package.rst
+1 -1
View File
@@ -59,7 +59,7 @@ add it into a working ``opkg`` repository. Use these commands: $ bitbake
libglade $ bitbake package-index
Next, source the cross-toolchain environment setup script found in the
`Source Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__. Follow
:term:`Source Directory`. Follow
that by setting up the installation destination to point to your sysroot
as sysroot_dir. Finally, have an OPKG configuration file conf_file that
corresponds to the ``opkg`` repository you have just created. The
documentation/adt-manual/adt-prepare.rst
+13 -16
View File
@@ -50,7 +50,7 @@ for more information.
other mentioned benefits had you run the ADT Installer script.
- *Use the toolchain from within the Build Directory:* If you already
have a `Build Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__,
have a :term:`Build Directory`,
you can build the cross-toolchain within the directory. However, like
the previous method mentioned, you only get the cross-toolchain and
QEMU - you do not get any of the other benefits without taking
@@ -79,9 +79,8 @@ the tarball using either of these methods:
` <&YOCTO_ADTINSTALLER_DL_URL;>`__ into any directory.
- *Build the Tarball:* You can use
`BitBake <&YOCTO_DOCS_DEV_URL;#bitbake-term>`__ to generate the
tarball inside an existing `Build
Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__.
:term:`BitBake` to generate the
tarball inside an existing :term:`Build Directory`.
If you use BitBake to generate the ADT Installer tarball, you must
``source`` the environment setup script
@@ -90,8 +89,8 @@ the tarball using either of these methods:
located in the Source Directory before running the ``bitbake``
command that creates the tarball.
The following example commands establish the `Source
Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__, check out the
The following example commands establish the
:term:`Source Directory`, check out the
current release branch, set up the build environment while also
creating the default Build Directory, and run the ``bitbake`` command
that results in the tarball
@@ -268,8 +267,8 @@ Using BitBake and the Build Directory
-------------------------------------
A final way of making the cross-toolchain available is to use BitBake to
generate the toolchain within an existing `Build
Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__. This method does
generate the toolchain within an existing :term:`Build Directory`.
This method does
not install the toolchain into the default ``/opt`` directory. As with
the previous method, if you need to install the target sysroot, you must
do that separately as well.
@@ -280,8 +279,7 @@ Follow these steps to generate the toolchain into the Build Directory:
environment setup script (i.e.
````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or
```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__)
located in the `Source
Directory <&YOCTO_DOCS_DEV_URL;#source-directory>`__.
located in the :term:`Source Directory`.
2. *Check your Local Configuration File:* At this point, you should be
sure that the :term:`MACHINE`
@@ -332,8 +330,8 @@ cross-development environment by sourcing the toolchain's environment
setup script. If you used the ADT Installer or hand-installed
cross-toolchain, then you can find this script in the directory you
chose for installation. For this release, the default installation
directory is ````. If you installed the toolchain in the `Build
Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__, you can find the
directory is ````. If you installed the toolchain in the
:term:`Build Directory`, you can find the
environment setup script for the toolchain in the Build Directory's
``tmp`` directory.
@@ -432,8 +430,8 @@ this by including the ``eclipse-debug`` image feature.
image features.
To include the ``eclipse-debug`` image feature, modify your
``local.conf`` file in the `Build
Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__ so that the
``local.conf`` file in the :term:`Build Directory`
so that the
:term:`EXTRA_IMAGE_FEATURES`
variable includes the "eclipse-debug" feature. After modifying the
configuration file, you can rebuild the image. Once the image is
@@ -484,8 +482,7 @@ Optionally Building a Toolchain Installer
=========================================
As an alternative to locating and downloading a toolchain installer, you
can build the toolchain installer if you have a `Build
Directory <&YOCTO_DOCS_DEV_URL;#build-directory>`__.
can build the toolchain installer if you have a :term:`Build Directory`.
.. note::
documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
+6 -6
View File
@@ -162,10 +162,10 @@ an entire Linux distribution, including the toolchain, from source.
<target>' Common targets are: core-image-minimal core-image-sato
meta-toolchain meta-ide-support You can also run generated qemu
images with a command like 'runqemu qemux86-64' Among other things,
the script creates the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is
``build`` in this case and is located in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. After the
the script creates the
:term:`Build Directory`, which is
``build`` in this case and is located in the :term:`Source Directory`.
After the
script runs, your current working directory is set to the Build
Directory. Later, when the build completes, the Build Directory
contains all the files created during the build.
@@ -271,8 +271,8 @@ Follow these steps to add a hardware layer:
4. *Add Your Layer to the Layer Configuration File:* Before you can use
a layer during a build, you must add it to your ``bblayers.conf``
file, which is found in the `Build
Directory's <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``conf``
file, which is found in the
:term:`Build Directory` ``conf``
directory.
Use the ``bitbake-layers add-layer`` command to add the layer to the
documentation/bsp-guide/bsp.rst
+14 -16
View File
@@ -74,12 +74,12 @@ section in the Yocto Project Development Tasks Manual.
The BSP layer's base directory (``meta-bsp_root_name``) is the root
directory of that Layer. This directory is what you add to the
:term:`BBLAYERS` variable in the
``conf/bblayers.conf`` file found in your `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is
``conf/bblayers.conf`` file found in your
:term:`Build Directory`, which is
established after you run the OpenEmbedded build environment setup
script (i.e. ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__).
Adding the root directory allows the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ to recognize the BSP
Adding the root directory allows the :term:`OpenEmbedded Build System`
to recognize the BSP
layer and from it build an image. Here is an example: BBLAYERS ?= " \\
/usr/local/src/yocto/meta \\ /usr/local/src/yocto/meta-poky \\
/usr/local/src/yocto/meta-yocto-bsp \\ /usr/local/src/yocto/meta-mylayer
@@ -144,8 +144,7 @@ section.
machine that uses CROPS.
2. *Clone the ``poky`` Repository:* You need to have a local copy of the
Yocto Project `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (i.e. a local
Yocto Project :term:`Source Directory` (i.e. a local
``poky`` repository). See the "`Cloning the ``poky``
Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" and
possibly the "`Checking Out by Branch in
@@ -169,8 +168,7 @@ section.
file.
1. *Navigate to Your Source Directory:* Typically, you set up the
``meta-intel`` Git repository inside the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g.
``meta-intel`` Git repository inside the :term:`Source Directory` (e.g.
``poky``). $ cd /home/you/poky
2. *Clone the Layer:* $ git clone
@@ -218,10 +216,10 @@ section.
````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ environment
setup script to define the OpenEmbedded build environment on your
build host. $ source OE_INIT_FILE Among other things, the script
creates the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is
``build`` in this case and is located in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. After the
creates the
:term:`Build Directory`, which is
``build`` in this case and is located in the :term:`Source Directory`.
After the
script runs, your current working directory is set to the ``build``
directory.
@@ -629,8 +627,8 @@ types of files although, in practice, it is likely that you would have
one or the other.
For your BSP, you typically want to use an existing Yocto Project kernel
recipe found in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ at
recipe found in the :term:`Source Directory`
at
``meta/recipes-kernel/linux``. You can append machine-specific changes
to the kernel recipe by using a similarly named append file, which is
located in the BSP Layer for your target device (e.g. the
@@ -848,8 +846,8 @@ Yocto Project:
- *File System Layout:* When possible, use the same directory names in
your BSP layer as listed in the ``recipes.txt`` file, which is found
in ``poky/meta`` directory of the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ or in the
in ``poky/meta`` directory of the :term:`Source Directory`
or in the
OpenEmbedded-Core Layer (``openembedded-core``) at
` <http://git.openembedded.org/openembedded-core/tree/meta>`__.
documentation/dev-manual/dev-manual-common-tasks.rst
+84 -89
View File
@@ -48,8 +48,8 @@ Follow these general steps to create your layer without using tools:
2. *Create a Directory:* Create the directory for your layer. When you
create the layer, be sure to create the directory in an area not
associated with the Yocto Project `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. the cloned
associated with the Yocto Project :term:`Source Directory`
(e.g. the cloned
``poky`` repository).
While not strictly required, prepend the name of the directory with
@@ -263,8 +263,7 @@ following list:
repository that use the ``meta-layer_name`` format.
- *Group Your Layers Locally:* Clone your repository alongside other
cloned ``meta`` directories from the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__.
cloned ``meta`` directories from the :term:`Source Directory`.
Making Sure Your Layer is Compatible With Yocto Project
-------------------------------------------------------
@@ -449,8 +448,8 @@ does not have a corresponding recipe with a matching name. See the
variable for information on how to handle this error.
As an example, consider the main formfactor recipe and a corresponding
formfactor append file both from the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Here is the main
formfactor append file both from the :term:`Source Directory`.
Here is the main
formfactor recipe, which is named ``formfactor_0.0.bb`` and located in
the "meta" layer at ``meta/recipes-bsp/formfactor``: SUMMARY = "Device
formfactor information" SECTION = "base" LICENSE = "MIT"
@@ -769,8 +768,8 @@ high-level image features by using the
variables. Although the functions for both variables are nearly
equivalent, best practices dictate using ``IMAGE_FEATURES`` from within
a recipe and using ``EXTRA_IMAGE_FEATURES`` from within your
``local.conf`` file, which is found in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
``local.conf`` file, which is found in the
:term:`Build Directory`.
To understand how these features work, the best reference is
``meta/classes/core-image.bbclass``. This class lists out the available
@@ -996,8 +995,8 @@ application that builds using Autotools. Creating the base recipe using
``recipetool`` results in a recipe that has the pre-build dependencies,
license requirements, and checksums configured.
To run the tool, you just need to be in your `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ and have sourced the
To run the tool, you just need to be in your
:term:`Build Directory` and have sourced the
build environment setup script (i.e.
```oe-init-build-env`` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__).
To get help on the tool, use the following command: $ recipetool -h
@@ -1799,8 +1798,8 @@ different ways:
To enable a service using systemd, your recipe needs to inherit the
:ref:`systemd <ref-classes-systemd>` class. See
the ``systemd.bbclass`` file located in your `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. section for
the ``systemd.bbclass`` file located in your :term:`Source Directory`
section for
more information.
.. _new-recipe-packaging:
@@ -2251,7 +2250,7 @@ could lead to compatibility problems with ABI in the future. However,
sometimes you have no choice.
The easiest solution is to create a recipe that uses the
```bin_package`` <&YOCTO_DOCS_REF_URL;#ref-classes-bin-package>`__ class
:ref:`bin_package <ref-classes-bin-package>` class
and to be sure that you are using default locations for build artifacts.
In most cases, the ``bin_package`` class handles "skipping" the
configure and compile steps as well as sets things up to grab packages
@@ -2739,7 +2738,7 @@ The following steps describe how to set up the AUH utility:
your build directory.
- If you want to enable testing through the
```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__
:ref:`testimage <ref-classes-testimage*>`
class, which is optional, you need to have the following set in
your ``conf/local.conf`` file: INHERIT += "testimage"
@@ -2856,8 +2855,8 @@ could add it easily using the
script. For example, suppose you use the ``nano.bb`` recipe from the
``meta-oe`` layer in the ``meta-openembedded`` repository. For this
example, assume that the layer has been cloned into following area:
/home/scottrif/meta-openembedded The following command from your `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ adds the layer to
/home/scottrif/meta-openembedded The following command from your
:term:`Build Directory` adds the layer to
your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``): $
bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe NOTE:
Starting bitbake server... Parsing recipes: 100%
@@ -3014,8 +3013,8 @@ You might find it helpful during development to modify the temporary
source code used by recipes to build packages. For example, suppose you
are developing a patch and you need to experiment a bit to figure out
your solution. After you have initially built the package, you can
iteratively tweak the source code, which is located in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, and then you can
iteratively tweak the source code, which is located in the
:term:`Build Directory`, and then you can
force a re-compile and quickly test your altered code. Once you settle
on a solution, you can then preserve your changes in the form of
patches.
@@ -3024,8 +3023,8 @@ During a build, the unpacked temporary source code used by recipes to
build packages is available in the Build Directory as defined by the
:term:`S` variable. Below is the default
value for the ``S`` variable as defined in the
``meta/conf/bitbake.conf`` configuration file in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__: S =
``meta/conf/bitbake.conf`` configuration file in the
:term:`Source Directory`: S =
"${WORKDIR}/${BP}" You should be aware that many recipes override the
``S`` variable. For example, recipes that fetch their source from Git
usually set ``S`` to ``${WORKDIR}/git``.
@@ -3096,8 +3095,8 @@ form of a patch all using Quilt.
Follow these general steps:
1. *Find the Source Code:* Temporary source code used by the
OpenEmbedded build system is kept in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. See the
OpenEmbedded build system is kept in the
:term:`Build Directory`. See the
"`Finding Temporary Source
Code <#finding-the-temporary-source-code>`__" section to learn how to
locate the directory that has the temporary source code for a
@@ -3314,8 +3313,8 @@ build host running Linux.
Build <&YOCTO_DOCS_BRIEF_URL;>`__ document.
The build process creates an entire Linux distribution from source and
places it in your `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ under
places it in your
:term:`Build Directory` under
``tmp/deploy/images``. For detailed information on the build process
using BitBake, see the
"`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" section in the
@@ -3372,8 +3371,8 @@ The following figure and list overviews the build process:
The target is the name of the recipe you want to build. Common
targets are the images in ``meta/recipes-core/images``,
``meta/recipes-sato/images``, and so forth all found in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Or, the target
``meta/recipes-sato/images``, and so forth all found in the
:term:`Source Directory`. Or, the target
can be the name of a recipe for a specific piece of software such as
BusyBox. For more details about the images the OpenEmbedded build
system supports, see the
@@ -3557,8 +3556,8 @@ Follow these steps to create an initramfs image:
1. *Create the initramfs Image Recipe:* You can reference the
``core-image-minimal-initramfs.bb`` recipe found in the
``meta/recipes-core`` directory of the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ as an example
``meta/recipes-core`` directory of the :term:`Source Directory`
as an example
from which to work.
2. *Decide if You Need to Bundle the initramfs Image Into the Kernel
@@ -3715,8 +3714,8 @@ memory used for decompressing the kernel and for the ``__init__``
functions.
To help you see where you currently are with kernel and root filesystem
sizes, you can use two tools found in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ in the
sizes, you can use two tools found in the :term:`Source Directory`
in the
``scripts/tiny/`` directory:
- ``ksize.py``: Reports component sizes for the kernel build objects.
@@ -4049,8 +4048,8 @@ your tunings to best consider build times and package feed maintenance.
Building Software from an External Source
-----------------------------------------
By default, the OpenEmbedded build system uses the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ when building source
By default, the OpenEmbedded build system uses the
:term:`Build Directory` when building source
code. The build process involves fetching the source files, unpacking
them, and then patching them if necessary before the build takes place.
@@ -4158,8 +4157,7 @@ directory:
2. *Start With a Clean Build:* You can start with a clean build by
removing the
``${``\ :term:`TMPDIR`\ ``}``
directory or using a new `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
directory or using a new :term:`Build Directory`.
3. *Build Your Target:* Use BitBake to build your target: $ bitbake
target The build completes using the known local "snapshot" of source
@@ -4258,7 +4256,7 @@ Following are additional factors that can affect build speed:
contents could easily be rebuilt.
- Inheriting the
```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ class:
:ref:`rm_work <ref-classes-rm-work>` class:
Inheriting this class has shown to speed up builds due to
significantly lower amounts of data stored in the data cache as well
as on disk. Inheriting this class also makes cleanup of
@@ -4409,8 +4407,8 @@ meet your needs.
In order to enable Multilib, you first need to ensure your recipe is
extended to support multiple libraries. Many standard recipes are
already extended and support multiple libraries. You can check in the
``meta/conf/multilib.conf`` configuration file in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ to see how this is
``meta/conf/multilib.conf`` configuration file in the
:term:`Source Directory` to see how this is
done using the
:term:`BBCLASSEXTEND` variable.
Eventually, all recipes will be covered and this list will not be
@@ -4436,8 +4434,8 @@ Using Multilib
After you have set up the recipes, you need to define the actual
combination of multiple libraries you want to build. You accomplish this
through your ``local.conf`` configuration file in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. An example
through your ``local.conf`` configuration file in the
:term:`Build Directory`. An example
configuration would be as follows: MACHINE = "qemux86-64" require
conf/multilib.conf MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86" IMAGE_INSTALL_append = "
@@ -4936,8 +4934,8 @@ Raw Mode
Running Wic in raw mode allows you to specify all the partitions through
the ``wic`` command line. The primary use for raw mode is if you have
built your kernel outside of the Yocto Project `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. In other words, you
built your kernel outside of the Yocto Project
:term:`Build Directory`. In other words, you
can point to arbitrary kernel, root filesystem locations, and so forth.
Contrast this behavior with cooked mode where Wic looks in the Build
Directory (e.g. ``tmp/deploy/images/``\ machine).
@@ -5210,8 +5208,8 @@ This next example demonstrates that through modification of the
As mentioned earlier, you can use the command ``wic list images`` to
show the list of existing kickstart files. The directory in which the
``directdisk-gpt.wks`` file resides is
``scripts/lib/image/canned-wks/``, which is located in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``).
``scripts/lib/image/canned-wks/``, which is located in the
:term:`Source Directory` (e.g. ``poky``).
Because available files reside in this directory, you can create and add
your own custom files to the directory. Subsequent use of the
``wic list images`` command would then include your kickstart files.
@@ -5520,8 +5518,8 @@ Security Flags
The Yocto Project has security flags that you can enable that help make
your build output more secure. The security flags are in the
``meta/conf/distro/include/security_flags.inc`` file in your `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``).
``meta/conf/distro/include/security_flags.inc`` file in your
:term:`Source Directory` (e.g. ``poky``).
.. note::
@@ -5561,7 +5559,7 @@ system to make your images more secure:
:ref:`extrausers <ref-classes-extrausers>`
class, which is the preferred method. For an example on how to set up
both root and user passwords, see the
"```extrausers.bbclass`` <&YOCTO_DOCS_REF_URL;#ref-classes-extrausers>`__"
":ref:`extrausers.bbclass <ref-classes-extrausers>`"
section.
.. note::
@@ -5663,8 +5661,8 @@ layer. The following steps provide some more detail:
limited to the list in the previous bulleted item.
- *Point to Your distribution configuration file:* In your
``local.conf`` file in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, set your
``local.conf`` file in the :term:`Build Directory`,
set your
:term:`DISTRO` variable to point to
your distribution's configuration file. For example, if your
distribution's configuration file is named ``mydistro.conf``, then
@@ -5704,8 +5702,8 @@ new build directory.
The OpenEmbedded build system uses the environment variable
``TEMPLATECONF`` to locate the directory from which it gathers
configuration information that ultimately ends up in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``conf`` directory.
configuration information that ultimately ends up in the
:term:`Build Directory` ``conf`` directory.
By default, ``TEMPLATECONF`` is set as follows in the ``poky``
repository: TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf} This is the
directory used by the build system to find templates from which to build
@@ -5762,7 +5760,7 @@ the :term:`Build Directory`: INHERIT
+= "rm_work" Adding this statement deletes the work directory used for
building a recipe once the recipe is built. For more information on
"rm_work", see the
```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ class in the
:ref:`rm_work <ref-classes-rm-work>` class in the
Yocto Project Reference Manual.
Working with Packages
@@ -5947,8 +5945,7 @@ The simplest form for a PR Service is for it to exist for a single host
development system that builds the package feed (building system). For
this scenario, you can enable a local PR Service by setting
:term:`PRSERV_HOST` in your
``local.conf`` file in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: PRSERV_HOST =
``local.conf`` file in the :term:`Build Directory`: PRSERV_HOST =
"localhost:0" Once the service is started, packages will automatically
get increasing ``PR`` values and BitBake takes care of starting and
stopping the server.
@@ -6253,8 +6250,8 @@ to use. In your configuration, you use the
:term:`PACKAGE_CLASSES`
variable to specify the format:
1. Open the ``local.conf`` file inside your `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (e.g.
1. Open the ``local.conf`` file inside your
:term:`Build Directory` (e.g.
``~/poky/build/conf/local.conf``).
2. Select the desired package format as follows: PACKAGE_CLASSES ?=
@@ -6582,8 +6579,8 @@ Adding ptest to Your Build
To add package testing to your build, add the
:term:`DISTRO_FEATURES` and
:term:`EXTRA_IMAGE_FEATURES`
variables to your ``local.conf`` file, which is found in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__:
variables to your ``local.conf`` file, which is found in the
:term:`Build Directory`:
DISTRO_FEATURES_append = " ptest" EXTRA_IMAGE_FEATURES += "ptest-pkgs"
Once your build is complete, the ptest files are installed into the
``/usr/lib/package/ptest`` directory within the image, where ``package``
@@ -7407,8 +7404,8 @@ dependency graphs, so you can see why something was pulled into the
image. If you are just interested in this information and not interested
in collecting specific package or SDK information, you can enable
writing only image information without any history by adding the
following to your ``conf/local.conf`` file found in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT +=
following to your ``conf/local.conf`` file found in the
:term:`Build Directory`: INHERIT +=
"buildhistory" BUILDHISTORY_COMMIT = "0" BUILDHISTORY_FEATURES = "image"
Here, you set the
:term:`BUILDHISTORY_FEATURES`
@@ -7856,19 +7853,19 @@ You can start the tests automatically or manually:
the OpenEmbedded build system successfully creates an image, first
set the
:term:`TESTIMAGE_AUTO`
variable to "1" in your ``local.conf`` file in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: TESTIMAGE_AUTO =
variable to "1" in your ``local.conf`` file in the
:term:`Build Directory`: TESTIMAGE_AUTO =
"1" Next, build your image. If the image successfully builds, the
tests run: bitbake core-image-sato
- *Manually running tests:* To manually run the tests, first globally
inherit the
```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class
:ref:`testimage <ref-classes-testimage*>` class
by editing your ``local.conf`` file: INHERIT += "testimage" Next, use
BitBake to run the tests: bitbake -c testimage image
All test files reside in ``meta/lib/oeqa/runtime`` in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. A test name maps
All test files reside in ``meta/lib/oeqa/runtime`` in the
:term:`Source Directory`. A test name maps
directly to a Python module. Each test module may contain a number of
individual tests. Tests are usually grouped together by the area tested
(e.g tests for systemd reside in ``meta/lib/oeqa/runtime/systemd.py``).
@@ -7934,8 +7931,8 @@ If your image is already built, make sure the following are set in your
"IP-address-for-the-test-target" TEST_SERVER_IP =
"IP-address-for-the-test-server" You can then export the tests with the
following BitBake command form: $ bitbake image -c testexport Exporting
the tests places them in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in
the tests places them in the
:term:`Build Directory` in
``tmp/testexport/``\ image, which is controlled by the
``TEST_EXPORT_DIR`` variable.
@@ -8158,8 +8155,8 @@ section:
- "`Viewing Task Variable
Dependencies <#dev-viewing-task-variable-dependencies>`__" describes
how to use the ``bitbake-dumpsig`` command in conjunction with key
subdirectories in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ to determine
subdirectories in the
:term:`Build Directory` to determine
variable dependencies.
- "`Running Specific Tasks <#dev-debugging-taskrunning>`__" describes
@@ -8313,7 +8310,7 @@ Following are a few of the available ``oe-pkgdata-util`` subcommands.
If you want to inspect the ``${WORKDIR}/packages-split``
directory, make sure that
```rm_work`` <&YOCTO_DOCS_REF_URL;#ref-classes-rm-work>`__ is not
:ref:`rm_work <ref-classes-rm-work>` is not
enabled when you build the recipe.
- ``oe-pkgdata-util find-path ``\ path\ `` ...``: Lists the names of
@@ -8704,8 +8701,7 @@ the names ``bbplain``, ``bbnote``, ``bbdebug``, ``bbwarn``, ``bberror``,
and ``bbfatal``. The
:ref:`logging <ref-classes-logging>` class
implements these functions. See that class in the ``meta/classes``
folder of the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ for information.
folder of the :term:`Source Directory` for information.
Logging With Python
~~~~~~~~~~~~~~~~~~~
@@ -8890,8 +8886,8 @@ to the file: tools/snep-send.$(OBJEXT): include/near/dbus.h
Once you have edited the file, use the ``refresh`` command to create the
patch: $ quilt refresh Refreshed patch patches/parallelmake.patch Once
the patch file exists, you need to add it back to the originating recipe
folder. Here is an example assuming a top-level `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ named ``poky``: $
folder. Here is an example assuming a top-level
:term:`Source Directory` named ``poky``: $
cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
The final thing you need to do to implement the fix in the build is to
update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the
@@ -9163,8 +9159,8 @@ Here are some other tips that you might find useful:
virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
- Removing :term:`TMPDIR` (usually
``tmp/``, within the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__) can often fix
``tmp/``, within the
:term:`Build Directory`) can often fix
temporary build issues. Removing ``TMPDIR`` is usually a relatively
cheap operation, because task output will be cached in
:term:`SSTATE_DIR` (usually
@@ -9471,8 +9467,7 @@ repository:
methods to find out:
- *Maintenance File:* Examine the ``maintainers.inc`` file, which is
located in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ at
located in the :term:`Source Directory` at
``meta/conf/distro/include``, to see who is responsible for code.
- *Search by File:* Using `Git <&YOCTO_DOCS_OM_URL;#git>`__, you can
@@ -9495,8 +9490,8 @@ repository:
The Yocto Project provides two scripts that conveniently let you
generate and send pull requests to the Yocto Project. These scripts
are ``create-pull-request`` and ``send-pull-request``. You can find
these scripts in the ``scripts`` directory within the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g.
these scripts in the ``scripts`` directory within the
:term:`Source Directory` (e.g.
``~/poky/scripts``).
Using these scripts correctly formats the requests without
@@ -9641,8 +9636,8 @@ As mentioned in the "`Licensing <&YOCTO_DOCS_OM_URL;#licensing>`__"
section in the Yocto Project Overview and Concepts Manual, open source
projects are open to the public and they consequently have different
licensing structures in place. This section describes the mechanism by
which the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ tracks changes to
which the :term:`OpenEmbedded Build System`
tracks changes to
licensing text and covers how to maintain open source license compliance
during your project's lifecycle. The section also describes how to
enable commercially licensed recipes, which by default are disabled.
@@ -9947,8 +9942,8 @@ of compliance in mind.
One way of doing this (but certainly not the only way) is to release
just the source as a tarball. You can do this by adding the following to
the ``local.conf`` file found in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__: INHERIT +=
the ``local.conf`` file found in the
:term:`Build Directory`: INHERIT +=
"archiver" ARCHIVER_MODE[src] = "original" During the creation of your
image, the source from all recipes that deploy packages to the image is
placed within subdirectories of ``DEPLOY_DIR/sources`` based on the
@@ -10070,8 +10065,8 @@ The error reporting tool allows you to submit errors encountered during
builds to a central database. Outside of the build environment, you can
use a web interface to browse errors, view statistics, and query for
errors. The tool works using a client-server system where the client
portion is integrated with the installed Yocto Project `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``).
portion is integrated with the installed Yocto Project
:term:`Source Directory` (e.g. ``poky``).
The server receives the information collected and saves it in a
database.
@@ -10093,8 +10088,8 @@ By default, the error reporting tool is disabled. You can enable it by
inheriting the
:ref:`report-error <ref-classes-report-error>`
class by adding the following statement to the end of your
``local.conf`` file in your `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. INHERIT +=
``local.conf`` file in your
:term:`Build Directory`. INHERIT +=
"report-error"
By default, the error reporting feature stores information in
@@ -10155,8 +10150,8 @@ The Yocto Project provides the Wayland protocol libraries and the
reference
`Weston <http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston>`__
compositor as part of its release. You can find the integrated packages
in the ``meta`` layer of the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. Specifically, you
in the ``meta`` layer of the :term:`Source Directory`.
Specifically, you
can find the recipes that build both Wayland and Weston at
``meta/recipes-graphics/wayland``.
documentation/dev-manual/dev-manual-qemu.rst
+4 -4
View File
@@ -100,8 +100,8 @@ available. Follow these general steps to run QEMU:
Here are some additional examples to help illustrate further QEMU:
- This example starts QEMU with MACHINE set to "qemux86-64".
Assuming a standard `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, ``runqemu``
Assuming a standard
:term:`Build Directory`, ``runqemu``
automatically finds the ``bzImage-qemux86-64.bin`` image file and
the ``core-image-minimal-qemux86-64-20200218002850.rootfs.ext4``
(assuming the current build created a ``core-image-minimal``
@@ -232,8 +232,8 @@ be a problem when QEMU is running with KVM enabled. Specifically,
software compiled with a certain CPU feature crashes when run on a CPU
under KVM that does not support that feature. To work around this
problem, you can override QEMU's runtime CPU setting by changing the
``QB_CPU_KVM`` variable in ``qemuboot.conf`` in the `Build
Directory's <&YOCTO_DOCS_REF_URL;#build-directory>`__ ``deploy/image``
``QB_CPU_KVM`` variable in ``qemuboot.conf`` in the
:term:`Build Directory` ``deploy/image``
directory. This setting specifies a ``-cpu`` option passed into QEMU in
the ``runqemu`` script. Running ``qemu -cpu help`` returns a list of
available supported CPU types.
documentation/dev-manual/dev-manual-start.rst
+3 -4
View File
@@ -140,8 +140,7 @@ particular working environment and set of practices.
Following are some best practices for setting up machines used for
developing images:
- Have the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ available on
- Have the :term:`OpenEmbedded Build System` available on
the developer workstations so developers can run their own builds
and directly rebuild the software stack.
@@ -740,8 +739,8 @@ Cloning and Checking Out Branches
To use the Yocto Project for development, you need a release locally
installed on your development system. This locally installed set of
files is referred to as the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ in the Yocto
files is referred to as the :term:`Source Directory`
in the Yocto
Project documentation.
The preferred method of creating your Source Directory is by using
documentation/kernel-dev/kernel-dev-common.rst
+15 -16
View File
@@ -24,8 +24,8 @@ host is set up to use the Yocto Project. For information on how to get
set up, see the "`Preparing the Build
Host <&YOCTO_DOCS_DEV_URL;#dev-preparing-the-build-host>`__" section in
the Yocto Project Development Tasks Manual. Part of preparing the system
is creating a local Git repository of the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (``poky``) on your
is creating a local Git repository of the
:term:`Source Directory` (``poky``) on your
system. Follow the steps in the "`Cloning the ``poky``
Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__"
section in the Yocto Project Development Tasks Manual to set up your
@@ -76,8 +76,8 @@ section:
"qemux86-64", which is fine if you are building for the QEMU emulator
in 64-bit mode. However, if you are not, you need to set the
``MACHINE`` variable appropriately in your ``conf/local.conf`` file
found in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (i.e.
found in the
:term:`Build Directory` (i.e.
``~/poky/build`` in this example).
Also, since you are preparing to work on the kernel image, you need
@@ -240,8 +240,8 @@ section:
"qemux86-64", which is fine if you are building for the QEMU emulator
in 64-bit mode. However, if you are not, you need to set the
``MACHINE`` variable appropriately in your ``conf/local.conf`` file
found in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ (i.e.
found in the
:term:`Build Directory` (i.e.
``~/poky/build`` in this example).
Also, since you are preparing to work on the kernel image, you need
@@ -289,8 +289,8 @@ section:
` <&YOCTO_GIT_URL;>`__.
For simplicity, it is recommended that you create your copy of the
kernel Git repository outside of the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__, which is
kernel Git repository outside of the
:term:`Source Directory`, which is
usually named ``poky``. Also, be sure you are in the
``standard/base`` branch.
@@ -317,8 +317,8 @@ section:
6. *Create a Local Copy of the Kernel Cache Git Repository:* For
simplicity, it is recommended that you create your copy of the kernel
cache Git repository outside of the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__, which is
cache Git repository outside of the
:term:`Source Directory`, which is
usually named ``poky``. Also, for this example, be sure you are in
the ``yocto-4.12`` branch.
@@ -483,8 +483,8 @@ ensure the build process uses the appropriate kernel branch.
Although this particular example does not use it, the
:term:`KERNEL_FEATURES`
variable could be used to enable features specific to the kernel. The
append file points to specific commits in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ Git repository and
append file points to specific commits in the
:term:`Source Directory` Git repository and
the ``meta`` Git repository branches to identify the exact kernel needed
to build the BSP.
@@ -781,8 +781,8 @@ the "`Getting Ready to Develop Using
8. *Build the Image With Your Modified Kernel:* You can now build an
image that includes your kernel patches. Execute the following
command from your `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in the terminal
command from your
:term:`Build Directory` in the terminal
set up to run BitBake: $ cd ~/poky/build $ bitbake core-image-minimal
Using Traditional Kernel Development to Patch the Kernel
@@ -1134,8 +1134,7 @@ build system applies fragments on top of and after applying the existing
defconfig file configurations.
Syntactically, the configuration statement is identical to what would
appear in the ``.config`` file, which is in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
appear in the ``.config`` file, which is in the :term:`Build Directory`.
.. note::
documentation/kernel-dev/kernel-dev-concepts-appx.rst
+2 -2
View File
@@ -320,8 +320,8 @@ tree specific to your kernel from which to generate the new kernel
image.
The following figure shows the temporary file structure created on your
host system when you build the kernel using Bitbake. This `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ contains all the
host system when you build the kernel using Bitbake. This
:term:`Build Directory` contains all the
source files used during the build.
Again, for additional information on the Yocto Project kernel's
documentation/kernel-dev/kernel-dev-maint-appx.rst
+2 -2
View File
@@ -222,7 +222,7 @@ functionality.
This behavior means that all the generated files for a particular
machine or BSP are now in the build tree directory. The files include
the final ``.config`` file, all the ``.o`` files, the ``.a`` files, and
so forth. Since each machine or BSP has its own separate `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ in its own separate
so forth. Since each machine or BSP has its own separate
:term:`Build Directory` in its own separate
branch of the Git repository, you can easily switch between different
builds.
documentation/overview-manual/overview-manual-concepts.rst
+33 -33
View File
@@ -6,8 +6,8 @@ Yocto Project Concepts
This chapter provides explanations for Yocto Project concepts that go
beyond the surface of "how-to" information and reference (or look-up)
material. Concepts such as components, the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ workflow,
material. Concepts such as components, the :term:`OpenEmbedded Build System`
workflow,
cross-development toolchains, shared state cache, and so forth are
explained.
@@ -48,8 +48,8 @@ Concepts <#openembedded-build-system-build-concepts>`__" section.
BitBake
-------
BitBake is the tool at the heart of the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ and is responsible
BitBake is the tool at the heart of the :term:`OpenEmbedded Build System`
and is responsible
for parsing the :term:`Metadata`, generating
a list of tasks from it, and then executing those tasks.
@@ -109,7 +109,7 @@ Class files (``.bbclass``) contain information that is useful to share
between recipes files. An example is the
:ref:`autotools <ref-classes-autotools>` class,
which contains common settings for any application that Autotools uses.
The "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter in the
The ":ref:`ref-manual/ref-classes:Classes`" chapter in the
Yocto Project Reference Manual provides details about classes and how to
use them.
@@ -123,8 +123,8 @@ variables that govern the OpenEmbedded build process. These files fall
into several areas that define machine configuration options,
distribution configuration options, compiler tuning options, general
common configuration options, and user configuration options in
``conf/local.conf``, which is found in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
``conf/local.conf``, which is found in the :term:`Build Directory`.
.. _overview-layers:
@@ -164,8 +164,8 @@ OpenEmbedded Build System Concepts
==================================
This section takes a more detailed look inside the build process used by
the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, which is the build
the :term:`OpenEmbedded Build System`,
which is the build
system specific to the Yocto Project. At the heart of the build system
is BitBake, the task executor.
@@ -221,8 +221,8 @@ figure <#general-workflow-figure>`__:
BitBake needs some basic configuration files in order to complete a
build. These files are ``*.conf`` files. The minimally necessary ones
reside as example files in the ``build/conf`` directory of the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. For simplicity,
reside as example files in the ``build/conf`` directory of the
:term:`Source Directory`. For simplicity,
this section refers to the Source Directory as the "Poky Directory."
When you clone the `Poky <&YOCTO_DOCS_REF_URL;#poky>`__ Git repository
@@ -241,8 +241,8 @@ for creating actual configuration files when you source
````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__, which is the
build environment script.
Sourcing the build environment script creates a `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ if one does not
Sourcing the build environment script creates a
:term:`Build Directory` if one does not
already exist. BitBake uses the Build Directory for all its work during
builds. The Build Directory has a ``conf`` directory that contains
default versions of your ``local.conf`` and ``bblayers.conf``
@@ -357,8 +357,8 @@ Configuration Edits" box in the figure.
When you launch your build with the ``bitbake target`` command, BitBake
sorts out the configurations to ultimately define your build
environment. It is important to understand that the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ reads the
environment. It is important to understand that the
:term:`OpenEmbedded Build System` reads the
configuration files in a specific order: ``site.conf``, ``auto.conf``,
and ``local.conf``. And, the build system applies the normal assignment
statement rules as described in the "`Syntax and
@@ -460,7 +460,7 @@ typically find in the distribution layer:
can be shared among recipes in the distribution. When your recipes
inherit a class, they take on the settings and functions for that
class. You can read more about class files in the
"`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter of the Yocto
":ref:`ref-manual/ref-classes:Classes`" chapter of the Yocto
Reference Manual.
- *conf:* This area holds configuration files for the layer
@@ -643,8 +643,8 @@ Package Feeds
-------------
When the OpenEmbedded build system generates an image or an SDK, it gets
the packages from a package feed area located in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The `general
the packages from a package feed area located in the
:term:`Build Directory`. The `general
workflow figure <#general-workflow-figure>`__ shows this package feeds
area in the upper-right corner.
@@ -687,7 +687,7 @@ package files are kept:
for the i586 or qemux86 architectures.
BitBake uses the
```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__
:ref:`do_package_write_* <ref-tasks-package_write_deb>`
tasks to generate packages and place them into the package holding area
(e.g. ``do_package_write_ipk`` for IPK packages). See the
":ref:`ref-tasks-package_write_deb`",
@@ -733,8 +733,8 @@ code:
The :ref:`ref-tasks-fetch` and
:ref:`ref-tasks-unpack` tasks fetch
the source files and unpack them into the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__.
the source files and unpack them into the
:term:`Build Directory`.
.. note::
@@ -984,7 +984,7 @@ details on how this is accomplished, you can look at
```package.bbclass`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`__.
Depending on the type of packages being created (RPM, DEB, or IPK), the
```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__
:ref:`do_package_write_* <ref-tasks-package_write_deb>`
task creates the actual packages and places them in the Package Feed
area, which is ``${TMPDIR}/deploy``. You can see the "`Package
Feeds <#package-feeds-dev-environment>`__" section for more detail on
@@ -1067,7 +1067,7 @@ processing includes creation of a manifest file and optimizations.
The manifest file (``.manifest``) resides in the same directory as the
root filesystem image. This file lists out, line-by-line, the installed
packages. The manifest file is useful for the
```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class,
:ref:`testimage <ref-classes-testimage*>` class,
for example, to determine whether or not to run specific tests. See the
:term:`IMAGE_MANIFEST`
variable for additional information.
@@ -1102,7 +1102,7 @@ as specified by the ``IMAGE_FSTYPES`` were ``ext4``, the dynamically
generated task would be as follows: do_image_ext4
The final task involved in image creation is the
```do_image_complete`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image-complete>`__
:ref:`do_image_complete <ref-tasks-image-complete>`
task. This task completes the image by applying any image post
processing as defined through the
:term:`IMAGE_POSTPROCESS_COMMAND`
@@ -1242,7 +1242,7 @@ version of the task where instead of building something, BitBake can
skip to the end result and simply place a set of files into specific
locations as needed. In some cases, it makes sense to have a setscene
task variant (e.g. generating package files in the
```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__
:ref:`do_package_write_* <ref-tasks-package_write_deb>`
task). In other cases, it does not make sense (e.g. a
:ref:`ref-tasks-patch` task or a
:ref:`ref-tasks-unpack` task) since
@@ -1317,8 +1317,8 @@ this output:
Images
" chapter in the Yocto Project Reference Manual.
The build process writes images out to the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ inside the
The build process writes images out to the :term:`Build Directory`
inside the
``tmp/deploy/images/machine/`` folder as shown in the figure. This
folder contains any files expected to be loaded on the target device.
The :term:`DEPLOY_DIR` variable
@@ -1775,8 +1775,8 @@ need to fix this situation.
Thus far, this section has limited discussion to the direct inputs into
a task. Information based on direct inputs is referred to as the
"basehash" in the code. However, the question of a task's indirect
inputs still exits - items already built and present in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The checksum (or
inputs still exits - items already built and present in the
:term:`Build Directory`. The checksum (or
signature) for a particular task needs to add the hashes of all the
tasks on which the particular task depends. Choosing which dependencies
to add is a policy decision. However, the effect is to generate a master
@@ -2117,9 +2117,9 @@ Fakeroot and Pseudo
Some tasks are easier to implement when allowed to perform certain
operations that are normally reserved for the root user (e.g.
:ref:`ref-tasks-install`,
```do_package_write*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__,
:ref:`do_package_write* <ref-tasks-package_write_deb>`,
:ref:`ref-tasks-rootfs`, and
```do_image*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image>`__). For example,
:ref:`do_image* <ref-tasks-image>`). For example,
the ``do_install`` task benefits from being able to set the UID and GID
of installed files to arbitrary values.
@@ -2139,8 +2139,8 @@ The capability to run tasks in a fake root environment is known as
the BitBake keyword/variable flag that requests a fake root environment
for a task.
In the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, the program that
In the :term:`OpenEmbedded Build System`,
the program that
implements fakeroot is known as
`Pseudo <https://www.yoctoproject.org/software-item/pseudo/>`__. Pseudo
overrides system calls by using the environment variable ``LD_PRELOAD``,
documentation/overview-manual/overview-manual-development-environment.rst
+8 -8
View File
@@ -86,8 +86,8 @@ Once your development host is set up to use the Yocto Project, several
methods exist for you to do work in the Yocto Project environment:
- *Command Lines, BitBake, and Shells:* Traditional development in the
Yocto Project involves using the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, which uses
Yocto Project involves using the :term:`OpenEmbedded Build System`,
which uses
BitBake, in a command-line environment from a shell on your
development host. You can accomplish this from a host that is a
native Linux machine or from a host that has been set up with CROPS.
@@ -162,8 +162,8 @@ these tarballs gives you a snapshot of the released files.
.. note::
- The recommended method for setting up the Yocto Project `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and the files
- The recommended method for setting up the Yocto Project
:term:`Source Directory` and the files
for supported BSPs (e.g., ``meta-intel``) is to use `Git <#git>`__
to create a local copy of the upstream repositories.
@@ -350,8 +350,8 @@ Book <http://book.git-scm.com>`__.
software on which to develop. The Yocto Project has two scripts named
``create-pull-request`` and ``send-pull-request`` that ship with the
release to facilitate this workflow. You can find these scripts in
the ``scripts`` folder of the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. For information
the ``scripts`` folder of the
:term:`Source Directory`. For information
on how to use these scripts, see the "`Using Scripts to Push a Change
Upstream and Request a
Pull <&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream>`__" section in
@@ -638,8 +638,8 @@ When you build an image using the Yocto Project, the build process uses
a known list of licenses to ensure compliance. You can find this list in
the :term:`Source Directory` at
``meta/files/common-licenses``. Once the build completes, the list of
all licenses found and used during that build are kept in the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ at
all licenses found and used during that build are kept in the
:term:`Build Directory` at
``tmp/deploy/licenses``.
If a module requires a license that is not in the base list, the build
documentation/overview-manual/overview-manual-yp-intro.rst
+13 -14
View File
@@ -180,8 +180,8 @@ developing using the Yocto Project:
changes on the development system within the BitBake environment and
then deploying only the updated packages to the target.
The Yocto Project `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ produces packages
The Yocto Project :term:`OpenEmbedded Build System`
produces packages
in standard formats (i.e. RPM, DEB, IPK, and TAR). You can deploy
these packages into the running system on the target by using
utilities on the target such as ``rpm`` or ``ipk``.
@@ -202,8 +202,8 @@ The Yocto Project's "Layer Model" is a development model for embedded
and IoT Linux creation that distinguishes the Yocto Project from other
simple build systems. The Layer Model simultaneously supports
collaboration and customization. Layers are repositories that contain
related sets of instructions that tell the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to do. You can
related sets of instructions that tell the :term:`OpenEmbedded Build System`
what to do. You can
collaborate, share, and reuse layers.
Layers can contain changes to previous instructions or settings at any
@@ -292,8 +292,8 @@ The Yocto Project employs a collection of components and tools used by
the project itself, by project developers, and by those using the Yocto
Project. These components and tools are open source projects and
metadata that are separate from the reference distribution
(`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. Most of the
(`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the
:term:`OpenEmbedded Build System`. Most of the
components and tools are downloaded separately.
This section provides brief overviews of the components and tools
@@ -367,8 +367,8 @@ The following list consists of tools that help production related
activities using the Yocto Project:
- *Auto Upgrade Helper:* This utility when used in conjunction with the
`OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ (BitBake and
:term:`OpenEmbedded Build System`
(BitBake and
OE-Core) automatically generates upgrades for recipes that are based
on new versions of the recipes published upstream.
@@ -668,8 +668,8 @@ Project.
- *Toaster:* Regardless of what your Build Host is running, you can use
Toaster to develop software using the Yocto Project. Toaster is a web
interface to the Yocto Project's `Open-Embedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface
interface to the Yocto Project's :term:`OpenEmbedded Build System`.
The interface
enables you to configure and run your builds. Information about
builds is collected and stored in a database. You can use Toaster to
configure and start builds on multiple remote build servers.
@@ -789,8 +789,7 @@ section in the BitBake User's Manual.
The OpenEmbedded Build System Workflow
======================================
The `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ uses a "workflow" to
The :term:`OpenEmbedded Build System` uses a "workflow" to
accomplish image and SDK generation. The following figure overviews that
workflow:
@@ -836,8 +835,8 @@ helpful for getting started:
- *Configuration Files:* Files that hold global definitions of
variables, user-defined variables, and hardware configuration
information. These files tell the `Open-Embedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to build and
information. These files tell the :term:`OpenEmbedded Build System`
what to build and
what to put into the image to support a particular platform.
- *Extensible Software Development Kit (eSDK):* A custom SDK for
documentation/ref-manual/faq.rst
+5 -6
View File
@@ -256,8 +256,7 @@ situation changes, the team will not support spaces in pathnames.
**A:** The toolchain configuration is very flexible and customizable. It
is primarily controlled with the ``TCMODE`` variable. This variable
controls which ``tcmode-*.inc`` file to include from the
``meta/conf/distro/include`` directory within the `Source
Directory <#source-directory>`__.
``meta/conf/distro/include`` directory within the :term:`Source Directory`.
The default value of ``TCMODE`` is "default", which tells the
OpenEmbedded build system to use its internally built toolchain (i.e.
@@ -342,8 +341,8 @@ redirect requests through proxy servers.
**A:** Yes - you can easily do this. When you use BitBake to build an
image, all the build output goes into the directory created when you run
the build environment setup script (i.e.
````` <#structure-core-script>`__). By default, this `Build
Directory <#build-directory>`__ is named ``build`` but can be named
````` <#structure-core-script>`__). By default, this :term:`Build Directory`
is named ``build`` but can be named
anything you want.
Within the Build Directory, is the ``tmp`` directory. To remove all the
@@ -379,8 +378,8 @@ system of that image. Thus, the build system provides a value of
"/usr/bin" for ``bindir``, a value of "/usr/lib" for ``libdir``, and so
forth.
Meanwhile, ``DESTDIR`` is a path within the `Build
Directory <#build-directory>`__. However, when the recipe builds a
Meanwhile, ``DESTDIR`` is a path within the :term:`Build Directory`.
However, when the recipe builds a
native program (i.e. one that is intended to run on the build machine),
that program is never installed directly to the build machine's root
file system. Consequently, the build system uses paths within the Build
documentation/ref-manual/migration.rst
+6 -6
View File
@@ -731,7 +731,7 @@ Automated Image Testing
-----------------------
A new automated image testing framework has been added through the
```testimage.bbclass`` <#ref-classes-testimage*>`__ class. This
:ref:`testimage.bbclass <ref-classes-testimage*>` class. This
framework replaces the older ``imagetest-qemu`` framework.
You can learn more about performing automated image tests in the
@@ -1077,7 +1077,7 @@ future releases the :ref:`autotools <ref-classes-autotools>` class
will enable a separate build directory by default as well. Recipes
building Autotools-based software that fails to build with a separate
build directory should be changed to inherit from the
```autotools-brokensep`` <#ref-classes-autotools>`__ class instead of
:ref:`autotools-brokensep <ref-classes-autotools>` class instead of
the ``autotools`` or ``autotools_stage``\ classes.
.. _migration-1.6-building-qemu-native:
@@ -1305,7 +1305,7 @@ occurred:
However, if the software is not capable of being built in this
manner, you will need to either patch the software so that it can
build separately, or you will need to change the recipe to inherit
the ```autotools-brokensep`` <#ref-classes-autotools>`__ class
the :ref:`autotools-brokensep <ref-classes-autotools>` class
instead of the ``autotools`` or ``autotools_stage`` classes.
- *The ``--foreign`` option is no longer passed to ``automake`` when
@@ -2048,7 +2048,7 @@ time.
A minor part of this restructuring is that the post-processing
definitions and functions have been moved from the
:ref:`image <ref-classes-image>` class to the
```rootfs-postcommands`` <#ref-classes-rootfs*>`__ class. Functionally,
:ref:`rootfs-postcommands <ref-classes-rootfs*>` class. Functionally,
however, they remain unchanged.
.. _migration-2.1-removed-recipes:
@@ -3973,7 +3973,7 @@ For names of recipes removed because of this repository change, see the
Previously, it was possible for Python recipes that inherited the
:ref:`distutils <ref-classes-distutils>` and
```distutils3`` <#ref-classes-distutils3>`__ classes to fetch code
:ref:`distutils3 <ref-classes-distutils3>` classes to fetch code
during the :ref:`ref-tasks-configure` task to satisfy
dependencies mentioned in ``setup.py`` if those dependencies were not
provided in the sysroot (i.e. recipes providing the dependencies were
@@ -4183,7 +4183,7 @@ This section provides information about automatic testing changes:
practices now dictate that you use the
:term:`IMAGE_CLASSES` variable rather than the
:term:`INHERIT` variable when you inherit the
```testimage`` <#ref-classes-testimage*>`__ and
:ref:`testimage <ref-classes-testimage*>` and
:ref:`testsdk <ref-classes-testsdk>` classes used for automatic
testing.
documentation/ref-manual/ref-classes.rst
+10 -10
View File
@@ -14,8 +14,8 @@ some default behavior.
Any :term:`Metadata` usually found in a recipe can also be
placed in a class file. Class files are identified by the extension
``.bbclass`` and are usually placed in a ``classes/`` directory beneath
the ``meta*/`` directory found in the `Source
Directory <#source-directory>`__. Class files can also be pointed to by
the ``meta*/`` directory found in the :term:`Source Directory`.
Class files can also be pointed to by
:term:`BUILDDIR` (e.g. ``build/``) in the same way as
``.conf`` files in the ``conf`` directory. Class files are searched for
in :term:`BBPATH` using the same method by which ``.conf``
@@ -555,7 +555,7 @@ used.
``distutils`` class in their recipes.
- Extensions that use build systems based on ``setuptools3`` require
the ```setuptools3`` <#ref-classes-setuptools>`__ class in their
the :ref:`setuptools3 <ref-classes-setuptools>` class in their
recipes.
The ``distutils3*`` classes either inherit their corresponding
@@ -592,8 +592,8 @@ ${WORKDIR}/${BPN}/{PV}/ See these variables for more information:
:term:`PV`,
For more information on the ``externalsrc`` class, see the comments in
``meta/classes/externalsrc.bbclass`` in the `Source
Directory <#source-directory>`__. For information on how to use the
``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`.
For information on how to use the
``externalsrc`` class, see the "`Building Software from an External
Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__"
section in the Yocto Project Development Tasks Manual.
@@ -1733,8 +1733,8 @@ package-specific classes:
You can control the list of resulting package formats by using the
``PACKAGE_CLASSES`` variable defined in your ``conf/local.conf``
configuration file, which is located in the `Build
Directory <#build-directory>`__. When defining the variable, you can
configuration file, which is located in the :term:`Build Directory`.
When defining the variable, you can
specify one or more package types. Since images are generated from
packages, a packaging class is needed to enable image generation. The
first class listed in this variable is used for image generation.
@@ -2181,8 +2181,8 @@ recipe are no longer needed. However, by default, the build system
preserves these files for inspection and possible debugging purposes. If
you would rather have these files deleted to save disk space as the
build progresses, you can enable ``rm_work`` by adding the following to
your ``local.conf`` file, which is found in the `Build
Directory <#build-directory>`__. INHERIT += "rm_work" If you are
your ``local.conf`` file, which is found in the :term:`Build Directory`.
INHERIT += "rm_work" If you are
modifying and building source code out of the work directory for a
recipe, enabling ``rm_work`` will potentially result in your changes to
the source being lost. To exclude some recipes from having their work
@@ -2565,7 +2565,7 @@ Other classes use the ``terminal`` class anywhere a separate terminal
session needs to be started. For example, the
:ref:`patch <ref-classes-patch>` class assuming
:term:`PATCHRESOLVE` is set to "user", the
```cml1`` <#ref-classes-cml1>`__ class, and the
:ref:`cml1 <ref-classes-cml1>` class, and the
:ref:`devshell <ref-classes-devshell>` class all use the ``terminal``
class.
documentation/ref-manual/ref-images.rst
+2 -2
View File
@@ -27,8 +27,8 @@ image you want.
From within the ``poky`` Git repository, you can use the following
command to display the list of directories within the `Source
Directory <#source-directory>`__ that contain image recipe files: $ ls
command to display the list of directories within the :term:`Source Directory`
that contain image recipe files: $ ls
meta*/recipes*/images/*.bb
Following is a list of supported recipes:
documentation/ref-manual/ref-release-process.rst
+1 -1
View File
@@ -117,7 +117,7 @@ consists of the following pieces:
an ARM target, did the build produce ARM binaries. If, for example,
the build produced PPC binaries then there is a problem.
- ```testimage.bbclass`` <#ref-classes-testimage*>`__: This class
- :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
performs runtime testing of images after they are built. The tests
are usually used with `QEMU <&YOCTO_DOCS_DEV_URL;#dev-manual-qemu>`__
to boot the images and check the combined runtime result boot
documentation/ref-manual/ref-structure.rst
+7 -8
View File
@@ -26,8 +26,7 @@ section in the Yocto Project Development Tasks Manual.
Top-Level Core Components
=========================
This section describes the top-level components of the `Source
Directory <#source-directory>`__.
This section describes the top-level components of the :term:`Source Directory`.
.. _structure-core-bitbake:
@@ -57,8 +56,8 @@ Manual <&YOCTO_DOCS_BB_URL;>`__.
This directory contains user configuration files and the output
generated by the OpenEmbedded build system in its standard configuration
where the source tree is combined with the output. The `Build
Directory <#build-directory>`__ is created initially when you ``source``
where the source tree is combined with the output. The :term:`Build Directory`
is created initially when you ``source``
the OpenEmbedded build environment setup script (i.e.
````` <#structure-core-script>`__).
@@ -175,8 +174,8 @@ creates the ``build/`` directory in your current working directory. If
you provide a Build Directory argument when you ``source`` the script,
you direct the OpenEmbedded build system to create a Build Directory of
your choice. For example, the following command creates a Build
Directory named ``mybuilds/`` that is outside of the `Source
Directory <#source-directory>`__: $ source OE_INIT_FILE ~/mybuilds The
Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`:
$ source OE_INIT_FILE ~/mybuilds The
OpenEmbedded build system uses the template configuration files, which
are found by default in the ``meta-poky/conf/`` directory in the Source
Directory. See the "`Creating a Custom Template Configuration
@@ -206,8 +205,8 @@ These files are standard top-level files.
The Build Directory - ``build/``
================================
The OpenEmbedded build system creates the `Build
Directory <#build-directory>`__ when you run the build environment setup
The OpenEmbedded build system creates the :term:`Build Directory`
when you run the build environment setup
script ````` <#structure-core-script>`__. If you do not give the Build
Directory a specific name when you run the setup script, the name
defaults to ``build/``.
documentation/ref-manual/ref-system-requirements.rst
+2 -2
View File
@@ -348,8 +348,8 @@ installer:
system.
Once the build completes, you can find the ``.sh`` file that installs
the tools in the ``tmp/deploy/sdk`` subdirectory of the `Build
Directory <#build-directory>`__. The installer file has the string
the tools in the ``tmp/deploy/sdk`` subdirectory of the
:term:`Build Directory`. The installer file has the string
"buildtools" (or "buildtools-extended") in the name.
3. Transfer the ``.sh`` file from the build host to the machine that
documentation/ref-manual/ref-tasks.rst
+1 -1
View File
@@ -409,7 +409,7 @@ dependencies specified by :term:`DEPENDS`). See the
Removes work files after the OpenEmbedded build system has finished with
them. You can learn more by looking at the
"```rm_work.bbclass`` <#ref-classes-rm-work>`__" section.
":ref:`rm_work.bbclass <ref-classes-rm-work>`" section.
.. _ref-tasks-unpack:
documentation/ref-manual/ref-terms.rst
+2 -2
View File
@@ -378,8 +378,8 @@ universal, the list includes them just in case:
:ref:`ref-tasks-patch`, and so forth).
Toaster
A web interface to the Yocto Project's `OpenEmbedded Build
System <#build-system-term>`__. The interface enables you to
A web interface to the Yocto Project's :term:`OpenEmbedded Build System`.
The interface enables you to
configure and run your builds. Information about builds is collected
and stored in a database. For information on Toaster, see the
`Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__.
documentation/ref-manual/ref-variables.rst
+57 -60
View File
@@ -144,8 +144,7 @@ system and gives an overview of their function and contents.
= "1" # Uses environment data. ARCHIVER_MODE[recipe] = "1" # Uses
recipe and include files. ARCHIVER_MODE[srpm] = "1" # Uses RPM
package files. For information on how the variable works, see the
``meta/classes/archiver.bbclass`` file in the `Source
Directory <#source-directory>`__.
``meta/classes/archiver.bbclass`` file in the :term:`Source Directory`.
AS
Minimal command and arguments needed to run the assembler.
@@ -583,8 +582,8 @@ system and gives an overview of their function and contents.
BBLAYERS
Lists the layers to enable during the build. This variable is defined
in the ``bblayers.conf`` configuration file in the `Build
Directory <#build-directory>`__. Here is an example: BBLAYERS = " \\
in the ``bblayers.conf`` configuration file in the :term:`Build Directory`.
Here is an example: BBLAYERS = " \\
/home/scottrif/poky/meta \\ /home/scottrif/poky/meta-poky \\
/home/scottrif/poky/meta-yocto-bsp \\
/home/scottrif/poky/meta-mykernel \\ "
@@ -705,8 +704,8 @@ system and gives an overview of their function and contents.
.
For more information on how this variable works, see
``meta/classes/binconfig.bbclass`` in the `Source
Directory <#source-directory>`__. You can also find general
``meta/classes/binconfig.bbclass`` in the :term:`Source Directory`.
You can also find general
information on the class in the
":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
@@ -1042,8 +1041,8 @@ system and gives an overview of their function and contents.
Bluetooth but you do not ever intend to use it.
COMMON_LICENSE_DIR
Points to ``meta/files/common-licenses`` in the `Source
Directory <#source-directory>`__, which is where generic license
Points to ``meta/files/common-licenses`` in the
:term:`Source Directory`, which is where generic license
files reside.
COMPATIBLE_HOST
@@ -1391,8 +1390,8 @@ system and gives an overview of their function and contents.
for an SDK (i.e. ``nativesdk-``)
D
The destination directory. The location in the `Build
Directory <#build-directory>`__ where components are installed by the
The destination directory. The location in the :term:`Build Directory`
where components are installed by the
:ref:`ref-tasks-install` task. This location defaults
to: ${WORKDIR}/image
@@ -1664,8 +1663,8 @@ system and gives an overview of their function and contents.
file whose root name is the same as the variable's argument and whose
filename extension is ``.conf``. For example, the distribution
configuration file for the Poky distribution is named ``poky.conf``
and resides in the ``meta-poky/conf/distro`` directory of the `Source
Directory <#source-directory>`__.
and resides in the ``meta-poky/conf/distro`` directory of the
:term:`Source Directory`.
Within that ``poky.conf`` file, the ``DISTRO`` variable is set as
follows: DISTRO = "poky"
@@ -2296,8 +2295,8 @@ system and gives an overview of their function and contents.
:term:`SRC_URI` statements.
The default value for the ``FILESPATH`` variable is defined in the
``base.bbclass`` class found in ``meta/classes`` in the `Source
Directory <#source-directory>`__: FILESPATH =
``base.bbclass`` class found in ``meta/classes`` in the
:term:`Source Directory`: FILESPATH =
"${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \\
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" The
``FILESPATH`` variable is automatically extended using the overrides
@@ -2344,14 +2343,14 @@ system and gives an overview of their function and contents.
packages themselves but this is not always possible.
By default, the OpenEmbedded build system uses the ``fs-perms.txt``,
which is located in the ``meta/files`` folder in the `Source
Directory <#source-directory>`__. If you create your own file
which is located in the ``meta/files`` folder in the :term:`Source Directory`.
If you create your own file
permissions setting table, you should place it in your layer or the
distro's layer.
You define the ``FILESYSTEM_PERMS_TABLES`` variable in the
``conf/local.conf`` file, which is found in the `Build
Directory <#build-directory>`__, to point to your custom
``conf/local.conf`` file, which is found in the :term:`Build Directory`,
to point to your custom
``fs-perms.txt``. You can specify more than a single file permissions
setting table. The paths you specify to these files must be defined
within the :term:`BBPATH` variable.
@@ -2717,8 +2716,8 @@ system and gives an overview of their function and contents.
IMAGE_FEATURES
The primary list of features to include in an image. Typically, you
configure this variable in an image recipe. Although you can use this
variable from your ``local.conf`` file, which is found in the `Build
Directory <#build-directory>`__, best practices dictate that you do
variable from your ``local.conf`` file, which is found in the
:term:`Build Directory`, best practices dictate that you do
not.
.. note::
@@ -2886,13 +2885,13 @@ system and gives an overview of their function and contents.
class is broken and is not supported. It is recommended that you
do not use it.
The ```populate_sdk_*`` <#ref-classes-populate-sdk-*>`__ and
The :ref:`populate_sdk_* <ref-classes-populate-sdk-*>` and
:ref:`image <ref-classes-image>` classes use the ``IMAGE_PKGTYPE``
for packaging up images and SDKs.
You should not set the ``IMAGE_PKGTYPE`` manually. Rather, the
variable is set indirectly through the appropriate
```package_*`` <#ref-classes-package>`__ class using the
:ref:`package_* <ref-classes-package>` class using the
:term:`PACKAGE_CLASSES` variable. The
OpenEmbedded build system uses the first package type (e.g. DEB, RPM,
or IPK) that appears with the variable
@@ -2995,8 +2994,7 @@ system and gives an overview of their function and contents.
wic.bz2 wic.gz wic.lzma
For more information about these types of images, see
``meta/classes/image_types*.bbclass`` in the `Source
Directory <#source-directory>`__.
``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`.
INC_PR
Helps define the recipe revision for recipes that share a common
@@ -3156,8 +3154,8 @@ system and gives an overview of their function and contents.
:term:`IMAGE_FSTYPES` variable.
The default value of this variable, which is set in the
``meta/conf/bitbake.conf`` configuration file in the `Source
Directory <#source-directory>`__, is "cpio.gz". The Linux kernel's
``meta/conf/bitbake.conf`` configuration file in the
:term:`Source Directory`, is "cpio.gz". The Linux kernel's
initramfs mechanism, as opposed to the initial RAM filesystem
`initrd <https://en.wikipedia.org/wiki/Initrd>`__ mechanism, expects
an optionally compressed cpio archive.
@@ -3945,8 +3943,8 @@ system and gives an overview of their function and contents.
MACHINE
Specifies the target device for which the image is built. You define
``MACHINE`` in the ``local.conf`` file found in the `Build
Directory <#build-directory>`__. By default, ``MACHINE`` is set to
``MACHINE`` in the ``local.conf`` file found in the
:term:`Build Directory`. By default, ``MACHINE`` is set to
"qemux86", which is an x86-based architecture machine to be emulated
using QEMU: MACHINE ?= "qemux86"
@@ -4353,8 +4351,8 @@ system and gives an overview of their function and contents.
``sysroots/`` directory so that all builds that use the script will
use the correct directories for the cross compiling layout.
See the ``meta/classes/binconfig.bbclass`` in the `Source
Directory <#source-directory>`__ for details on how this class
See the ``meta/classes/binconfig.bbclass`` in the
:term:`Source Directory` for details on how this class
applies these additional sed command arguments. For general
information on the ``binconfig`` class, see the
":ref:`binconfig.bbclass <ref-classes-binconfig>`" section.
@@ -4499,8 +4497,8 @@ system and gives an overview of their function and contents.
PACKAGE_CLASSES
This variable, which is set in the ``local.conf`` configuration file
found in the ``conf`` folder of the `Build
Directory <#build-directory>`__, specifies the package manager the
found in the ``conf`` folder of the
:term:`Build Directory`, specifies the package manager the
OpenEmbedded build system uses when packaging data.
You can provide one or more of the following arguments for the
@@ -5234,8 +5232,8 @@ system and gives an overview of their function and contents.
Typically, you could add a specific server for the build system to
attempt before any others by adding something like the following to
the ``local.conf`` configuration file in the `Build
Directory <#build-directory>`__: PREMIRRORS_prepend = "\\
the ``local.conf`` configuration file in the
:term:`Build Directory`: PREMIRRORS_prepend = "\\
git://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ ftp://.*/.\*
http://www.yoctoproject.org/sources/ \\n \\ http://.*/.\*
http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\*
@@ -5364,8 +5362,8 @@ system and gives an overview of their function and contents.
PYTHON_ABI
When used by recipes that inherit the
```distutils3`` <#ref-classes-distutils3>`__,
```setuptools3`` <#ref-classes-setuptools3>`__,
:ref:`distutils3 <ref-classes-distutils3>`,
:ref:`setuptools3 <ref-classes-setuptools3>`,
:ref:`distutils <ref-classes-distutils>`, or
:ref:`setuptools <ref-classes-setuptools>` classes, denotes the
Application Binary Interface (ABI) currently in use for Python. By
@@ -5382,8 +5380,8 @@ system and gives an overview of their function and contents.
PYTHON_PN
When used by recipes that inherit the
```distutils3`` <#ref-classes-distutils3>`__,
```setuptools3`` <#ref-classes-setuptools3>`__,
`distutils3 <ref-classes-distutils3>`,
:ref:`setuptools3 <ref-classes-setuptools3>`,
:ref:`distutils <ref-classes-distutils>`, or
:ref:`setuptools <ref-classes-setuptools>` classes, specifies the
major Python version being built. For Python 3.x, ``PYTHON_PN`` would
@@ -5522,7 +5520,7 @@ system and gives an overview of their function and contents.
RM_WORK_EXCLUDE
With ``rm_work`` enabled, this variable specifies a list of recipes
whose work directories should not be removed. See the
"```rm_work.bbclass`` <#ref-classes-rm-work>`__" section for more
":ref:`rm_work.bbclass <ref-classes-rm-work>`" section for more
details.
ROOT_HOME
@@ -5731,14 +5729,14 @@ system and gives an overview of their function and contents.
SDK_DEPLOY
The directory set up and used by the
```populate_sdk_base`` <#ref-classes-populate-sdk>`__ class to which
:ref:`populate_sdk_base <ref-classes-populate-sdk>` class to which
the SDK is deployed. The ``populate_sdk_base`` class defines
``SDK_DEPLOY`` as follows: SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
SDK_DIR
The parent directory used by the OpenEmbedded build system when
creating SDK output. The
```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class defines
:ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class defines
the variable as follows: SDK_DIR = "${WORKDIR}/sdk"
.. note::
@@ -5770,7 +5768,7 @@ system and gives an overview of their function and contents.
file contains package information on a line-per-package basis as
follows: packagename packagearch version
The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class
The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class
defines the manifest file as follows: SDK_HOST_MANIFEST =
"${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" The location is
derived using the :term:`SDK_DEPLOY` and
@@ -5807,7 +5805,7 @@ system and gives an overview of their function and contents.
SDK_INHERIT_BLACKLIST
A list of classes to remove from the :term:`INHERIT`
value globally within the extensible SDK configuration. The
```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class sets the
:ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class sets the
default value: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
Some classes are not generally applicable within the extensible SDK
@@ -5827,7 +5825,7 @@ system and gives an overview of their function and contents.
within the extensible SDK.
By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the
```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class and
:ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class and
excludes the following variables:
:term:`CONF_VERSION`
:term:`BB_NUMBER_THREADS`
@@ -5848,7 +5846,7 @@ system and gives an overview of their function and contents.
A list of variables allowed through from the OpenEmbedded build
system configuration into the extensible SDK configuration. By
default, the list of variables is empty and is set in the
```populate-sdk-ext`` <#ref-classes-populate-sdk-*>`__ class.
:ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class.
This list overrides the variables specified using the
:term:`SDK_LOCAL_CONF_BLACKLIST`
@@ -5877,7 +5875,7 @@ system and gives an overview of their function and contents.
SDK_OUTPUT
The location used by the OpenEmbedded build system when creating SDK
output. The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__
output. The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
class defines the variable as follows: SDK_DIR = "${WORKDIR}/sdk"
SDK_OUTPUT = "${SDK_DIR}/image" SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
@@ -5942,7 +5940,7 @@ system and gives an overview of their function and contents.
file contains package information on a line-per-package basis as
follows: packagename packagearch version
The ```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class
The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class
defines the manifest file as follows: SDK_TARGET_MANIFEST =
"${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" The location
is derived using the :term:`SDK_DEPLOY` and
@@ -5960,7 +5958,7 @@ system and gives an overview of their function and contents.
The title to be printed when running the SDK installer. By default,
this title is based on the :term:`DISTRO_NAME` or
:term:`DISTRO` variable and is set in the
```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as
:ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as
follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or
d.getVar('DISTRO')} SDK" For the default distribution "poky",
``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)".
@@ -5993,7 +5991,7 @@ system and gives an overview of their function and contents.
The default installation directory for the Extensible SDK. By
default, this directory is based on the :term:`DISTRO`
variable and is set in the
```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class as
:ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as
follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" For the
default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk".
@@ -6135,8 +6133,8 @@ system and gives an overview of their function and contents.
prebuilt binaries and libraries such as ``libstdc++`` and ``glibc``.
To enable file removal, set the variable to "1" in your
``conf/local.conf`` configuration file in your: `Build
Directory <#build-directory>`__. SKIP_FILEDEPS = "1"
``conf/local.conf`` configuration file in your:
:term:`Build Directory`. SKIP_FILEDEPS = "1"
SOC_FAMILY
Groups together machines based upon the same family of SOC (System On
@@ -7289,8 +7287,8 @@ system and gives an overview of their function and contents.
If you want to establish this directory in a location other than the
default, you can uncomment and edit the following statement in the
``conf/local.conf`` file in the `Source
Directory <#source-directory>`__: #TMPDIR = "${TOPDIR}/tmp" An
``conf/local.conf`` file in the :term:`Source Directory`:
#TMPDIR = "${TOPDIR}/tmp" An
example use for this scenario is to set ``TMPDIR`` to a local disk,
which does not use NFS, while having the Build Directory use NFS.
@@ -7325,7 +7323,7 @@ system and gives an overview of their function and contents.
TOOLCHAIN_OUTPUTNAME
This variable defines the name used for the toolchain output. The
```populate_sdk_base`` <#ref-classes-populate-sdk-*>`__ class sets
:ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class sets
the ``TOOLCHAIN_OUTPUTNAME`` variable as follows:
TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" See
the :term:`SDK_NAME` and
@@ -7374,8 +7372,8 @@ system and gives an overview of their function and contents.
definitions can be a single static definition, or can be dynamically
adjusted. You can see details for a given CPU family by looking at
the architecture's ``README`` file. For example, the
``meta/conf/machine/include/mips/README`` file in the `Source
Directory <#source-directory>`__ provides information for
``meta/conf/machine/include/mips/README`` file in the
:term:`Source Directory` provides information for
``TUNE_ARCH`` specific to the ``mips`` architecture.
``TUNE_ARCH`` is tied closely to
@@ -7510,8 +7508,8 @@ system and gives an overview of their function and contents.
``meta/conf/machine/include/arm/arch-arm.inc``). Here is an example
from that file: TUNEVALID[bigendian] = "Enable big-endian mode."
See the machine include files in the `Source
Directory <#source-directory>`__ for these features.
See the machine include files in the :term:`Source Directory`
for these features.
UBOOT_CONFIG
Configures the :term:`UBOOT_MACHINE` and can
@@ -7696,8 +7694,7 @@ system and gives an overview of their function and contents.
The default list is set in your ``local.conf`` file: USER_CLASSES ?=
"buildstats image-mklibs image-prelink" For more information, see
``meta-poky/conf/local.conf.sample`` in the `Source
Directory <#source-directory>`__.
``meta-poky/conf/local.conf.sample`` in the :term:`Source Directory`.
USERADD_ERROR_DYNAMIC
If set to ``error``, forces the OpenEmbedded build system to produce
documentation/sdk-manual/sdk-appendix-customizing.rst
+4 -4
View File
@@ -150,7 +150,7 @@ set. If the ``DISTRO_NAME`` variable is not set, the title is derived
from the :term:`DISTRO` variable.
The
```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__
:ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
class defines the default value of the ``SDK_TITLE`` variable as
follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or
d.getVar('DISTRO')} SDK"
@@ -212,7 +212,7 @@ installation directory for the SDK is based on the
:term:`DISTRO` and
:term:`SDKEXTPATH` variables from
within the
```populate_sdk_base`` <&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*>`__
:ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
class as follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" You can
change this default installation directory by specifically setting the
``SDKEXTPATH`` variable.
@@ -276,8 +276,8 @@ source, you need to do a number of things:
- Alternatively, if you just want to set the ``SSTATE_MIRRORS``
variable's value for the SDK alone, create a
``conf/sdk-extra.conf`` file either in your `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ or within any
``conf/sdk-extra.conf`` file either in your
:term:`Build Directory` or within any
layer and put your ``SSTATE_MIRRORS`` setting within that file.
.. note::
documentation/sdk-manual/sdk-appendix-obtain.rst
+4 -4
View File
@@ -70,8 +70,8 @@ build the SDK installer. Follow these steps:
machine that uses CROPS.
2. *Clone the ``poky`` Repository:* You need to have a local copy of the
Yocto Project `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (i.e. a local
Yocto Project :term:`Source Directory`
(i.e. a local
``poky`` repository). See the "`Cloning the ``poky``
Repository <&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository>`__" and
possibly the "`Checking Out by Branch in
@@ -87,8 +87,8 @@ build the SDK installer. Follow these steps:
````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ environment
setup script to define the OpenEmbedded build environment on your
build host. $ source OE_INIT_FILE Among other things, the script
creates the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is
creates the :term:`Build Directory`,
which is
``build`` in this case and is located in the Source Directory. After
the script runs, your current working directory is set to the
``build`` directory.
documentation/sdk-manual/sdk-extensible.rst
+2 -2
View File
@@ -9,8 +9,8 @@ Information covers the pieces of the SDK, how to install it, and
presents a look at using the ``devtool`` functionality. The extensible
SDK makes it easy to add new applications and libraries to an image,
modify the source for an existing component, test changes on the target
hardware, and ease integration into the rest of the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__.
hardware, and ease integration into the rest of the
:term:`OpenEmbedded Build System`.
.. note::
documentation/sdk-manual/sdk-intro.rst
+4 -6
View File
@@ -39,8 +39,7 @@ All SDKs consist of the following:
Additionally, an extensible SDK has tools that allow you to easily add
new applications and libraries to an image, modify the source of an
existing component, test changes on the target hardware, and easily
integrate an application into the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__.
integrate an application into the :term:`OpenEmbedded Build System`.
You can use an SDK to independently develop and test code that is
destined to run on some target machine. SDKs are completely
@@ -126,8 +125,7 @@ of a cross-compiler, cross-linker, and cross-debugger that are used to
develop user-space applications for targeted hardware. Additionally, for
an extensible SDK, the toolchain also has built-in ``devtool``
functionality. This toolchain is created by running a SDK installer
script or through a `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ that is based on
script or through a :term:`Build Directory` that is based on
your metadata configuration or extension for your targeted device. The
cross-toolchain works with a matching target sysroot.
@@ -149,8 +147,8 @@ The QEMU emulator allows you to simulate your hardware while running
your application or image. QEMU is not part of the SDK but is made
available a number of different ways:
- If you have cloned the ``poky`` Git repository to create a `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and you have
- If you have cloned the ``poky`` Git repository to create a
:term:`Source Directory` and you have
sourced the environment setup script, QEMU is installed and
automatically available.
documentation/sdk-manual/sdk-working-projects.rst
+1 -2
View File
@@ -14,8 +14,7 @@ Once you have a suitable `cross-development
toolchain <&YOCTO_DOCS_REF_URL;#cross-development-toolchain>`__
installed, it is very easy to develop a project using the `GNU
Autotools-based <https://en.wikipedia.org/wiki/GNU_Build_System>`__
workflow, which is outside of the `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__.
workflow, which is outside of the :term:`OpenEmbedded Build System`.
The following figure presents a simple Autotools workflow.
documentation/toaster-manual/toaster-manual-intro.rst
+2 -2
View File
@@ -4,8 +4,8 @@
Introduction
************
Toaster is a web interface to the Yocto Project's `OpenEmbedded build
system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface
Toaster is a web interface to the Yocto Project's
:term:`OpenEmbedded Build System`. The interface
enables you to configure and run your builds. Information about builds
is collected and stored in a database. You can use Toaster to configure
and start builds on multiple remote build servers.
documentation/toaster-manual/toaster-manual-reference.rst
+4 -4
View File
@@ -422,15 +422,15 @@ at the
`Django <https://docs.djangoproject.com/en/1.7/topics/settings/>`__
site. However, several ``manage.py`` commands have been created that are
specific to Toaster and are used to control configuration and back-end
tasks. You can locate these commands in the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``) at
tasks. You can locate these commands in the
:term:`Source Directory` (e.g. ``poky``) at
``bitbake/lib/manage.py``. This section documents those commands.
.. note::
- When using ``manage.py`` commands given a default configuration,
you must be sure that your working directory is set to the `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. Using
you must be sure that your working directory is set to the
:term:`Build Directory`. Using
``manage.py`` commands from the Build Directory allows Toaster to
find the ``toaster.sqlite`` file, which is located in the Build
Directory.
documentation/toaster-manual/toaster-manual-setup-and-use.rst
+4 -4
View File
@@ -12,8 +12,8 @@ dependencies as described in the "`Preparing to Use
Toaster <#toaster-manual-start>`__" chapter, you are ready to start
Toaster.
Navigate to the root of your `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g. ``poky``): $
Navigate to the root of your
:term:`Source Directory` (e.g. ``poky``): $
cd poky Once in that directory, source the build environment script: $
source oe-init-build-env Next, from the build directory (e.g.
``poky/build``), start Toaster using this command: $ source toaster
@@ -267,8 +267,8 @@ Perform the following steps to install Toaster:
the "`Configuring Toaster <#configuring-toaster>`__" section.
This line also runs the ``checksettings`` command, which configures
the location of the Toaster `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The Toaster
the location of the Toaster :term:`Build Directory`.
The Toaster
root directory ``TOASTER_DIR`` determines where the Toaster build
directory is created on the file system. In the example above,
``TOASTER_DIR`` is set as follows: /var/www/toaster/poky This
documentation/toaster-manual/toaster-manual-start.rst
+2 -2
View File
@@ -28,8 +28,8 @@ Establishing Toaster System Dependencies
Toaster requires extra Python dependencies in order to run. A Toaster
requirements file named ``toaster-requirements.txt`` defines the Python
dependencies. The requirements file is located in the ``bitbake``
directory, which is located in the root directory of the `Source
Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ (e.g.
directory, which is located in the root directory of the
:term:`Source Directory` (e.g.
``poky/bitbake/toaster-requirements.txt``). The dependencies appear in a
``pip``, install-compatible format.