manuals: fix paragraphs with the "inherit" word

Nothing wrong with this word, but instances of "inherit"
were looked for while looking for class names without references.
Fixing alignment and sometimes syntax.

(From yocto-docs rev: c418c645a360e74ebb91765a3041336f03097e0d)

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
2022-11-22 11:19:58 +01:00
committed by Richard Purdie
parent 55621c31f1
commit 4d01625794
8 changed files with 64 additions and 82 deletions

View File

@@ -1703,26 +1703,21 @@ your software is built:
need to modify the configuration.
When using Autotools, your recipe needs to inherit the
:ref:`autotools <ref-classes-autotools>` class
and your recipe does not have to contain a
:ref:`ref-tasks-configure` task.
However, you might still want to make some adjustments. For example,
you can set
:term:`EXTRA_OECONF` or
:term:`PACKAGECONFIG_CONFARGS`
to pass any needed configure options that are specific to the recipe.
:ref:`autotools <ref-classes-autotools>` class and it does not have to
contain a :ref:`ref-tasks-configure` task. However, you might still want to
make some adjustments. For example, you can set :term:`EXTRA_OECONF` or
:term:`PACKAGECONFIG_CONFARGS` to pass any needed configure options that
are specific to the recipe.
- *CMake:* If your source files have a ``CMakeLists.txt`` file, then
your software is built using CMake. If this is the case, you just
need to modify the configuration.
When you use CMake, your recipe needs to inherit the
:ref:`cmake <ref-classes-cmake>` class and your
recipe does not have to contain a
:ref:`ref-tasks-configure` task.
You can make some adjustments by setting
:term:`EXTRA_OECMAKE` to
pass any needed configure options that are specific to the recipe.
:ref:`cmake <ref-classes-cmake>` class and it does not have to contain a
:ref:`ref-tasks-configure` task. You can make some adjustments by setting
:term:`EXTRA_OECMAKE` to pass any needed configure options that are
specific to the recipe.
.. note::
@@ -1997,9 +1992,8 @@ different ways:
shutdown of all other programs.
To enable a service using SysVinit, your recipe needs to inherit the
:ref:`update-rc.d <ref-classes-update-rc.d>`
class. The class helps facilitate safely installing the package on
the target.
:ref:`update-rc.d <ref-classes-update-rc.d>` class. The class helps
facilitate safely installing the package on the target.
You will need to set the
:term:`INITSCRIPT_PACKAGES`,
@@ -2014,10 +2008,8 @@ different ways:
https://freedesktop.org/wiki/Software/systemd/.
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 :term:`Source Directory`
section for
more information.
:ref:`systemd <ref-classes-systemd>` class. See the ``systemd.bbclass`` file
located in your :term:`Source Directory` section for more information.
Packaging
---------
@@ -2370,8 +2362,7 @@ Autotooled Package
Applications that use Autotools such as ``autoconf`` and ``automake``
require a recipe that has a source archive listed in :term:`SRC_URI` and
also inherit the
:ref:`autotools <ref-classes-autotools>` class,
also inherit the :ref:`autotools <ref-classes-autotools>` class,
which contains the definitions of all the steps needed to build an
Autotool-based application. The result of the build is automatically
packaged. And, if the application uses NLS for localization, packages
@@ -4404,13 +4395,10 @@ where the development occurs. You want the recipe's
:term:`SRC_URI` variable to point to
the external directory and use it as is, not copy it.
To build from software that comes from an external source, all you need
to do is inherit the
:ref:`externalsrc <ref-classes-externalsrc>` class
and then set the
:term:`EXTERNALSRC` variable to
point to your external source code. Here are the statements to put in
your ``local.conf`` file::
To build from software that comes from an external source, all you need to do
is inherit the :ref:`externalsrc <ref-classes-externalsrc>` class and then set
the :term:`EXTERNALSRC` variable to point to your external source code. Here
are the statements to put in your ``local.conf`` file::
INHERIT += "externalsrc"
EXTERNALSRC:pn-myrecipe = "path-to-your-source-tree"
@@ -4494,8 +4482,7 @@ directory:
1. *Using Local Files Only:* Inside your ``local.conf`` file, add the
:term:`SOURCE_MIRROR_URL` variable, inherit the
:ref:`own-mirrors <ref-classes-own-mirrors>` class, and use the
:term:`BB_NO_NETWORK` variable to your ``local.conf``.
::
:term:`BB_NO_NETWORK` variable to your ``local.conf``::
SOURCE_MIRROR_URL ?= "file:///home/your-download-dir/"
INHERIT += "own-mirrors"
@@ -7441,8 +7428,7 @@ In order to enable a recipe to run installed ptests on target hardware,
you need to prepare the recipes that build the packages you want to
test. Here is what you have to do for each recipe:
- *Be sure the recipe inherits
the* :ref:`ptest <ref-classes-ptest>` *class:*
- *Be sure the recipe inherits the* :ref:`ptest <ref-classes-ptest>` *class:*
Include the following line in each recipe::
inherit ptest
@@ -8868,8 +8854,7 @@ You can start the tests automatically or manually:
bitbake core-image-sato
- *Manually running tests:* To manually run the tests, first globally
inherit the
:ref:`testimage <ref-classes-testimage>` class
inherit the :ref:`testimage <ref-classes-testimage>` class
by editing your ``local.conf`` file::
INHERIT += "testimage"
@@ -9287,8 +9272,7 @@ In addition to variable values, the output of the ``bitbake -e`` and
classes included globally, recursively listing the files they include
or inherit in turn. Much of the behavior of the OpenEmbedded build
system (including the behavior of the :ref:`ref-manual/tasks:normal recipe build tasks`) is
implemented in the
:ref:`base <ref-classes-base>` class and the
implemented in the :ref:`base <ref-classes-base>` class and the
classes it inherits, rather than being built into BitBake itself.
- After the variable values, all functions appear in the output. For

