sphinx-lint: unbalanced inline literal markup

Fix as many instances of unbalanced-inline-literals-delimiters as reported
by 'make sphinx-lint' as possible. Sphinx and/or its linter seem to get
tripped up randomly when references contain links to heading which contain
literals enclosed in double-back-tics, and not all of them can be "fixed"
to pass both building and linting.

(From yocto-docs rev: 2c1e5b080ad5e62d8283d332cbc473fd2d59c6e6)

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This commit is contained in:
Trevor Woerner 2025-05-24 16:06:30 -04:00 committed by Steve Sakoman
parent d2de20a4b6
commit 7dfd7de941
15 changed files with 27 additions and 27 deletions

View File

@ -182,7 +182,7 @@ an entire Linux distribution, including the toolchain, from source.
page of the Yocto Project Wiki.
#. **Initialize the Build Environment:** From within the ``poky``
directory, run the :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``
directory, run the :ref:`ref-manual/structure:``oe-init-build-env```
environment
setup script to define Yocto Project's build environment on your
build host.

View File

@ -81,7 +81,7 @@ directory of that Layer. This directory is what you add to the
``conf/bblayers.conf`` file found in your
:term:`Build Directory`, which is
established after you run the OpenEmbedded build environment setup
script (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``).
script (i.e. :ref:`ref-manual/structure:``oe-init-build-env```).
Adding the root directory allows the :term:`OpenEmbedded Build System`
to recognize the BSP
layer and from it build an image. Here is an example::
@ -230,7 +230,7 @@ section.
#. *Initialize the Build Environment:* While in the root directory of
the Source Directory (i.e. ``poky``), run the
:ref:`ref-manual/structure:\`\`oe-init-build-env\`\`` environment
:ref:`ref-manual/structure:``oe-init-build-env``` environment
setup script to define the OpenEmbedded build environment on your
build host. ::

View File

@ -36,7 +36,7 @@ section:
use the BitBake ``-e`` option to examine variable values after a
recipe has been parsed.
- ":ref:`dev-manual/debugging:viewing package information with \`\`oe-pkgdata-util\`\``"
- ":ref:`dev-manual/debugging:viewing package information with ``oe-pkgdata-util```"
describes how to use the ``oe-pkgdata-util`` utility to query
:term:`PKGDATA_DIR` and
display package-related information for built packages.

View File

@ -56,7 +56,7 @@ necessary when adding a recipe to build a new piece of software to be
included in a build.
You can find a complete description of the ``devtool add`` command in
the ":ref:`sdk-manual/extensible:a closer look at \`\`devtool add\`\``" section
the ":ref:`sdk-manual/extensible:a closer look at ``devtool add```" section
in the Yocto Project Application Development and the Extensible Software
Development Kit (eSDK) manual.

View File

@ -333,7 +333,7 @@ Manually Upgrading a Recipe
If for some reason you choose not to upgrade recipes using
:ref:`dev-manual/upgrading-recipes:Using the Auto Upgrade Helper (AUH)` or
by :ref:`dev-manual/upgrading-recipes:Using \`\`devtool upgrade\`\``,
by :ref:`dev-manual/upgrading-recipes:Using ``devtool upgrade```,
you can manually edit the recipe files to upgrade the versions.
.. note::

View File

@ -514,7 +514,7 @@ or ::
For more information on how to use the ``bmaptool``
to flash a device with an image, see the
":ref:`dev-manual/bmaptool:flashing images using \`\`bmaptool\`\``"
":ref:`dev-manual/bmaptool:flashing images using ``bmaptool```"
section.
Using a Modified Kickstart File

View File

@ -746,7 +746,7 @@ the extensible SDK and ``devtool``.
Before attempting this procedure, be sure you have performed the
steps to get ready for updating the kernel as described in the
":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
section.
Patching the kernel involves changing or adding configurations to an
@ -759,7 +759,7 @@ output at boot time through ``printk`` statements in the kernel's
``calibrate.c`` source code file. Applying the patch and booting the
modified image causes the added messages to appear on the emulator's
console. The example is a continuation of the setup procedure found in
the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Section.
the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Section.
1. *Check Out the Kernel Source Files:* First you must use ``devtool``
to checkout the kernel source code in its workspace. Be sure you are
@ -768,7 +768,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
.. note::
See this step in the
":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
section for more information.
Use the following ``devtool`` command to check out the code::
@ -883,7 +883,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
.. note::
See Step 3 of the
":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
section for information on setting up this layer.
Once the command
@ -1271,7 +1271,7 @@ appear in the ``.config`` file, which is in the :term:`Build Directory`.
For more information about where the ``.config`` file is located, see the
example in the
":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
":ref:`kernel-dev/common:using ``menuconfig```"
section.
It is simple to create a configuration fragment. One method is to use
@ -1367,7 +1367,7 @@ when you override a policy configuration in a hardware configuration
fragment.
In order to run this task, you must have an existing ``.config`` file.
See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" section for
See the ":ref:`kernel-dev/common:using ``menuconfig```" section for
information on how to create a configuration file.
Here is sample output from the ``do_kernel_configcheck`` task:
@ -1440,7 +1440,7 @@ and
tasks until they produce no warnings.
For more information on how to use the ``menuconfig`` tool, see the
:ref:`kernel-dev/common:using \`\`menuconfig\`\`` section.
:ref:`kernel-dev/common:using ``menuconfig``` section.
Fine-Tuning the Kernel Configuration File
-----------------------------------------

