From 7d3f57cfd2e4322bcd96d67d330124f221a9aedd Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Thu, 27 May 2021 20:41:17 +0200 Subject: docs: replace ``FOO`` by :term:`FOO` where possible 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 Reviewed-by: Michael Opdenacker Reviewed-by: Nicolas Dechesne Signed-off-by: Richard Purdie --- documentation/kernel-dev/common.rst | 52 ++++++++++++++++++------------------- 1 file changed, 26 insertions(+), 26 deletions(-) (limited to 'documentation/kernel-dev/common.rst') diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst index f64cbab56c..de62df5b1f 100644 --- a/documentation/kernel-dev/common.rst +++ b/documentation/kernel-dev/common.rst @@ -70,7 +70,7 @@ section: :term:`MACHINE` variable is set to "qemux86-64", which is fine if you are building for the QEMU emulator in 64-bit mode. However, if you are not, you need to set the - ``MACHINE`` variable appropriately in your ``conf/local.conf`` file + :term:`MACHINE` variable appropriately in your ``conf/local.conf`` file found in the :term:`Build Directory` (i.e. ``poky/build`` in this example). @@ -248,7 +248,7 @@ section: :term:`MACHINE` variable is set to "qemux86-64", which is fine if you are building for the QEMU emulator in 64-bit mode. However, if you are not, you need to set the - ``MACHINE`` variable appropriately in your ``conf/local.conf`` file + :term:`MACHINE` variable appropriately in your ``conf/local.conf`` file found in the :term:`Build Directory` (i.e. ``poky/build`` in this example). @@ -474,7 +474,7 @@ variable as follows:: The path ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}`` expands to "linux-yocto" in the current directory for this example. If you add any new files that modify the kernel recipe and you have -extended ``FILESPATH`` as described above, you must place the files in +extended :term:`FILESPATH` as described above, you must place the files in your layer in the following area:: your-layer/recipes-kernel/linux/linux-yocto/ @@ -553,7 +553,7 @@ the append file. For example, suppose you had some configuration options in a file called ``network_configs.cfg``. You can place that file inside a directory -named ``linux-yocto`` and then add a ``SRC_URI`` statement such as the +named ``linux-yocto`` and then add a :term:`SRC_URI` statement such as the following to the append file. When the OpenEmbedded build system builds the kernel, the configuration options are picked up and applied. :: @@ -563,7 +563,7 @@ the kernel, the configuration options are picked up and applied. To group related configurations into multiple files, you perform a similar procedure. Here is an example that groups separate configurations specifically for Ethernet and graphics into their own -files and adds the configurations by using a ``SRC_URI`` statement like +files and adds the configurations by using a :term:`SRC_URI` statement like the following in your append file:: SRC_URI += "file://myconfig.cfg \ @@ -643,7 +643,7 @@ following lines to the linux-yocto ``.bbappend`` file in your layer:: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI += "file://defconfig" -The ``SRC_URI`` tells the build system how to search +The :term:`SRC_URI` tells the build system how to search for the file, while the :term:`FILESEXTRAPATHS` extends the :term:`FILESPATH` @@ -684,7 +684,7 @@ with the following content (without indentation):: CONFIG_SERIAL_CORE_CONSOLE=y Next, include this -configuration fragment and extend the ``FILESPATH`` variable in your +configuration fragment and extend the :term:`FILESPATH` variable in your ``.bbappend`` file:: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" @@ -722,7 +722,7 @@ form:: KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file" Here is an example -that assigns the ``KBUILD_DEFCONFIG`` variable based on "raspberrypi2" +that assigns the :term:`KBUILD_DEFCONFIG` variable based on "raspberrypi2" and provides the path to the "in-tree" ``defconfig`` file to be used for a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset:: @@ -734,7 +734,7 @@ Aside from modifying your kernel recipe and providing your own a kernel's ``linux-``\ `machine`\ ``.inc`` file). In other words, if the build system detects a statement that identifies an "out-of-tree" ``defconfig`` file, that statement will override your -``KBUILD_DEFCONFIG`` variable. +:term:`KBUILD_DEFCONFIG` variable. See the :term:`KBUILD_DEFCONFIG` @@ -1349,10 +1349,10 @@ be picked up and applied when the kernel is built:: SRC_URI += "file://myconfig.cfg" As mentioned earlier, you can group related configurations into multiple -files and name them all in the ``SRC_URI`` statement as well. For +files and name them all in the :term:`SRC_URI` statement as well. For example, you could group separate configurations specifically for Ethernet and graphics into their own files and add those by using a -``SRC_URI`` statement like the following in your append file:: +:term:`SRC_URI` statement like the following in your append file:: SRC_URI += "file://myconfig.cfg \ file://eth.cfg \ @@ -1628,11 +1628,11 @@ Here are some basic steps you can use to work with your own sources: appropriate for your project: - :term:`SRC_URI`: The - ``SRC_URI`` should specify a Git repository that uses one of the + :term:`SRC_URI` should specify a Git repository that uses one of the supported Git fetcher protocols (i.e. ``file``, ``git``, ``http``, - and so forth). The ``SRC_URI`` variable should also specify either + and so forth). The :term:`SRC_URI` variable should also specify either a ``defconfig`` file or some configuration fragment files. The - skeleton recipe provides an example ``SRC_URI`` as a syntax + skeleton recipe provides an example :term:`SRC_URI` as a syntax reference. - :term:`LINUX_VERSION`: @@ -1650,16 +1650,16 @@ Here are some basic steps you can use to work with your own sources: indicate to the OpenEmbedded build system that the recipe has changed. - - :term:`PV`: The default ``PV`` + - :term:`PV`: The default :term:`PV` assignment is typically adequate. It combines the - ``LINUX_VERSION`` with the Source Control Manager (SCM) revision + :term:`LINUX_VERSION` with the Source Control Manager (SCM) revision as derived from the :term:`SRCPV` variable. The combined results are a string with the following form:: 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2 - While lengthy, the extra verbosity in ``PV`` helps ensure you are + While lengthy, the extra verbosity in :term:`PV` helps ensure you are using the exact sources from which you intend to build. - :term:`COMPATIBLE_MACHINE`: @@ -1773,7 +1773,7 @@ information to build modules. If your module ``Makefile`` uses a different variable, you might want to override the :ref:`ref-tasks-compile` step, or create a patch to the ``Makefile`` to work with the more typical -``KERNEL_SRC`` or ``KERNEL_PATH`` variables. +:term:`KERNEL_SRC` or :term:`KERNEL_PATH` variables. After you have prepared your recipe, you will likely want to include the module in your images. To do this, see the documentation for the @@ -1886,23 +1886,23 @@ build stops. Kernel features are the last elements processed for configuring and patching the kernel. Therefore, adding features in this manner is a way to enforce specific features are present and enabled without needing to do a full audit of any other layer's additions to the -``SRC_URI`` statement. +:term:`SRC_URI` statement. You add a kernel feature by providing the feature as part of the -``KERNEL_FEATURES`` variable and by providing the path to the feature's +:term:`KERNEL_FEATURES` variable and by providing the path to the feature's ``.scc`` file, which is relative to the root of the kernel Metadata. The OpenEmbedded build system searches all forms of kernel Metadata on the -``SRC_URI`` statement regardless of whether the Metadata is in the +:term:`SRC_URI` statement regardless of whether the Metadata is in the "kernel-cache", system kernel Metadata, or a recipe-space Metadata (i.e. part of the kernel recipe). See the ":ref:`kernel-dev/advanced:kernel metadata location`" section for additional information. -When you specify the feature's ``.scc`` file on the ``SRC_URI`` +When you specify the feature's ``.scc`` file on the :term:`SRC_URI` statement, the OpenEmbedded build system adds the directory of that ``.scc`` file along with all its subdirectories to the kernel feature search path. Because subdirectories are searched, you can reference a -single ``.scc`` file in the ``SRC_URI`` statement to reference multiple +single ``.scc`` file in the :term:`SRC_URI` statement to reference multiple kernel features. Consider the following example that adds the "test.scc" feature to the @@ -1910,7 +1910,7 @@ build. 1. *Create the Feature File:* Create a ``.scc`` file and locate it just as you would any other patch file, ``.cfg`` file, or fetcher item you - specify in the ``SRC_URI`` statement. + specify in the :term:`SRC_URI` statement. .. note:: @@ -1937,7 +1937,7 @@ build. a similarly named configuration fragment file ``test.cfg``. 2. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the - recipe's ``SRC_URI`` statement:: + recipe's :term:`SRC_URI` statement:: SRC_URI_append = " file://test.scc" @@ -1945,7 +1945,7 @@ build. appended to the existing path. 3. *Specify the Feature as a Kernel Feature:* Use the - ``KERNEL_FEATURES`` statement to specify the feature as a kernel + :term:`KERNEL_FEATURES` statement to specify the feature as a kernel feature:: KERNEL_FEATURES_append = " test.scc" -- cgit v1.2.3-54-g00ecf