View File

@@ -221,8 +221,8 @@ Task Recipes
The previously deprecated ``task.bbclass`` has now been dropped. For
recipes that previously inherited from this class, you should rename
them from ``task-*`` to ``packagegroup-*`` and inherit packagegroup
instead.
them from ``task-*`` to ``packagegroup-*`` and inherit
:ref:`packagegroup <ref-classes-packagegroup>` instead.
For more information, see the ":ref:`ref-classes-packagegroup`" section.

View File

@@ -259,7 +259,9 @@ The following miscellaneous changes have occurred.
- The ``gnome`` class has been removed because it now does very little.
You should update recipes that previously inherited this class to do
the following: inherit gnomebase gtk-icon-cache gconf mime
the following::
inherit gnomebase gtk-icon-cache gconf mime
- The ``meta/recipes-kernel/linux/linux-dtb.inc`` file has been
removed. This file was previously deprecated in favor of setting

View File

@@ -99,9 +99,9 @@ variable so that recipes can specify it explicitly, for example::
Recipes that inherit from ``distutils3`` (or
:ref:`setuptools3 <ref-classes-setuptools3>` which itself inherits
``distutils3``) that also set :term:`S` to
point to a Python module within a subdirectory in the aforementioned
manner should be changed to set ``DISTUTILS_SETUP_PATH`` instead.
``distutils3``) that also set :term:`S` to point to a Python module within a
subdirectory in the aforementioned manner should be changed to set
``DISTUTILS_SETUP_PATH`` instead.
.. _migration-3.3-bitbake:

View File

@@ -210,9 +210,8 @@ information.
An alternative version of the :ref:`binconfig <ref-classes-binconfig>`
class, which disables binary configuration scripts by making them return
an error in favor of using ``pkg-config`` to query the information. The
scripts to be disabled should be specified using the
:term:`BINCONFIG` variable within the recipe inheriting
the class.
scripts to be disabled should be specified using the :term:`BINCONFIG`
variable within the recipe inheriting the class.
.. _ref-classes-buildhistory:
@@ -580,8 +579,7 @@ By default, the OpenEmbedded build system uses the :term:`S`
and :term:`B` variables to locate unpacked recipe source code
and to build it, respectively. When your recipe inherits the
:ref:`externalsrc <ref-classes-externalsrc>` class, you use the
:term:`EXTERNALSRC` and
:term:`EXTERNALSRC_BUILD` variables to
:term:`EXTERNALSRC` and :term:`EXTERNALSRC_BUILD` variables to
ultimately define :term:`S` and :term:`B`.
By default, this class expects the source code to support recipe builds
@@ -734,9 +732,9 @@ register and unregister the schemas in the target image.
``gettext.bbclass``
===================
The :ref:`gettext <ref-classes-gettext>` class provides support for building software that uses
the GNU ``gettext`` internationalization and localization system. All
recipes building software that use ``gettext`` should inherit this
The :ref:`gettext <ref-classes-gettext>` class provides support for building
software that uses the GNU ``gettext`` internationalization and localization
system. All recipes building software that use ``gettext`` should inherit this
class.
.. _ref-classes-github-releases:

View File