View File

@ -122,7 +122,7 @@ general information and references for further information.
Using ``devtool`` and the eSDK requires that you have a clean build
of the image and that you are set up with the appropriate eSDK. For
more information, see the
":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
section.
Using traditional kernel development requires that you have the

View File

@ -983,7 +983,7 @@ package.
For more information on the ``oe-pkgdata-util`` utility, see the section
:ref:`dev-manual/debugging:Viewing Package Information with
\`\`oe-pkgdata-util\`\`` of the Yocto Project Development Tasks Manual.
``oe-pkgdata-util``` of the Yocto Project Development Tasks Manual.
To add a custom package variant of the ``${PN}`` recipe named
``${PN}-extra`` (name is arbitrary), one can add it to the

View File

@ -432,7 +432,7 @@ You can read more on the ``devtool upgrade`` workflow in the
":ref:`sdk-manual/extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual. You can also see an example of
how to use ``devtool upgrade`` in the ":ref:`dev-manual/upgrading-recipes:using \`\`devtool upgrade\`\``"
how to use ``devtool upgrade`` in the ":ref:`dev-manual/upgrading-recipes:using ``devtool upgrade```"
section in the Yocto Project Development Tasks Manual.
.. _devtool-resetting-a-recipe:

View File

@ -498,7 +498,7 @@ generated during the :ref:`ref-tasks-packagedata` task. The files stored in this
directory contain information about each output package produced by the
OpenEmbedded build system, and are used in different ways by the build system
such as ":ref:`dev-manual/debugging:viewing package information with
\`\`oe-pkgdata-util\`\``".
``oe-pkgdata-util```".
.. _structure-build-tmp-sstate-control:

View File

@ -740,7 +740,7 @@ tool, which you then use to modify the kernel configuration.
$ bitbake linux-yocto -c menuconfig
See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
See the ":ref:`kernel-dev/common:using ``menuconfig```"
section in the Yocto Project Linux Kernel Development Manual for more
information on this configuration tool.
@ -764,7 +764,7 @@ which can then be applied by subsequent tasks such as
Runs ``make menuconfig`` for the kernel. For information on
``menuconfig``, see the
":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
":ref:`kernel-dev/common:using ``menuconfig```"
section in the Yocto Project Linux Kernel Development Manual.
.. _ref-tasks-savedefconfig:

View File

@ -63,7 +63,7 @@ universal, the list includes them just in case:
This term refers to the area used by the OpenEmbedded build system for
builds. The area is created when you ``source`` the setup environment
script that is found in the Source Directory
(i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``). The
(i.e. :ref:`ref-manual/structure:``oe-init-build-env```). The
:term:`TOPDIR` variable points to the Build Directory.
You have a lot of flexibility when creating the :term:`Build Directory`.

View File

@ -1806,7 +1806,7 @@ system and gives an overview of their function and contents.
``${TMPDIR}/deploy``.
For more information on the structure of the Build Directory, see
":ref:`ref-manual/structure:the build directory --- \`\`build/\`\``" section.
":ref:`ref-manual/structure:the build directory --- ``build/```" section.
For more detail on the contents of the ``deploy`` directory, see the
":ref:`overview-manual/concepts:images`",
":ref:`overview-manual/concepts:package feeds`", and
@ -1850,7 +1850,7 @@ system and gives an overview of their function and contents.
<ref-classes-image>` class.
For more information on the structure of the Build Directory, see
":ref:`ref-manual/structure:the build directory --- \`\`build/\`\``" section.
":ref:`ref-manual/structure:the build directory --- ``build/```" section.
For more detail on the contents of the ``deploy`` directory, see the
":ref:`overview-manual/concepts:images`" and
":ref:`overview-manual/concepts:application development sdk`" sections both in
@ -6099,7 +6099,7 @@ system and gives an overview of their function and contents.
For examples of how this data is used, see the
":ref:`overview-manual/concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual and the
":ref:`dev-manual/debugging:viewing package information with \`\`oe-pkgdata-util\`\``"
":ref:`dev-manual/debugging:viewing package information with ``oe-pkgdata-util```"
section in the Yocto Project Development Tasks Manual. For more
information on the shared, global-state directory, see
:term:`STAGING_DIR_HOST`.

View File

@ -548,7 +548,7 @@ database.
You need to run the ``buildslist`` command first to identify existing
builds in the database before using the
:ref:`toaster-manual/reference:\`\`builddelete\`\`` command. Here is an
:ref:`toaster-manual/reference:``builddelete``` command. Here is an
example that assumes default repository and build directory names:
.. code-block:: shell
@ -557,7 +557,7 @@ example that assumes default repository and build directory names:
$ python ../bitbake/lib/toaster/manage.py buildslist
If your Toaster database had only one build, the above
:ref:`toaster-manual/reference:\`\`buildslist\`\``
:ref:`toaster-manual/reference:``buildslist```
command would return something like the following::
1: qemux86 poky core-image-minimal
@ -578,7 +578,7 @@ the database.
Prior to running the ``builddelete`` command, you need to get the ID
associated with builds by using the
:ref:`toaster-manual/reference:\`\`buildslist\`\`` command.
:ref:`toaster-manual/reference:``buildslist``` command.
``perf``
--------