diff options
author | Quentin Schulz <foss@0leil.net> | 2021-05-27 20:41:17 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-06-19 16:54:01 +0100 |
commit | 7d3f57cfd2e4322bcd96d67d330124f221a9aedd (patch) | |
tree | 5d07321b7c8bc59bb7fcc0372fab8b7a1966cf06 /documentation/ref-manual/faq.rst | |
parent | 7a9b74e9d2a5cf3b1fb3ac7565c50eae6e0d4632 (diff) | |
download | poky-7d3f57cfd2e4322bcd96d67d330124f221a9aedd.tar.gz |
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 <foss@0leil.net>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/ref-manual/faq.rst')
-rw-r--r-- | documentation/ref-manual/faq.rst | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst index f1b564a60e..640ef77d03 100644 --- a/documentation/ref-manual/faq.rst +++ b/documentation/ref-manual/faq.rst | |||
@@ -108,10 +108,10 @@ the team can place sources there so builds continue to work. | |||
108 | but the package is being marked as machine-specific in all cases, how do | 108 | but the package is being marked as machine-specific in all cases, how do |
109 | I prevent this? | 109 | I prevent this? |
110 | 110 | ||
111 | **A:** Set ``SRC_URI_OVERRIDES_PACKAGE_ARCH`` = "0" in the ``.bb`` file | 111 | **A:** Set :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` = "0" in the ``.bb`` file |
112 | but make sure the package is manually marked as machine-specific for the | 112 | but make sure the package is manually marked as machine-specific for the |
113 | case that needs it. The code that handles | 113 | case that needs it. The code that handles |
114 | ``SRC_URI_OVERRIDES_PACKAGE_ARCH`` is in the | 114 | :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` is in the |
115 | ``meta/classes/base.bbclass`` file. | 115 | ``meta/classes/base.bbclass`` file. |
116 | 116 | ||
117 | **Q:** I'm behind a firewall and need to use a proxy server. How do I do | 117 | **Q:** I'm behind a firewall and need to use a proxy server. How do I do |
@@ -250,7 +250,7 @@ size, you need to set various configurations: | |||
250 | :term:`IMAGE_ROOTFS_EXTRA_SPACE` | 250 | :term:`IMAGE_ROOTFS_EXTRA_SPACE` |
251 | variable to add additional free space to the image. The build system | 251 | variable to add additional free space to the image. The build system |
252 | adds this space to the image after it determines its | 252 | adds this space to the image after it determines its |
253 | ``IMAGE_ROOTFS_SIZE``. | 253 | :term:`IMAGE_ROOTFS_SIZE`. |
254 | 254 | ||
255 | **Q:** Why don't you support directories with spaces in the pathnames? | 255 | **Q:** Why don't you support directories with spaces in the pathnames? |
256 | 256 | ||
@@ -262,11 +262,11 @@ situation changes, the team will not support spaces in pathnames. | |||
262 | **Q:** How do I use an external toolchain? | 262 | **Q:** How do I use an external toolchain? |
263 | 263 | ||
264 | **A:** The toolchain configuration is very flexible and customizable. It | 264 | **A:** The toolchain configuration is very flexible and customizable. It |
265 | is primarily controlled with the ``TCMODE`` variable. This variable | 265 | is primarily controlled with the :term:`TCMODE` variable. This variable |
266 | controls which ``tcmode-*.inc`` file to include from the | 266 | controls which ``tcmode-*.inc`` file to include from the |
267 | ``meta/conf/distro/include`` directory within the :term:`Source Directory`. | 267 | ``meta/conf/distro/include`` directory within the :term:`Source Directory`. |
268 | 268 | ||
269 | The default value of ``TCMODE`` is "default", which tells the | 269 | The default value of :term:`TCMODE` is "default", which tells the |
270 | OpenEmbedded build system to use its internally built toolchain (i.e. | 270 | OpenEmbedded build system to use its internally built toolchain (i.e. |
271 | ``tcmode-default.inc``). However, other patterns are accepted. In | 271 | ``tcmode-default.inc``). However, other patterns are accepted. In |
272 | particular, "external-\*" refers to external toolchains. One example is | 272 | particular, "external-\*" refers to external toolchains. One example is |
@@ -325,7 +325,7 @@ Here is another technique:: | |||
325 | BB_FETCH_PREMIRRORONLY = "1" | 325 | BB_FETCH_PREMIRRORONLY = "1" |
326 | 326 | ||
327 | This statement | 327 | This statement |
328 | limits the build system to pulling source from the ``PREMIRRORS`` only. | 328 | limits the build system to pulling source from the :term:`PREMIRRORS` only. |
329 | Again, this technique is useful for reproducing builds. | 329 | Again, this technique is useful for reproducing builds. |
330 | 330 | ||
331 | Here is another technique:: | 331 | Here is another technique:: |
@@ -339,7 +339,7 @@ however, the technique can simply waste time during the build. | |||
339 | 339 | ||
340 | Finally, consider an example where you are behind an HTTP-only firewall. | 340 | Finally, consider an example where you are behind an HTTP-only firewall. |
341 | You could make the following changes to the ``local.conf`` configuration | 341 | You could make the following changes to the ``local.conf`` configuration |
342 | file as long as the ``PREMIRRORS`` server is current:: | 342 | file as long as the :term:`PREMIRRORS` server is current:: |
343 | 343 | ||
344 | PREMIRRORS_prepend = "\ | 344 | PREMIRRORS_prepend = "\ |
345 | ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ | 345 | ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ |
@@ -349,7 +349,7 @@ file as long as the ``PREMIRRORS`` server is current:: | |||
349 | 349 | ||
350 | These changes would cause the build system to successfully fetch source | 350 | These changes would cause the build system to successfully fetch source |
351 | over HTTP and any network accesses to anything other than the | 351 | over HTTP and any network accesses to anything other than the |
352 | ``PREMIRRORS`` would fail. | 352 | :term:`PREMIRRORS` would fail. |
353 | 353 | ||
354 | The build system also honors the standard shell environment variables | 354 | The build system also honors the standard shell environment variables |
355 | ``http_proxy``, ``ftp_proxy``, ``https_proxy``, and ``all_proxy`` to | 355 | ``http_proxy``, ``ftp_proxy``, ``https_proxy``, and ``all_proxy`` to |