summaryrefslogtreecommitdiffstats
path: root/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
diff options
context:
space:
mode:
authorQuentin Schulz <quentin.schulz@theobroma-systems.com>2021-07-26 17:33:57 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2021-07-26 23:05:05 +0100
commit7ade8346b3a09983257589d22aaada47e0eec010 (patch)
tree634932b452d7c2a090dc67d5fa945561ddc83c3a /bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
parent3b6742685ba313bbe6c7c05cb1542041ebdcbf16 (diff)
downloadpoky-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.rst20
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
54The ``SRC_URI`` and ``WORKDIR`` variables are not hardcoded into the 54The :term:`SRC_URI` and ``WORKDIR`` variables are not hardcoded into the
55fetcher, since those fetcher methods can be (and are) called with 55fetcher, since those fetcher methods can be (and are) called with
56different variable names. In OpenEmbedded for example, the shared state 56different 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
72For each URL passed to the fetcher, the fetcher calls the submodule that 72For each URL passed to the fetcher, the fetcher calls the submodule that
73handles that particular URL type. This behavior can be the source of 73handles that particular URL type. This behavior can be the source of
74some confusion when you are providing URLs for the ``SRC_URI`` variable. 74some confusion when you are providing URLs for the :term:`SRC_URI` variable.
75Consider the following two URLs:: 75Consider 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.
110File integrity is of key importance for reproducing builds. For 110File integrity is of key importance for reproducing builds. For
111non-local archive downloads, the fetcher code can verify SHA-256 and MD5 111non-local archive downloads, the fetcher code can verify SHA-256 and MD5
112checksums to ensure the archives have been downloaded correctly. You can 112checksums to ensure the archives have been downloaded correctly. You can
113specify these checksums by using the ``SRC_URI`` variable with the 113specify these checksums by using the :term:`SRC_URI` variable with the
114appropriate varflags as follows:: 114appropriate 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
119You can also specify the checksums as 119You can also specify the checksums as
120parameters on the ``SRC_URI`` as shown below:: 120parameters 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
131After a file has been downloaded and 131After a file has been downloaded and
132has had its checksum checked, a ".done" stamp is placed in ``DL_DIR``. 132has had its checksum checked, a ".done" stamp is placed in :term:`DL_DIR`.
133BitBake uses this stamp during subsequent builds to avoid downloading or 133BitBake uses this stamp during subsequent builds to avoid downloading or
134comparing a checksum for the file again. 134comparing 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
487The fetcher uses the ``rcleartool`` or 487The 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
490Following are options for the ``SRC_URI`` statement: 490Following 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
549you choose not to use ``P4CONFIG``, or to explicitly set variables that 549you 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
551the server's URL and port number, and you can specify a username and 551the server's URL and port number, and you can specify a username and
552password directly in your recipe within ``SRC_URI``. 552password directly in your recipe within :term:`SRC_URI`.
553 553
554Here is an example that relies on ``P4CONFIG`` to specify the server URL 554Here is an example that relies on ``P4CONFIG`` to specify the server URL
555and port, username, and password, and fetches the Head Revision:: 555and port, username, and password, and fetches the Head Revision::
@@ -680,4 +680,4 @@ submodules. However, you might find the code helpful and readable.
680Auto Revisions 680Auto Revisions
681============== 681==============
682 682
683We need to document ``AUTOREV`` and ``SRCREV_FORMAT`` here. 683We need to document ``AUTOREV`` and :term:`SRCREV_FORMAT` here.