@@ -579,10 +579,10 @@ Errors and Warnings
- ``package contains mime types but does not inherit mime: <packagename> path '<file>' [mime]``
The specified package contains mime type files (``.xml`` files in
``${datadir}/mime/packages``) and yet does not inherit the mime
class which will ensure that these get properly installed. Either
add ``inherit mime`` to the recipe or remove the files at the
:ref:`ref-tasks-install` step if they are not needed.
``${datadir}/mime/packages``) and yet does not inherit the
:ref:`mime <ref-classes-mime>` class which will ensure that these get
properly installed. Either add ``inherit mime`` to the recipe or remove the
files at the :ref:`ref-tasks-install` step if they are not needed.
.. _qa-check-mime-xdg:
@@ -620,11 +620,13 @@ Errors and Warnings
- ``<recipename>: recipe doesn't inherit features_check [unhandled-features-check]``
This check ensures that if one of the variables that the :ref:`features_check <ref-classes-features_check>`
class supports (e.g. :term:`REQUIRED_DISTRO_FEATURES`) is used, then the recipe
inherits ``features_check`` in order for the requirement to actually work. If
you are seeing this message, either add ``inherit features_check`` to your recipe
or remove the reference to the variable if it is not needed.
This check ensures that if one of the variables that the
:ref:`features_check <ref-classes-features_check>` class supports (e.g.
:term:`REQUIRED_DISTRO_FEATURES`) is used, then the recipe
inherits :ref:`features_check <ref-classes-features_check>` in order for
the requirement to actually work. If you are seeing this message, either
add ``inherit features_check`` to your recipe or remove the reference to
the variable if it is not needed.
.. _qa-check-missing-update-alternatives:

View File

@@ -126,8 +126,7 @@ system and gives an overview of their function and contents.
":ref:`ref-classes-update-alternatives`" section.
:term:`ANY_OF_DISTRO_FEATURES`
When inheriting the
:ref:`features_check <ref-classes-features_check>`
When inheriting the :ref:`features_check <ref-classes-features_check>`
class, this variable identifies a list of distribution features where
at least one must be enabled in the current configuration in order
for the OpenEmbedded build system to build the recipe. In other words,
@@ -215,12 +214,11 @@ system and gives an overview of their function and contents.
If you use the previous statement to retrieve the latest version of
software, you need to be sure :term:`PV` contains
``${``\ :term:`SRCPV`\ ``}``. For example, suppose you
have a kernel recipe that inherits the
:ref:`kernel <ref-classes-kernel>` class and you use the previous
statement. In this example, ``${SRCPV}`` does not automatically get
into :term:`PV`. Consequently, you need to change :term:`PV` in your recipe
so that it does contain ``${SRCPV}``.
``${``\ :term:`SRCPV`\ ``}``. For example, suppose you have a kernel
recipe that inherits the :ref:`kernel <ref-classes-kernel>` class and you
use the previous statement. In this example, ``${SRCPV}`` does not
automatically get into :term:`PV`. Consequently, you need to change
:term:`PV` in your recipe so that it does contain ``${SRCPV}``.
For more information see the
":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
@@ -3566,9 +3564,9 @@ system and gives an overview of their function and contents.
IMGDEPLOYDIR = "${WORKDIR}/deploy-${PN}-image-complete"
Recipes inheriting the ``image`` class should copy files to be
deployed into :term:`IMGDEPLOYDIR`, and the class will take care of
copying them into :term:`DEPLOY_DIR_IMAGE` afterwards.
Recipes inheriting the :ref:`image <ref-classes-image>` class should copy
files to be deployed into :term:`IMGDEPLOYDIR`, and the class will take
care of copying them into :term:`DEPLOY_DIR_IMAGE` afterwards.
:term:`INC_PR`
Helps define the recipe revision for recipes that share a common
@@ -6542,8 +6540,7 @@ system and gives an overview of their function and contents.
section.
:term:`REQUIRED_DISTRO_FEATURES`
When inheriting the
:ref:`features_check <ref-classes-features_check>`
When inheriting the :ref:`features_check <ref-classes-features_check>`
class, this variable identifies distribution features that must exist
in the current configuration in order for the OpenEmbedded build
system to build the recipe. In other words, if the

View File

@@ -44,14 +44,13 @@ build system applies them against ``local.conf`` and ``auto.conf``:
:term:`ESDK_LOCALCONF_ALLOW` overrides either of the previous two
filters. The default value is blank.
- Classes inherited globally with
:term:`INHERIT` that are listed in
:term:`ESDK_CLASS_INHERIT_DISABLE`
are disabled. Using :term:`ESDK_CLASS_INHERIT_DISABLE` to disable these
classes is the typical method to disable classes that are problematic
or unnecessary in the SDK context. The default value disables the
:ref:`buildhistory <ref-classes-buildhistory>`
and :ref:`icecc <ref-classes-icecc>` classes.
- Classes inherited globally with :term:`INHERIT` that are listed in
:term:`ESDK_CLASS_INHERIT_DISABLE` are disabled. Using
:term:`ESDK_CLASS_INHERIT_DISABLE` to disable these classes is the typical
method to disable classes that are problematic or unnecessary in the SDK
context. The default value disables the
:ref:`buildhistory <ref-classes-buildhistory>` and
:ref:`icecc <ref-classes-icecc>` classes.
Additionally, the contents of ``conf/sdk-extra.conf``, when present, are
appended to the end of ``conf/local.conf`` within the produced SDK,