diff options
author | Quentin Schulz <quentin.schulz@theobroma-systems.com> | 2021-07-26 17:33:57 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-07-26 23:05:05 +0100 |
commit | 7ade8346b3a09983257589d22aaada47e0eec010 (patch) | |
tree | 634932b452d7c2a090dc67d5fa945561ddc83c3a /bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst | |
parent | 3b6742685ba313bbe6c7c05cb1542041ebdcbf16 (diff) | |
download | poky-7ade8346b3a09983257589d22aaada47e0eec010.tar.gz |
bitbake: doc: bitbake-user-manual: 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.
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 which can be
gotten from doc/_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.
(Bitbake rev: aba88f40c47133ed9bc999e0298aca3bc8490912)
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst')
-rw-r--r-- | bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst index bd1fb4fc74..593de61f24 100644 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst +++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst | |||
@@ -51,7 +51,7 @@ This code unpacks the downloaded files to the specified by ``WORKDIR``. | |||
51 | examine the OpenEmbedded class file ``base.bbclass`` | 51 | examine the OpenEmbedded class file ``base.bbclass`` |
52 | . | 52 | . |
53 | 53 | ||
54 | The ``SRC_URI`` and ``WORKDIR`` variables are not hardcoded into the | 54 | The :term:`SRC_URI` and ``WORKDIR`` variables are not hardcoded into the |
55 | fetcher, since those fetcher methods can be (and are) called with | 55 | fetcher, since those fetcher methods can be (and are) called with |
56 | different variable names. In OpenEmbedded for example, the shared state | 56 | different variable names. In OpenEmbedded for example, the shared state |
57 | (sstate) code uses the fetch module to fetch the sstate files. | 57 | (sstate) code uses the fetch module to fetch the sstate files. |
@@ -64,14 +64,14 @@ URLs by looking for source files in a specific search order: | |||
64 | :term:`PREMIRRORS` variable. | 64 | :term:`PREMIRRORS` variable. |
65 | 65 | ||
66 | - *Source URI:* If pre-mirrors fail, BitBake uses the original URL (e.g | 66 | - *Source URI:* If pre-mirrors fail, BitBake uses the original URL (e.g |
67 | from ``SRC_URI``). | 67 | from :term:`SRC_URI`). |
68 | 68 | ||
69 | - *Mirror Sites:* If fetch failures occur, BitBake next uses mirror | 69 | - *Mirror Sites:* If fetch failures occur, BitBake next uses mirror |
70 | locations as defined by the :term:`MIRRORS` variable. | 70 | locations as defined by the :term:`MIRRORS` variable. |
71 | 71 | ||
72 | For each URL passed to the fetcher, the fetcher calls the submodule that | 72 | For each URL passed to the fetcher, the fetcher calls the submodule that |
73 | handles that particular URL type. This behavior can be the source of | 73 | handles that particular URL type. This behavior can be the source of |
74 | some confusion when you are providing URLs for the ``SRC_URI`` variable. | 74 | some confusion when you are providing URLs for the :term:`SRC_URI` variable. |
75 | Consider the following two URLs:: | 75 | Consider the following two URLs:: |
76 | 76 | ||
77 | http://git.yoctoproject.org/git/poky;protocol=git | 77 | http://git.yoctoproject.org/git/poky;protocol=git |
@@ -110,14 +110,14 @@ which is specified by the :term:`DL_DIR` variable. | |||
110 | File integrity is of key importance for reproducing builds. For | 110 | File integrity is of key importance for reproducing builds. For |
111 | non-local archive downloads, the fetcher code can verify SHA-256 and MD5 | 111 | non-local archive downloads, the fetcher code can verify SHA-256 and MD5 |
112 | checksums to ensure the archives have been downloaded correctly. You can | 112 | checksums to ensure the archives have been downloaded correctly. You can |
113 | specify these checksums by using the ``SRC_URI`` variable with the | 113 | specify these checksums by using the :term:`SRC_URI` variable with the |
114 | appropriate varflags as follows:: | 114 | appropriate varflags as follows:: |
115 | 115 | ||
116 | SRC_URI[md5sum] = "value" | 116 | SRC_URI[md5sum] = "value" |
117 | SRC_URI[sha256sum] = "value" | 117 | SRC_URI[sha256sum] = "value" |
118 | 118 | ||
119 | You can also specify the checksums as | 119 | You can also specify the checksums as |
120 | parameters on the ``SRC_URI`` as shown below:: | 120 | parameters on the :term:`SRC_URI` as shown below:: |
121 | 121 | ||
122 | SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d" | 122 | SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d" |
123 | 123 | ||
@@ -129,7 +129,7 @@ shows how you name the URIs:: | |||
129 | SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d | 129 | SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d |
130 | 130 | ||
131 | After a file has been downloaded and | 131 | After a file has been downloaded and |
132 | has had its checksum checked, a ".done" stamp is placed in ``DL_DIR``. | 132 | has had its checksum checked, a ".done" stamp is placed in :term:`DL_DIR`. |
133 | BitBake uses this stamp during subsequent builds to avoid downloading or | 133 | BitBake uses this stamp during subsequent builds to avoid downloading or |
134 | comparing a checksum for the file again. | 134 | comparing a checksum for the file again. |
135 | 135 | ||
@@ -438,7 +438,7 @@ Here are some example URLs:: | |||
438 | .. note:: | 438 | .. note:: |
439 | 439 | ||
440 | Specifying passwords directly in ``git://`` urls is not supported. | 440 | Specifying passwords directly in ``git://`` urls is not supported. |
441 | There are several reasons: ``SRC_URI`` is often written out to logs and | 441 | There are several reasons: :term:`SRC_URI` is often written out to logs and |
442 | other places, and that could easily leak passwords; it is also all too | 442 | other places, and that could easily leak passwords; it is also all too |
443 | easy to share metadata without removing passwords. SSH keys, ``~/.netrc`` | 443 | easy to share metadata without removing passwords. SSH keys, ``~/.netrc`` |
444 | and ``~/.ssh/config`` files can be used as alternatives. | 444 | and ``~/.ssh/config`` files can be used as alternatives. |
@@ -487,7 +487,7 @@ To use this fetcher, make sure your recipe has proper | |||
487 | The fetcher uses the ``rcleartool`` or | 487 | The fetcher uses the ``rcleartool`` or |
488 | ``cleartool`` remote client, depending on which one is available. | 488 | ``cleartool`` remote client, depending on which one is available. |
489 | 489 | ||
490 | Following are options for the ``SRC_URI`` statement: | 490 | Following are options for the :term:`SRC_URI` statement: |
491 | 491 | ||
492 | - *vob*: The name, which must include the prepending "/" character, | 492 | - *vob*: The name, which must include the prepending "/" character, |
493 | of the ClearCase VOB. This option is required. | 493 | of the ClearCase VOB. This option is required. |
@@ -549,7 +549,7 @@ password if you do not wish to keep those values in a recipe itself. If | |||
549 | you choose not to use ``P4CONFIG``, or to explicitly set variables that | 549 | you choose not to use ``P4CONFIG``, or to explicitly set variables that |
550 | ``P4CONFIG`` can contain, you can specify the ``P4PORT`` value, which is | 550 | ``P4CONFIG`` can contain, you can specify the ``P4PORT`` value, which is |
551 | the server's URL and port number, and you can specify a username and | 551 | the server's URL and port number, and you can specify a username and |
552 | password directly in your recipe within ``SRC_URI``. | 552 | password directly in your recipe within :term:`SRC_URI`. |
553 | 553 | ||
554 | Here is an example that relies on ``P4CONFIG`` to specify the server URL | 554 | Here is an example that relies on ``P4CONFIG`` to specify the server URL |
555 | and port, username, and password, and fetches the Head Revision:: | 555 | and port, username, and password, and fetches the Head Revision:: |
@@ -680,4 +680,4 @@ submodules. However, you might find the code helpful and readable. | |||
680 | Auto Revisions | 680 | Auto Revisions |
681 | ============== | 681 | ============== |
682 | 682 | ||
683 | We need to document ``AUTOREV`` and ``SRCREV_FORMAT`` here. | 683 | We need to document ``AUTOREV`` and :term:`SRCREV_FORMAT` here. |