mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-06-01 00:59:48 +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/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