mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-01-29 21:08:42 +01:00
Code Issues Packages Projects Releases Wiki Activity

ref-manual: simplify style

Browse Source 
(From yocto-docs rev: 657a7f54856afd6fec7f2cb0b5f12b4b2d24adb7)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
2021-05-12 11:29:20 +02:00
committed by Richard Purdie
parent 68ee5b4bcc
commit 4db4e4ca46
11 changed files with 69 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1006,7 +1006,7 @@ package name override, in this example ``${PN}``, must be used::
INSANE_SKIP_${PN} += "dev-so"
Please keep in mind that the QA checks
exist in order to detect real or potential problems in the packaged
are meant to detect real or potential problems in the packaged
output. So exercise caution when disabling these checks.
Here are the tests you can list with the ``WARN_QA`` and
@@ -1085,8 +1085,8 @@ Here are the tests you can list with the ``WARN_QA`` and
- ``dev-so:`` Checks that the ``.so`` symbolic links are in the
``-dev`` package and not in any of the other packages. In general,
these symlinks are only useful for development purposes. Thus, the
``-dev`` package is the correct location for them. Some very rare
cases do exist for dynamically loaded modules where these symlinks
``-dev`` package is the correct location for them. In very rare
cases, such as dynamically loaded modules, these symlinks
are needed instead in the main package.
- ``file-rdeps:`` Checks that file-level dependencies identified by
@@ -1676,7 +1676,7 @@ couple different ways:
nativesdk-myrecipe.bb
Not doing so can lead to subtle problems because code exists that
Not doing so can lead to subtle problems because there is code that
depends on the naming convention.
Although applied differently, the ``nativesdk`` class is used with both
@@ -1714,10 +1714,10 @@ section in the Yocto Project Development Tasks Manual.
``oelint.bbclass``
==================
The ``oelint`` class is an obsolete lint checking tool that exists in
The ``oelint`` class is an obsolete lint checking tool available in
``meta/classes`` in the :term:`Source Directory`.
A number of classes exist that could be generally useful in OE-Core but
There are some classes that could be generally useful in OE-Core but
are never actually used within OE-Core itself. The ``oelint`` class is
one such example. However, being aware of this class can reduce the
proliferation of different versions of similar classes across multiple

10
documentation/ref-manual/devtool-reference.rst
View File

@@ -403,8 +403,8 @@ Upgrading a Recipe
As software matures, upstream recipes are upgraded to newer versions. As
a developer, you need to keep your local recipes up-to-date with the
upstream version releases. Several methods exist by which you can
upgrade recipes. You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`"
upstream version releases. There are several ways of upgrading recipes.
You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`"
section of the Yocto Project Development Tasks Manual. This section
overviews the ``devtool upgrade`` command.
@@ -516,8 +516,8 @@ you do, the package manager is bypassed.
should never use it to update an image that will be used in
production.
Some conditions exist that could prevent a deployed application from
behaving as expected. When both of the following conditions exist, your
Some conditions could prevent a deployed application from
behaving as expected. When both of the following conditions are met, your
application has the potential to not behave correctly when run on the
target:
@@ -528,7 +528,7 @@ target:
- The target does not physically have the packages on which the
application depends installed.
If both of these conditions exist, your application will not behave as
If both of these conditions are met, your application will not behave as
expected. The reason for this misbehavior is because the
``devtool deploy-target`` command does not deploy the packages (e.g.
libraries) on which your new application depends. The assumption is that

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

@@ -312,7 +312,7 @@ HTTPS requests and direct them to the ``http://`` sources mirror. You
can use ``file://`` URLs to point to local directories or network shares
as well.
Aside from the previous technique, these options also exist::
Here are other options::
BB_NO_NETWORK = "1"

2
documentation/ref-manual/kickstart.rst
View File

@@ -210,5 +210,5 @@ supports the following options:
- ``--configfile``: Specifies a user-defined configuration file for
the bootloader. You can provide a full pathname for the file or a
file that exists in the ``canned-wks`` folder. This option overrides
file located in the ``canned-wks`` folder. This option overrides
all other bootloader options.

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

