diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst index d7e8c6c51b..392d9638aa 100644 --- a/documentation/brief-yoctoprojectqs/index.rst +++ b/documentation/brief-yoctoprojectqs/index.rst @@ -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. diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst index b5f00d617e..47e4193f38 100644 --- a/documentation/bsp-guide/bsp.rst +++ b/documentation/bsp-guide/bsp.rst @@ -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. :: diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index 74f5772554..5a3fb11170 100644 --- a/documentation/dev-manual/debugging.rst +++ b/documentation/dev-manual/debugging.rst @@ -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. diff --git a/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst index be52610621..b7385c2ec3 100644 --- a/documentation/dev-manual/new-recipe.rst +++ b/documentation/dev-manual/new-recipe.rst @@ -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. diff --git a/documentation/dev-manual/upgrading-recipes.rst b/documentation/dev-manual/upgrading-recipes.rst index 4fac78bdfb..a38fd7837c 100644 --- a/documentation/dev-manual/upgrading-recipes.rst +++ b/documentation/dev-manual/upgrading-recipes.rst @@ -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:: diff --git a/documentation/dev-manual/wic.rst b/documentation/dev-manual/wic.rst index 049996c39e..6ff018f07f 100644 --- a/documentation/dev-manual/wic.rst +++ b/documentation/dev-manual/wic.rst @@ -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 diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst index 815695652b..83fe98bf05 100644 --- a/documentation/kernel-dev/common.rst +++ b/documentation/kernel-dev/common.rst @@ -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 ----------------------------------------- diff --git a/documentation/kernel-dev/intro.rst b/documentation/kernel-dev/intro.rst index cc879db887..fea876cbe1 100644 --- a/documentation/kernel-dev/intro.rst +++ b/documentation/kernel-dev/intro.rst @@ -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 diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst index c7e062bdfb..22ec460014 100644 --- a/documentation/overview-manual/concepts.rst +++ b/documentation/overview-manual/concepts.rst @@ -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 diff --git a/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst index ccf4ab3d13..56070b6218 100644 --- a/documentation/ref-manual/devtool-reference.rst +++ b/documentation/ref-manual/devtool-reference.rst @@ -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: diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst index 4cf23544db..1bb35da5dc 100644 --- a/documentation/ref-manual/structure.rst +++ b/documentation/ref-manual/structure.rst @@ -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: diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst index c69fbaa518..563ed0586f 100644 --- a/documentation/ref-manual/tasks.rst +++ b/documentation/ref-manual/tasks.rst @@ -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: diff --git a/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst index 89cbc8ac68..b9cf063ca1 100644 --- a/documentation/ref-manual/terms.rst +++ b/documentation/ref-manual/terms.rst @@ -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`. diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index 019285f360..4610add7ea 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst @@ -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. ` 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`. diff --git a/documentation/toaster-manual/reference.rst b/documentation/toaster-manual/reference.rst index 927699d2a8..78e0767f58 100644 --- a/documentation/toaster-manual/reference.rst +++ b/documentation/toaster-manual/reference.rst @@ -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`` --------