1
0
mirror of https://git.yoctoproject.org/poky synced 2026-05-08 17:19:20 +00:00

docs: replace remaining `FOO by :term:FOO`

A few occurences appeared between the time the original patch was sent
and it was applied, this fixes it.

Also, the original patch didn't take into account lowercase terms, this
is now fixed, see module_autoload for example.

Finally, as is often the case with regexp, there was a typo in it that
didn't make it match as much as it should have.

The script that is used to do the replacement of ``FOO`` by :term:`FOO`
is the following Python code:

import re
from pathlib import Path
from runpy import run_module
import contextlib
import io
import sys

re_term = re.compile(r'variables.html#term-([a-zA-Z_0-9]*)')
terms = []
new_terms = set()

with contextlib.redirect_stdout(io.StringIO()) as f:
    run_module('sphinx.ext.intersphinx', run_name='__main__')

objects = f.getvalue()

match = re_term.search(objects)
while match:
    if match.group(1):
        terms.append(match.group(1))
    match = re_term.search(objects, match.end())

for rst in Path('.').rglob('*.rst'):
    with open(rst, 'r') as f:
        content = "".join(f.readlines())
    for term in terms:
        content = re.sub(r'``({})``(?!.*\s+[~=-]{{{:d},}})'.format(term, len(term)), r':term:`\1`', content)

    with open(rst, 'w') as f:
        f.write(content)

This script takes one argument as input: an objects.inv. Bitbake's can
be gotten from https://docs.yoctoproject.org/bitbake/objects.inv. The
objetcs.inv from the current git repo can be gotten from
documentation/_build/html/objetcs.inv after running `make html`.

Note that this excludes from replacement terms that appear in section
titles as it requires refs to be changed too. This can be automated too
if need be but right now it looks a bit confusing to have an anchor link
(for sections) also have a term/reference link in it. I am not sure this
is desired today.

This is the result of two runs of the aforementioned script, once with
Bitbake objects.inv and once with this repo's.

Fixes: ba49d9babfcb "docs: replace ``FOO`` by :term:`FOO` where possible"

(From yocto-docs rev: 1e1b0c4dd241b6657035172b1f7b5f341afa8b25)

Signed-off-by: Quentin Schulz <foss@0leil.net>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Quentin Schulz
2021-06-19 09:07:35 +02:00
committed by Richard Purdie
parent be3e14dd43
commit 5a6fb291ad
19 changed files with 74 additions and 74 deletions
+12 -12
View File
@@ -268,7 +268,7 @@ following list:
quickly.
In summary, you need to place all files referenced from
``SRC_URI`` in a machine-specific subdirectory within the layer in
:term:`SRC_URI` in a machine-specific subdirectory within the layer in
order to restrict those files to machine-specific builds.
- *Perform Steps to Apply for Yocto Project Compatibility:* If you want
@@ -1305,7 +1305,7 @@ scanning directory locations for local files in :term:`SRC_URI`.
The :term:`SRC_URI` variable in your recipe must define each unique location
for your source files. It is good practice to not hard-code version
numbers in a URL used in ``SRC_URI``. Rather than hard-code these
numbers in a URL used in :term:`SRC_URI`. Rather than hard-code these
values, use ``${``\ :term:`PV`\ ``}``,
which causes the fetch process to use the version specified in the
recipe filename. Specifying the version in this manner means that
@@ -2743,7 +2743,7 @@ recognizes the machine as "crownbay".
The most important variables you must set in your machine configuration
file or include from a lower-level configuration file are as follows:
- ``TARGET_ARCH`` (e.g. "arm")
- :term:`TARGET_ARCH` (e.g. "arm")
- ``PREFERRED_PROVIDER_virtual/kernel``
@@ -2751,9 +2751,9 @@ file or include from a lower-level configuration file are as follows:
You might also need these variables:
- ``SERIAL_CONSOLES`` (e.g. "115200;ttyS0 115200;ttyS1")
- :term:`SERIAL_CONSOLES` (e.g. "115200;ttyS0 115200;ttyS1")
- ``KERNEL_IMAGETYPE`` (e.g. "zImage")
- :term:`KERNEL_IMAGETYPE` (e.g. "zImage")
- :term:`IMAGE_FSTYPES` (e.g. "tar.gz jffs2")
@@ -3277,7 +3277,7 @@ The actual directory depends on several things:
- :term:`EXTENDPE`: The epoch - (if
:term:`PE` is not specified, which is
usually the case for most recipes, then ``EXTENDPE`` is blank).
usually the case for most recipes, then :term:`EXTENDPE` is blank).
- :term:`PV`: The recipe version.
@@ -4167,7 +4167,7 @@ your tunings to best consider build times and package feed maintenance.
If :term:`DISTRO` settings change or fundamental configuration settings
such as the filesystem layout, you need to work with a clean :term:`TMPDIR`.
Sharing :term:`TMPDIR` under these circumstances might work but since it is
not guaranteed, you should use a clean ``TMPDIR``.
not guaranteed, you should use a clean :term:`TMPDIR`.
- *Enable the Appropriate Package Architecture:* By default, the
OpenEmbedded build system enables three levels of package
@@ -4392,7 +4392,7 @@ directory:
INHERIT += "own-mirrors"
BB_NO_NETWORK = "1"
The ``SOURCE_MIRROR_URL`` and ``own-mirror``
The :term:`SOURCE_MIRROR_URL` and ``own-mirror``
class set up the system to use the downloads directory as your "own
mirror". Using the :term:`BB_NO_NETWORK` variable makes sure that
BitBake's fetching process in step 3 stays local, which means files
@@ -4676,7 +4676,7 @@ needed.
For the most part, the Multilib class extension works automatically to
extend the package name from ``${PN}`` to ``${MLPREFIX}${PN}``, where
``MLPREFIX`` is the particular multilib (e.g. "lib32-" or "lib64-").
:term:`MLPREFIX` is the particular multilib (e.g. "lib32-" or "lib64-").
Standard variables such as
:term:`DEPENDS`,
:term:`RDEPENDS`,
@@ -6258,7 +6258,7 @@ the following:
software being packaged. Do not confuse :term:`PV` with the binary
package version.
- ``PR``: The recipe revision.
- :term:`PR`: The recipe revision.
- :term:`SRCPV`: The OpenEmbedded
build system uses this string to help define the value of :term:`PV` when
@@ -7946,8 +7946,8 @@ output from this command::
Here are some notes on using the ``buildhistory-collect-srcrevs`` command:
- By default, only values where the :term:`SRCREV` was not hardcoded
(usually when ``AUTOREV`` is used) are reported. Use the ``-a``
option to see all ``SRCREV`` values.
(usually when :term:`AUTOREV` is used) are reported. Use the ``-a``
option to see all :term:`SRCREV` values.
- The output statements might not have any effect if overrides are
applied elsewhere in the build system configuration. Use the