@@ -97,7 +97,7 @@ Errors and Warnings
- ``<packagename1> rdepends on <packagename2>, but it isn't a build dependency? [build-deps]``
A runtime dependency exists between the two specified packages, but
There is a runtime dependency between the two specified packages, but
there is nothing explicit within the recipe to enable the
OpenEmbedded build system to ensure that dependency is satisfied.
This condition is usually triggered by an
@@ -303,7 +303,7 @@ Errors and Warnings
- ``<packagename> rdepends on <debug_packagename> [debug-deps]``
A dependency exists between the specified non-dbg package (i.e. a
There is a dependency between the specified non-dbg package (i.e. a
package whose name does not end in ``-dbg``) and a package that is a
``dbg`` package. The ``dbg`` packages contain debug symbols and are
brought in using several different methods:
@@ -326,7 +326,7 @@ Errors and Warnings
- ``<packagename> rdepends on <dev_packagename> [dev-deps]``
A dependency exists between the specified non-dev package (a package
There is a dependency between the specified non-dev package (a package
whose name does not end in ``-dev``) and a package that is a ``dev``
package. The ``dev`` packages contain development headers and are
usually brought in using several different methods:
@@ -753,6 +753,6 @@ how to work with the QA checks, see the
.. note::
Please keep in mind that the QA checks exist in order to detect real
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.

4
documentation/ref-manual/release-process.rst
View File

@@ -82,14 +82,14 @@ stable release.
bug fixes and security fixes only. Policy dictates that features are
not backported to a stable release. This policy means generic recipe
version upgrades are unlikely to be accepted for backporting. The
exception to this policy occurs when a strong reason exists such as
exception to this policy occurs when there is a strong reason such as
the fix happens to also be the preferred upstream approach.
Stable release branches have strong maintenance for about a year after
their initial release. Should significant issues be found for any
release regardless of its age, fixes could be backported to older
releases. For issues that are not backported given an older release,
Community LTS trees and branches exist where community members share
Community LTS trees and branches allow community members to share
patches for older releases. However, these types of patches do not go
through the same release process as do point releases. You can find more
information about stable branch maintenance at

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

@@ -10,7 +10,7 @@ Introduction
============
The Yocto Project team is happy for people to experiment with the Yocto
Project. A number of places exist to find help if you run into
Project. There is a number of places where you can find help if you run into
difficulties or find bugs. This presents information about contributing
and participating in the Yocto Project.
@@ -43,8 +43,7 @@ the Yocto Project itself (e.g. when discovering an issue with some
component of the build system that acts contrary to the documentation or
your expectations).
A general procedure and guidelines exist for when you use Bugzilla to
submit a bug. For information on how to use Bugzilla to submit a bug
For a general procedure and guidelines on how to use Bugzilla to submit a bug
against the Yocto Project, see the following:
- The ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
@@ -59,7 +58,7 @@ For information on Bugzilla in general, see https://www.bugzilla.org/about/.
Mailing lists
=============
A number of mailing lists maintained by the Yocto Project exist as well
There are multiple mailing lists maintained by the Yocto Project as well
as related OpenEmbedded mailing lists for discussion, patch submission
and announcements. To subscribe to one of the following mailing lists,
click on the appropriate URL in the following list and follow the
@@ -156,9 +155,8 @@ Here is a list of resources you might find helpful:
- :yocto_docs:`Yocto Project Mega-Manual </singleindex.html>`\ *:* This manual
is simply a single HTML file comprised of the bulk of the Yocto
Project manuals. The Mega-Manual primarily exists as a vehicle by
which you can easily search for phrases and terms used in the Yocto
Project documentation set.
Project manuals. It makes it easy to search for phrases and terms used
in the Yocto Project documentation set.
- :doc:`/profile-manual/index` *:* This manual presents a set of
common and generally useful tracing and profiling schemes along with

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

@@ -510,8 +510,8 @@ should be automatic, and recipes should not directly reference
-----------------------
Previous versions of the OpenEmbedded build system used to create a
global shared sysroot per machine along with a native sysroot. Beginning
with the 2.3 version of the Yocto Project, sysroots exist in
global shared sysroot per machine along with a native sysroot. Since
the 2.3 version of the Yocto Project, there are sysroots in
recipe-specific :term:`WORKDIR` directories. Thus, the
``build/tmp/sysroots/`` directory is unused.
@@ -601,7 +601,7 @@ constructed using the architecture of the given build (e.g.
name, and the version of the recipe (i.e.
:term:`PE`\ ``:``\ :term:`PV`\ ``-``\ :term:`PR`).
A number of key subdirectories exist within each recipe work directory:
Here are key subdirectories within each recipe work directory:
- ``${WORKDIR}/temp``: Contains the log files of each task executed for
this recipe, the "run" files for each executed task, which contain
@@ -624,7 +624,7 @@ A number of key subdirectories exist within each recipe work directory:
- ``${WORKDIR}/packages-split``: Contains the output of the
``do_package`` task after the output has been split into individual
packages. Subdirectories exist for each individual package created by
packages. There are subdirectories for each individual package created by
the recipe.
- ``${WORKDIR}/recipe-sysroot``: A directory populated with the target

8
documentation/ref-manual/system-requirements.rst
View File

@@ -66,9 +66,8 @@ distributions:
- While the Yocto Project Team attempts to ensure all Yocto Project
releases are one hundred percent compatible with each officially
supported Linux distribution, instances might exist where you
encounter a problem while using the Yocto Project on a specific
distribution.
supported Linux distribution, you may still encounter problems
that happen only with a specific distribution.
- Yocto Project releases are tested against the stable Linux
distributions in the above list. The Yocto Project should work
@@ -119,8 +118,7 @@ supported Ubuntu or Debian Linux distribution:
- If your build system has the ``oss4-dev`` package installed, you
might experience QEMU build failures due to the package installing
its own custom ``/usr/include/linux/soundcard.h`` on the Debian
system. If you run into this situation, either of the following
solutions exist::
system. If you run into this situation, try either of these solutions::
$ sudo apt-get build-dep qemu
$ sudo apt-get remove oss4-dev

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

@@ -823,6 +823,5 @@ sections from a size-sensitive configuration.
After the kernel is unpacked but before it is patched, this task makes
sure that the machine and metadata branches as specified by the
:term:`SRCREV` variables actually exist on the specified
branches. If these branches do not exist and
:term:`AUTOREV` is not being used, the
branches. Otherwise, if :term:`AUTOREV` is not being used, the
``do_validate_branches`` task fails during the build.

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

@@ -49,10 +49,9 @@ system and gives an overview of their function and contents.
alternatives system to create a different binary naming scheme so the
commands can co-exist.
To use the variable, list out the package's commands that also exist
as part of another package. For example, if the ``busybox`` package
has four commands that also exist as part of another package, you
identify them as follows::
To use the variable, list out the package's commands that are also
provided by another package. For example, if the ``busybox`` package
has four such commands, you identify them as follows::
ALTERNATIVE_busybox = "sh sed test bracket"
@@ -306,8 +305,8 @@ system and gives an overview of their function and contents.
variable), the OpenEmbedded build system ignores your request and
will install the packages to avoid dependency errors.
Support for this variable exists only when using the IPK and RPM
packaging backend. Support does not exist for DEB.
This variable is supported only when using the IPK and RPM
packaging backends. DEB is not supported.
See the :term:`NO_RECOMMENDATIONS` and the
:term:`PACKAGE_EXCLUDE` variables for related
@@ -336,8 +335,8 @@ system and gives an overview of their function and contents.
- This host list is only used if ``BB_NO_NETWORK`` is either not set
or set to "0".
- Limited support for wildcard matching against the beginning of
host names exists. For example, the following setting matches
- There is limited support for wildcard matching against the beginning of
host names. For example, the following setting matches
``git.gnu.org``, ``ftp.gnu.org``, and ``foo.git.gnu.org``.
::
@@ -558,7 +557,7 @@ system and gives an overview of their function and contents.
:term:`BBCLASSEXTEND`
Allows you to extend a recipe so that it builds variants of the
software. Common variants for recipes exist such as "natives" like
software. There are common variants for recipes as "natives" like
``quilt-native``, which is a copy of Quilt built to run on the build
system; "crosses" such as ``gcc-cross``, which is a compiler built to
run on the build machine but produces binaries that run on the target
@@ -1237,7 +1236,7 @@ system and gives an overview of their function and contents.
CONFFILES_${PN} += "${sysconfdir}/file1 \
${sysconfdir}/file2 ${sysconfdir}/file3"
A relationship exists between the ``CONFFILES`` and ``FILES``
There is a relationship between the ``CONFFILES`` and ``FILES``
variables. The files listed within ``CONFFILES`` must be a subset of
the files listed within ``FILES``. Because the configuration files
you provide with ``CONFFILES`` are simply being identified so that
@@ -1417,8 +1416,8 @@ system and gives an overview of their function and contents.
:term:`COREBASE_FILES`
Lists files from the :term:`COREBASE` directory that
should be copied other than the layers listed in the
``bblayers.conf`` file. The ``COREBASE_FILES`` variable exists for
the purpose of copying metadata from the OpenEmbedded build system
``bblayers.conf`` file. The ``COREBASE_FILES`` variable allows
to copy metadata from the OpenEmbedded build system
into the extensible SDK.
Explicitly listing files in ``COREBASE`` is needed because it
@@ -2460,8 +2459,8 @@ system and gives an overview of their function and contents.
``FILESEXTRAPATHS`` variable.
You can take advantage of this searching behavior in useful ways. For
example, consider a case where the following directory structure
exists for general and machine-specific configurations::
example, consider a case where there is the following directory structure
for general and machine-specific configurations::
files/defconfig
files/MACHINEA/defconfig
@@ -3013,8 +3012,8 @@ system and gives an overview of their function and contents.
Image recipes set ``IMAGE_INSTALL`` to specify the packages to
install into an image through ``image.bbclass``. Additionally,
"helper" classes such as the
:ref:`core-image <ref-classes-core-image>` class exist that can
there are "helper" classes such as the
:ref:`core-image <ref-classes-core-image>` class which can
take lists used with ``IMAGE_FEATURES`` and turn them into
auto-generated entries in ``IMAGE_INSTALL`` in addition to its
default contents.
@@ -3465,8 +3464,8 @@ system and gives an overview of their function and contents.
Use of the ``INHIBIT_SYSROOT_STRIP`` variable occurs in rare and
special circumstances. For example, suppose you are building
bare-metal firmware by using an external GCC toolchain. Furthermore,
even if the toolchain's binaries are strippable, other files exist
that are needed for the build that are not strippable.
even if the toolchain's binaries are strippable, there are other files
needed for the build that are not strippable.
:term:`INITRAMFS_FSTYPES`
Defines the format for the output image of an initial RAM filesystem
@@ -3817,7 +3816,7 @@ system and gives an overview of their function and contents.
.. note::
Legacy support exists for specifying the full path to the device
There is legacy support for specifying the full path to the device
tree. However, providing just the ``.dtb`` file is preferred.
In order to use this variable, the
@@ -4042,7 +4041,7 @@ system and gives an overview of their function and contents.
:term:`KERNELDEPMODDEPEND`
Specifies whether the data referenced through
:term:`PKGDATA_DIR` is needed or not. The
:term:`PKGDATA_DIR` is needed or not.
``KERNELDEPMODDEPEND`` does not control whether or not that data
exists, but simply whether or not it is used. If you do not need to
use the data, set the ``KERNELDEPMODDEPEND`` variable in your
@@ -4227,8 +4226,8 @@ system and gives an overview of their function and contents.
- Separate license names using \| (pipe) when there is a choice
between licenses.
- Separate license names using & (ampersand) when multiple licenses
exist that cover different parts of the source.
- Separate license names using & (ampersand) when there are
multiple licenses for different parts of the source.
- You can use spaces between license names.
@@ -4376,8 +4375,8 @@ system and gives an overview of their function and contents.
The variable corresponds to a machine configuration file of the same
name, through which machine-specific configurations are set. Thus,
when ``MACHINE`` is set to "qemux86" there exists the corresponding
``qemux86.conf`` machine configuration file, which can be found in
when ``MACHINE`` is set to "qemux86", the corresponding
``qemux86.conf`` machine configuration file can be found in
the :term:`Source Directory` in
``meta/conf/machine``.
@@ -4742,7 +4741,7 @@ system and gives an overview of their function and contents.
:term:`NO_GENERIC_LICENSE`
Avoids QA errors when you use a non-common, non-CLOSED license in a
recipe. Packages exist, such as the linux-firmware package, with many
recipe. There are packages, such as the linux-firmware package, with many
licenses that are not in any way common. Also, new licenses are added
occasionally to avoid introducing a lot of common license files,
which are only applicable to a specific package.
@@ -4786,8 +4785,8 @@ system and gives an overview of their function and contents.
functionality, such as kernel modules. It is up to you to add
packages with the :term:`IMAGE_INSTALL` variable.
Support for this variable exists only when using the IPK and RPM
packaging backend. Support does not exist for DEB.
This variable is only supported when using the IPK and RPM
packaging backends. DEB is not supported.
See the :term:`BAD_RECOMMENDATIONS` and
the :term:`PACKAGE_EXCLUDE` variables for
@@ -5064,8 +5063,8 @@ system and gives an overview of their function and contents.
an iterative development process to remove specific components from a
system.
Support for this variable exists only when using the IPK and RPM
packaging backend. Support does not exist for DEB.
This variable is supported only when using the IPK and RPM
packaging backends. DEB is not supported.
See the :term:`NO_RECOMMENDATIONS` and the
:term:`BAD_RECOMMENDATIONS` variables for
@@ -6211,7 +6210,7 @@ system and gives an overview of their function and contents.
:term:`PACKAGE_EXCLUDE` variables.
Packages specified in ``RRECOMMENDS`` need not actually be produced.
However, a recipe must exist that provides each package, either
However, there must be a recipe providing each package, either
through the :term:`PACKAGES` or
:term:`PACKAGES_DYNAMIC` variables or the
:term:`RPROVIDES` variable, or an error will occur
@@ -6979,8 +6978,8 @@ system and gives an overview of their function and contents.
- ``az://`` - Fetches files from an Azure Storage account.
Standard and recipe-specific options for ``SRC_URI`` exist. Here are
standard options:
There are standard and recipe-specific options for ``SRC_URI``. Here are
standard ones:
- ``apply`` - Whether to apply the patch or not. The default
action is to apply the patch.
@@ -7667,8 +7666,8 @@ system and gives an overview of their function and contents.
:term:`TARGET_OS`
Specifies the target's operating system. The variable can be set to
"linux" for glibc-based systems (GNU C Library) and to "linux-musl"
for musl libc. For ARM/EABI targets, "linux-gnueabi" and
"linux-musleabi" possible values exist.
for musl libc. For ARM/EABI targets, the possible values are
"linux-gnueabi" and "linux-musleabi".
:term:`TARGET_PREFIX`
Specifies the prefix used for the toolchain binary target tools.
@@ -8369,11 +8368,10 @@ system and gives an overview of their function and contents.
configure options are simply not passed to the configure script (e.g.
should be removed from :term:`EXTRA_OECONF` or
:term:`PACKAGECONFIG_CONFARGS`).
However, common options, for example, exist that are passed to all
configure scripts at a class level that might not be valid for some
configure scripts. It follows that no benefit exists in seeing a
warning about these options. For these cases, the options are added
to ``UNKNOWN_CONFIGURE_WHITELIST``.
However, there are common options that are passed to all
configure scripts at a class level, but might not be valid for some
configure scripts. Therefore warnings about these options are useless.
For these cases, the options are added to ``UNKNOWN_CONFIGURE_WHITELIST``.
The configure arguments check that uses
``UNKNOWN_CONFIGURE_WHITELIST`` is part of the