mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-09-16 00:49:32 +02:00
Code Issues Packages Projects Releases Wiki Activity

bitbake: doc: bitbake-user-manual: replace `FOO by :term:FOO` where possible

Browse Source 
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>
This commit is contained in:
Quentin Schulz
2021-07-26 17:33:57 +02:00
committed by Richard Purdie
parent 3b6742685b
commit 7ade8346b3
6 changed files with 151 additions and 151 deletions
Download Patch File Download Diff File Expand all files Collapse all files

148
bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
View File

@@ -31,7 +31,7 @@ overview of their function and contents.
attempt to build. Instead, BitBake assumes these recipes have already
been built.
In OpenEmbedded-Core, ``ASSUME_PROVIDED`` mostly specifies native
In OpenEmbedded-Core, :term:`ASSUME_PROVIDED` mostly specifies native
tools that should not be built. An example is ``git-native``, which
when specified allows for the Git binary from the host to be used
rather than building ``git-native``.
@@ -84,14 +84,14 @@ overview of their function and contents.
- Attempts to access networks not in the host list cause a failure.
Using ``BB_ALLOWED_NETWORKS`` in conjunction with
Using :term:`BB_ALLOWED_NETWORKS` in conjunction with
:term:`PREMIRRORS` is very useful. Adding the
host you want to use to ``PREMIRRORS`` results in the source code
host you want to use to :term:`PREMIRRORS` results in the source code
being fetched from an allowed location and avoids raising an error
when a host that is not allowed is in a
:term:`SRC_URI` statement. This is because the
fetcher does not attempt to use the host listed in ``SRC_URI`` after
a successful fetch from the ``PREMIRRORS`` occurs.
fetcher does not attempt to use the host listed in :term:`SRC_URI` after
a successful fetch from the :term:`PREMIRRORS` occurs.
:term:`BB_CONSOLELOG`
Specifies the path to a log file into which BitBake's user interface
@@ -178,7 +178,7 @@ overview of their function and contents.
issues a warning when the disk space in the ``${SSTATE_DIR}``
directory drops below 1 Gbyte or the number of free inodes drops
below 100 Kbytes. Subsequent warnings are issued during intervals as
defined by the ``BB_DISKMON_WARNINTERVAL`` variable.
defined by the :term:`BB_DISKMON_WARNINTERVAL` variable.
The second example stops the build after all currently executing
tasks complete when the minimum disk space in the ``${TMPDIR}``
@@ -192,14 +192,14 @@ overview of their function and contents.
:term:`BB_DISKMON_WARNINTERVAL`
Defines the disk space and free inode warning intervals.
If you are going to use the ``BB_DISKMON_WARNINTERVAL`` variable, you
If you are going to use the :term:`BB_DISKMON_WARNINTERVAL` variable, you
must also use the :term:`BB_DISKMON_DIRS`
variable and define its action as "WARN". During the build,
subsequent warnings are issued each time disk space or number of free
inodes further reduces by the respective interval.
If you do not provide a ``BB_DISKMON_WARNINTERVAL`` variable and you
do use ``BB_DISKMON_DIRS`` with the "WARN" action, the disk
If you do not provide a :term:`BB_DISKMON_WARNINTERVAL` variable and you
do use :term:`BB_DISKMON_DIRS` with the "WARN" action, the disk
monitoring interval defaults to the following:
BB_DISKMON_WARNINTERVAL = "50M,5K"
@@ -264,7 +264,7 @@ overview of their function and contents.
:term:`BB_FILENAME`
Contains the filename of the recipe that owns the currently running
task. For example, if the ``do_fetch`` task that resides in the
``my-recipe.bb`` is executing, the ``BB_FILENAME`` variable contains
``my-recipe.bb`` is executing, the :term:`BB_FILENAME` variable contains
"/foo/path/my-recipe.bb".
:term:`BB_GENERATE_MIRROR_TARBALLS`
@@ -334,7 +334,7 @@ overview of their function and contents.
:term:`BB_LOGFMT`
Specifies the name of the log files saved into
``${``\ :term:`T`\ ``}``. By default, the ``BB_LOGFMT``
``${``\ :term:`T`\ ``}``. By default, the :term:`BB_LOGFMT`
variable is undefined and the log file names get created using the
following form::
@@ -389,7 +389,7 @@ overview of their function and contents.
:term:`BB_RUNFMT`
Specifies the name of the executable script files (i.e. run files)
saved into ``${``\ :term:`T`\ ``}``. By default, the
``BB_RUNFMT`` variable is undefined and the run file names get
:term:`BB_RUNFMT` variable is undefined and the run file names get
created using the following form::
run.{task}.{pid}
@@ -455,7 +455,7 @@ overview of their function and contents.
:term:`BB_SRCREV_POLICY`
Defines the behavior of the fetcher when it interacts with source
control systems and dynamic source revisions. The
``BB_SRCREV_POLICY`` variable is useful when working without a
:term:`BB_SRCREV_POLICY` variable is useful when working without a
network.
The variable can be set using one of two policies:
@@ -499,7 +499,7 @@ overview of their function and contents.
Allows adjustment of a task's Input/Output priority. During
Autobuilder testing, random failures can occur for tasks due to I/O
starvation. These failures occur during various QEMU runtime
timeouts. You can use the ``BB_TASK_IONICE_LEVEL`` variable to adjust
timeouts. You can use the :term:`BB_TASK_IONICE_LEVEL` variable to adjust
the I/O priority of these tasks.
.. note::
@@ -573,13 +573,13 @@ overview of their function and contents.
.. note::
Internally, the ``BBCLASSEXTEND`` mechanism generates recipe
Internally, the :term:`BBCLASSEXTEND` mechanism generates recipe
variants by rewriting variable values and applying overrides such
as ``_class-native``. For example, to generate a native version of
a recipe, a :term:`DEPENDS` on "foo" is
rewritten to a ``DEPENDS`` on "foo-native".
rewritten to a :term:`DEPENDS` on "foo-native".
Even when using ``BBCLASSEXTEND``, the recipe is only parsed once.
Even when using :term:`BBCLASSEXTEND`, the recipe is only parsed once.
Parsing once adds some limitations. For example, it is not
possible to include a different file depending on the variant,
since ``include`` statements are processed when the recipe is
@@ -615,14 +615,14 @@ overview of their function and contents.
- effectively letting you control the precedence for the multiple
layers. The precedence established through this variable stands
regardless of a recipe's version (:term:`PV` variable).
For example, a layer that has a recipe with a higher ``PV`` value but
for which the ``BBFILE_PRIORITY`` is set to have a lower precedence
For example, a layer that has a recipe with a higher :term:`PV` value but
for which the :term:`BBFILE_PRIORITY` is set to have a lower precedence
still has a lower precedence.
A larger value for the ``BBFILE_PRIORITY`` variable results in a
A larger value for the :term:`BBFILE_PRIORITY` variable results in a
higher precedence. For example, the value 6 has a higher precedence
than the value 5. If not specified, the ``BBFILE_PRIORITY`` variable
is set based on layer dependencies (see the ``LAYERDEPENDS`` variable
than the value 5. If not specified, the :term:`BBFILE_PRIORITY` variable
is set based on layer dependencies (see the :term:`LAYERDEPENDS` variable
for more information. The default priority, if unspecified for a
layer with no dependencies, is the lowest defined priority + 1 (or 1
if no priorities are defined).
@@ -645,7 +645,7 @@ overview of their function and contents.
Activates content depending on presence of identified layers. You
identify the layers by the collections that the layers define.
Use the ``BBFILES_DYNAMIC`` variable to avoid ``.bbappend`` files whose
Use the :term:`BBFILES_DYNAMIC` variable to avoid ``.bbappend`` files whose
corresponding ``.bb`` file is in a layer that attempts to modify other
layers through ``.bbappend`` but does not want to introduce a hard
dependency on those other layers.
@@ -654,7 +654,7 @@ overview of their function and contents.
``.bb`` files in case a layer is not present. Use this avoid hard
dependency on those other layers.
Use the following form for ``BBFILES_DYNAMIC``::
Use the following form for :term:`BBFILES_DYNAMIC`::
collection_name:filename_pattern
@@ -691,7 +691,7 @@ overview of their function and contents.
:term:`BBINCLUDELOGS_LINES`
If :term:`BBINCLUDELOGS` is set, specifies
the maximum number of lines from the task log file to print when
reporting a failed task. If you do not set ``BBINCLUDELOGS_LINES``,
reporting a failed task. If you do not set :term:`BBINCLUDELOGS_LINES`,
the entire log is printed.
:term:`BBLAYERS`
@@ -717,7 +717,7 @@ overview of their function and contents.
:term:`BBMASK`
Prevents BitBake from processing recipes and recipe append files.
You can use the ``BBMASK`` variable to "hide" these ``.bb`` and
You can use the :term:`BBMASK` variable to "hide" these ``.bb`` and
``.bbappend`` files. BitBake ignores any recipe or recipe append
files that match any of the expressions. It is as if BitBake does not
see them at all. Consequently, matching files are not parsed or
@@ -754,7 +754,7 @@ overview of their function and contents.
Enables BitBake to perform multiple configuration builds and lists
each separate configuration (multiconfig). You can use this variable
to cause BitBake to build multiple targets where each target has a
separate configuration. Define ``BBMULTICONFIG`` in your
separate configuration. Define :term:`BBMULTICONFIG` in your
``conf/local.conf`` configuration file.
As an example, the following line specifies three multiconfigs, each
@@ -766,7 +766,7 @@ overview of their function and contents.
build directory within a directory named ``conf/multiconfig`` (e.g.
build_directory\ ``/conf/multiconfig/configA.conf``).
For information on how to use ``BBMULTICONFIG`` in an environment
For information on how to use :term:`BBMULTICONFIG` in an environment
that supports building targets with multiple configurations, see the
":ref:`bitbake-user-manual/bitbake-user-manual-intro:executing a multiple configuration build`"
section.
@@ -777,7 +777,7 @@ overview of their function and contents.
variable.
If you run BitBake from a directory outside of the build directory,
you must be sure to set ``BBPATH`` to point to the build directory.
you must be sure to set :term:`BBPATH` to point to the build directory.
Set the variable as you would any environment variable and then run
BitBake::
@@ -824,7 +824,7 @@ overview of their function and contents.
The most common usage of this is variable is to set it to "-1" within
a recipe for a development version of a piece of software. Using the
variable in this way causes the stable version of the recipe to build
by default in the absence of ``PREFERRED_VERSION`` being used to
by default in the absence of :term:`PREFERRED_VERSION` being used to
build the development version.
.. note::
@@ -837,7 +837,7 @@ overview of their function and contents.
Lists a recipe's build-time dependencies (i.e. other recipe files).
Consider this simple example for two recipes named "a" and "b" that
produce similarly named packages. In this example, the ``DEPENDS``
produce similarly named packages. In this example, the :term:`DEPENDS`
statement appears in the "a" recipe::
DEPENDS = "b"
@@ -855,7 +855,7 @@ overview of their function and contents.
:term:`DL_DIR`
The central download directory used by the build process to store
downloads. By default, ``DL_DIR`` gets files suitable for mirroring for
downloads. By default, :term:`DL_DIR` gets files suitable for mirroring for
everything except Git repositories. If you want tarballs of Git
repositories, use the :term:`BB_GENERATE_MIRROR_TARBALLS` variable.
@@ -870,14 +870,14 @@ overview of their function and contents.
.. note::
Recipes added to ``EXCLUDE_FROM_WORLD`` may still be built during a world
Recipes added to :term:`EXCLUDE_FROM_WORLD` may still be built during a world
build in order to satisfy dependencies of other recipes. Adding a
recipe to ``EXCLUDE_FROM_WORLD`` only ensures that the recipe is not
recipe to :term:`EXCLUDE_FROM_WORLD` only ensures that the recipe is not
explicitly added to the list of build targets in a world build.
:term:`FAKEROOT`
Contains the command to use when running a shell script in a fakeroot
environment. The ``FAKEROOT`` variable is obsolete and has been
environment. The :term:`FAKEROOT` variable is obsolete and has been
replaced by the other ``FAKEROOT*`` variables. See these entries in
the glossary for more information.
@@ -940,9 +940,9 @@ overview of their function and contents.
Causes the named class or classes to be inherited globally. Anonymous
functions in the class or classes are not executed for the base
configuration and in each individual recipe. The OpenEmbedded build
system ignores changes to ``INHERIT`` in individual recipes.
system ignores changes to :term:`INHERIT` in individual recipes.
For more information on ``INHERIT``, see the
For more information on :term:`INHERIT`, see the
":ref:`bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`"
section.
@@ -990,7 +990,7 @@ overview of their function and contents.
the build system searches for source code, it first tries the local
download directory. If that location fails, the build system tries
locations defined by :term:`PREMIRRORS`, the
upstream source, and then locations specified by ``MIRRORS`` in that
upstream source, and then locations specified by :term:`MIRRORS` in that
order.
:term:`MULTI_PROVIDER_WHITELIST`
@@ -1007,12 +1007,12 @@ overview of their function and contents.
``virtual/kernel``, and so forth).
:term:`OVERRIDES`
BitBake uses ``OVERRIDES`` to control what variables are overridden
BitBake uses :term:`OVERRIDES` to control what variables are overridden
after BitBake parses recipes and configuration files.
Following is a simple example that uses an overrides list based on
machine architectures: OVERRIDES = "arm:x86:mips:powerpc" You can
find information on how to use ``OVERRIDES`` in the
find information on how to use :term:`OVERRIDES` in the
":ref:`bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax
(overrides)`" section.
@@ -1026,11 +1026,11 @@ overview of their function and contents.
:term:`PACKAGES_DYNAMIC`
A promise that your recipe satisfies runtime dependencies for
optional modules that are found in other recipes.
``PACKAGES_DYNAMIC`` does not actually satisfy the dependencies, it
:term:`PACKAGES_DYNAMIC` does not actually satisfy the dependencies, it
only states that they should be satisfied. For example, if a hard,
runtime dependency (:term:`RDEPENDS`) of another
package is satisfied during the build through the
``PACKAGES_DYNAMIC`` variable, but a package with the module name is
:term:`PACKAGES_DYNAMIC` variable, but a package with the module name is
never actually produced, then the other package will be broken.
:term:`PE`
@@ -1069,8 +1069,8 @@ overview of their function and contents.
:term:`PREFERRED_PROVIDERS`
Determines which recipe should be given preference for cases where
multiple recipes provide the same item. Functionally,
``PREFERRED_PROVIDERS`` is identical to
:term:`PREFERRED_PROVIDER`. However, the ``PREFERRED_PROVIDERS`` variable
:term:`PREFERRED_PROVIDERS` is identical to
:term:`PREFERRED_PROVIDER`. However, the :term:`PREFERRED_PROVIDERS` variable
lets you define preferences for multiple situations using the following
form::
@@ -1088,7 +1088,7 @@ overview of their function and contents.
select, and you should set :term:`PV` accordingly for
precedence.
The ``PREFERRED_VERSION`` variable supports limited wildcard use
The :term:`PREFERRED_VERSION` variable supports limited wildcard use
through the "``%``" character. You can use the character to match any
number of characters, which can be useful when specifying versions
that contain long revision numbers that potentially change. Here are
@@ -1111,7 +1111,7 @@ overview of their function and contents.
Specifies additional paths from which BitBake gets source code. When
the build system searches for source code, it first tries the local
download directory. If that location fails, the build system tries
locations defined by ``PREMIRRORS``, the upstream source, and then
locations defined by :term:`PREMIRRORS`, the upstream source, and then
locations specified by :term:`MIRRORS` in that order.
Typically, you would add a specific server for the build system to
@@ -1131,25 +1131,25 @@ overview of their function and contents.
:term:`PROVIDES`
A list of aliases by which a particular recipe can be known. By
default, a recipe's own ``PN`` is implicitly already in its
``PROVIDES`` list. If a recipe uses ``PROVIDES``, the additional
default, a recipe's own :term:`PN` is implicitly already in its
:term:`PROVIDES` list. If a recipe uses :term:`PROVIDES`, the additional
aliases are synonyms for the recipe and can be useful satisfying
dependencies of other recipes during the build as specified by
``DEPENDS``.
:term:`DEPENDS`.
Consider the following example ``PROVIDES`` statement from a recipe
Consider the following example :term:`PROVIDES` statement from a recipe
file ``libav_0.8.11.bb``::
PROVIDES += "libpostproc"
The ``PROVIDES`` statement results in the "libav" recipe also being known
The :term:`PROVIDES` statement results in the "libav" recipe also being known
as "libpostproc".
In addition to providing recipes under alternate names, the
``PROVIDES`` mechanism is also used to implement virtual targets. A
:term:`PROVIDES` mechanism is also used to implement virtual targets. A
virtual target is a name that corresponds to some particular
functionality (e.g. a Linux kernel). Recipes that provide the
functionality in question list the virtual target in ``PROVIDES``.
functionality in question list the virtual target in :term:`PROVIDES`.
Recipes that depend on the functionality in question can include the
virtual target in :term:`DEPENDS` to leave the
choice of provider open.
@@ -1161,12 +1161,12 @@ overview of their function and contents.
:term:`PRSERV_HOST`
The network based :term:`PR` service host and port.
Following is an example of how the ``PRSERV_HOST`` variable is set::
Following is an example of how the :term:`PRSERV_HOST` variable is set::
PRSERV_HOST = "localhost:0"
You must set the variable if you want to automatically start a local PR
service. You can set ``PRSERV_HOST`` to other values to use a remote PR
service. You can set :term:`PRSERV_HOST` to other values to use a remote PR
service.
:term:`PV`
@@ -1178,22 +1178,22 @@ overview of their function and contents.
a package in this list cannot be found during the build, you will get
a build error.
Because the ``RDEPENDS`` variable applies to packages being built,
Because the :term:`RDEPENDS` variable applies to packages being built,
you should always use the variable in a form with an attached package
name. For example, suppose you are building a development package
that depends on the ``perl`` package. In this case, you would use the
following ``RDEPENDS`` statement::
following :term:`RDEPENDS` statement::
RDEPENDS_${PN}-dev += "perl"
In the example, the development package depends on the ``perl`` package.
Thus, the ``RDEPENDS`` variable has the ``${PN}-dev`` package name as part
Thus, the :term:`RDEPENDS` variable has the ``${PN}-dev`` package name as part
of the variable.
BitBake supports specifying versioned dependencies. Although the
syntax varies depending on the packaging format, BitBake hides these
differences from you. Here is the general syntax to specify versions
with the ``RDEPENDS`` variable::
with the :term:`RDEPENDS` variable::
RDEPENDS_${PN} = "package (operator version)"
@@ -1219,19 +1219,19 @@ overview of their function and contents.
:term:`REQUIRED_VERSION`
If there are multiple versions of a recipe available, this variable
determines which version should be given preference. ``REQUIRED_VERSION``
determines which version should be given preference. :term:`REQUIRED_VERSION`
works in exactly the same manner as :term:`PREFERRED_VERSION`, except
that if the specified version is not available then an error message
is shown and the build fails immediately.
If both ``REQUIRED_VERSION`` and ``PREFERRED_VERSION`` are set for
the same recipe, the ``REQUIRED_VERSION`` value applies.
If both :term:`REQUIRED_VERSION` and :term:`PREFERRED_VERSION` are set for
the same recipe, the :term:`REQUIRED_VERSION` value applies.
:term:`RPROVIDES`
A list of package name aliases that a package also provides. These
aliases are useful for satisfying runtime dependencies of other
packages both during the build and on the target (as specified by
``RDEPENDS``).
:term:`RDEPENDS`).
As with all package-controlling variables, you must always use the
variable in conjunction with a package name override. Here is an
@@ -1244,12 +1244,12 @@ overview of their function and contents.
built. The package being built does not depend on this list of
packages in order to successfully build, but needs them for the
extended usability. To specify runtime dependencies for packages, see
the ``RDEPENDS`` variable.
the :term:`RDEPENDS` variable.
BitBake supports specifying versioned recommends. Although the syntax
varies depending on the packaging format, BitBake hides these
differences from you. Here is the general syntax to specify versions
with the ``RRECOMMENDS`` variable::
with the :term:`RRECOMMENDS` variable::
RRECOMMENDS_${PN} = "package (operator version)"
@@ -1273,10 +1273,10 @@ overview of their function and contents.
The list of source files - local or remote. This variable tells
BitBake which bits to pull for the build and how to pull them. For
example, if the recipe or append file needs to fetch a single tarball
from the Internet, the recipe or append file uses a ``SRC_URI`` entry
from the Internet, the recipe or append file uses a :term:`SRC_URI` entry
that specifies that tarball. On the other hand, if the recipe or
append file needs to fetch a tarball and include a custom file, the
recipe or append file needs an ``SRC_URI`` variable that specifies
recipe or append file needs an :term:`SRC_URI` variable that specifies
all those sources.
The following list explains the available URI protocols:
@@ -1329,8 +1329,8 @@ overview of their function and contents.
subdirectory within the archive.
- ``name`` : Specifies a name to be used for association with
``SRC_URI`` checksums when you have more than one file specified
in ``SRC_URI``.
:term:`SRC_URI` checksums when you have more than one file specified
in :term:`SRC_URI`.
- ``downloadfilename`` : Specifies the filename used when storing
the downloaded file.
@@ -1345,7 +1345,7 @@ overview of their function and contents.
variable applies only when using Subversion, Git, Mercurial and
Bazaar. If you want to build a fixed revision and you want to avoid
performing a query on the remote repository every time BitBake parses
your recipe, you should specify a ``SRCREV`` that is a full revision
your recipe, you should specify a :term:`SRCREV` that is a full revision
identifier and not just a tag.
:term:`SRCREV_FORMAT`
@@ -1354,10 +1354,10 @@ overview of their function and contents.
:term:`SRC_URI`.
The system needs help constructing these values under these
circumstances. Each component in the ``SRC_URI`` is assigned a name
and these are referenced in the ``SRCREV_FORMAT`` variable. Consider
circumstances. Each component in the :term:`SRC_URI` is assigned a name
and these are referenced in the :term:`SRCREV_FORMAT` variable. Consider
an example with URLs named "machine" and "meta". In this case,
``SRCREV_FORMAT`` could look like "machine_meta" and those names
:term:`SRCREV_FORMAT` could look like "machine_meta" and those names
would have the SCM versions substituted into each position. Only one
``AUTOINC`` placeholder is added and if needed. And, this placeholder
is placed at the start of the returned string.
@@ -1369,7 +1369,7 @@ overview of their function and contents.
:term:`STAMPCLEAN`
Specifies the base path used to create recipe stamp files. Unlike the
:term:`STAMP` variable, ``STAMPCLEAN`` can contain
:term:`STAMP` variable, :term:`STAMPCLEAN` can contain
wildcards to match the range of files a clean operation should
remove. BitBake uses a clean operation to remove any other stamps it
should be removing when creating a new stamp.