mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-04-26 18:32:13 +02:00
Code Issues Packages Projects Releases Wiki Activity

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

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

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

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

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

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

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

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

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

(From yocto-docs rev: ba49d9babfcb84bc5c26a68c8c3880a1d9c236d3)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

File diff suppressed because it is too large Load Diff