mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-31 00:39:46 +00:00
Code Issues Projects Releases Wiki Activity

sphinx: fix internal links

Browse Source 
Many of the internal links were not converted probably from DocBook
using pandoc. After looking at the various patterns, the follow series
of 'naive' Python regexp were used to perform some additional
automatic conversion.

Also, since we rely on built-in glossary, all links to terms need to
use the sphinx :term: syntax.

This commit is generated using the following Python series of regexp:

   line = re.sub("`+(\w+)`* <(\&YOCTO_DOCS_REF_URL;)?#var-\\1>`__",
                 ":term:`\\1`",
                 line)

   line = re.sub("`+do_([a-z_]+)`* <(\&YOCTO_DOCS_REF_URL;)?#ref-tasks-\\1>`__",
                 ":ref:`ref-tasks-\\1`",
                 line)

   line = re.sub("`+([a-z_\-\*\.]+).bbclass`* <(\&YOCTO_DOCS_REF_URL;)?#ref-classes-\\1>`__",
                 ":ref:`\\1.bbclass <ref-classes-\\1>`",
                 line)

   line = re.sub("`+([a-z_\-\*\.]+)`* <(\&YOCTO_DOCS_REF_URL;)?#ref-classes-\\1>`__",
                 ":ref:`\\1 <ref-classes-\\1>`",
                 line)

   line = re.sub("`Source Directory <(\&YOCTO_DOCS_REF_URL;)?#source-directory>`__",
                 ":term:`Source Directory`",
                 line)

   line = re.sub("`Build Directory <(\&YOCTO_DOCS_REF_URL;)?#build-directory>`__",
                 ":term:`Build Directory`",
                 line)

   line = re.sub("`Metadata <(\&YOCTO_DOCS_REF_URL;)?#metadata>`__",
                 ":term:`Metadata`",
                 line)

   line = re.sub("`BitBake <(\&YOCTO_DOCS_REF_URL;)?#bitbake-term>`__",
                 ":term:`BitBake`",
                 line)

   line = re.sub("`Images <(\&YOCTO_DOCS_REF_URL;)?#ref-images>`__",
                 ":ref:`ref-manual/ref-images:Images`",
                 line)

   line = re.sub("`Classes <(\&YOCTO_DOCS_REF_URL;)?#ref-classes>`__",
                 ":ref:`ref-manual/ref-classes:Classes`",
                 line)

   line = re.sub("`workspace <(\&YOCTO_DOCS_REF_URL;)?#devtool-the-workspace-layer-structure>`__",
                 ":ref:`devtool-the-workspace-layer-structure`",
                 line)

   line = re.sub("`Open-?Embedded b?B?uild s?S?ystem <(\&YOCTO_DOCS_REF_URL;)?#build-system-term>`__",
                 ":term:`OpenEmbedded Build System`",
                 line)

   line = re.sub("`(OpenEmbedded-Core )?(\(?OE-Core\)? )?<(\&YOCTO_DOCS_REF_URL;)?#oe-core>`__",
                 ":term:`OpenEmbedded-Core (OE-Core)`",
                 line)

It won't catch multiline strings, but it catches a very large number
of occurences!

(From yocto-docs rev: 3f537d17de5b1fb76ba3bee196481984a4826378)

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Nicolas Dechesne
2020-07-24 16:27:54 +02:00
committed by Richard Purdie
parent 4cd953989d
commit c473fa2292
42 changed files with 2221 additions and 2221 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/bsp-guide/bsp.rst
+38 -38
View File
@@ -73,7 +73,7 @@ section in the Yocto Project Development Tasks Manual.
The BSP layer's base directory (``meta-bsp_root_name``) is the root
directory of that Layer. This directory is what you add to the
```BBLAYERS`` <&YOCTO_DOCS_REF_URL;#var-BBLAYERS>`__ variable in the
:term:`BBLAYERS` variable in the
``conf/bblayers.conf`` file found in your `Build
Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__, which is
established after you run the OpenEmbedded build environment setup
@@ -466,7 +466,7 @@ This file provides information on where to locate the BSP source files
used to build the images (if any) that reside in
``meta-bsp_root_name/binary``. Images in the ``binary`` would be images
released with the BSP. The information in the ``README.sources`` file
also helps you find the `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__
also helps you find the :term:`Metadata`
used to generate the images that ship with the BSP.
.. note::
@@ -532,7 +532,7 @@ BBFILE_PATTERN_raspberrypi := "^${LAYERDIR}/"
BBFILE_PRIORITY_raspberrypi = "9" # Additional license directories.
LICENSE_PATH += "${LAYERDIR}/files/custom-licenses" . . .
This file simply makes `BitBake <&YOCTO_DOCS_REF_URL;#bitbake-term>`__
This file simply makes :term:`BitBake`
aware of the recipes and configuration directories. The file must exist
so that the OpenEmbedded build system can recognize the BSP.
@@ -549,10 +549,10 @@ in the BSP into a format that the build system can understand. Each BSP
Layer requires at least one machine file. If the BSP supports multiple
machines, multiple machine configuration files can exist. These
filenames correspond to the values to which users have set the
```MACHINE`` <&YOCTO_DOCS_REF_URL;#var-MACHINE>`__ variable.
:term:`MACHINE` variable.
These files define things such as the kernel package to use
(```PREFERRED_PROVIDER`` <&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER>`__
(:term:`PREFERRED_PROVIDER`
of
`virtual/kernel <&YOCTO_DOCS_DEV_URL;#metadata-virtual-providers>`__),
the hardware drivers to include in different types of images, any
@@ -565,7 +565,7 @@ optimization flags, which are carefully chosen to give best performance
on a given processor.
Tuning files are found in the ``meta/conf/machine/include`` directory
within the `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__.
within the :term:`Source Directory`.
For example, many ``tune-*`` files (e.g. ``tune-arm1136jf-s.inc``,
``tune-1586-nlp.inc``, and so forth) reside in the
``poky/meta/conf/machine/include`` directory.
@@ -599,7 +599,7 @@ DISPLAY_ORIENTATION=0 DISPLAY_DPI=133
according to the formfactor configuration file that is installed by
the main formfactor recipe
``meta/recipes-bsp/formfactor/formfactor_0.0.bb``, which is found in
the `Source Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__.
the :term:`Source Directory`.
.. _bsp-filelayout-recipes-graphics:
@@ -639,9 +639,9 @@ located in the BSP Layer for your target device (e.g. the
Suppose you are using the ``linux-yocto_4.4.bb`` recipe to build the
kernel. In other words, you have selected the kernel in your
bsp_root_name\ ``.conf`` file by adding
```PREFERRED_PROVIDER`` <&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER>`__
:term:`PREFERRED_PROVIDER`
and
```PREFERRED_VERSION`` <&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION>`__
:term:`PREFERRED_VERSION`
statements as follows: PREFERRED_PROVIDER_virtual/kernel ?=
"linux-yocto" PREFERRED_VERSION_linux-yocto ?= "4.4%"
@@ -796,7 +796,7 @@ workflow.
The build process supports several types of images to satisfy
different needs. See the
"`Images <&YOCTO_DOCS_REF_URL;#ref-images>`__" chapter in the Yocto
":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
Project Reference Manual for information on supported images.
Requirements and Recommendations for Released BSPs
@@ -1038,7 +1038,7 @@ also supports several other machines:
The
```FILESEXTRAPATHS`` <&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS>`__
:term:`FILESEXTRAPATHS`
variable in the append files extends the search path the build system
uses to find files during the build. Consequently, for this example
you need to have the ``files`` directory in the same location as your
@@ -1090,11 +1090,11 @@ satisfy the licensing requirements for an encumbered BSP. The following
list describes them in order of preference:
1. *Use
the*\ ```LICENSE_FLAGS`` <&YOCTO_DOCS_REF_URL;#var-LICENSE_FLAGS>`__\ *Variable
the*\ :term:`LICENSE_FLAGS`\ *Variable
to Define the Recipes that Have Commercial or Other Types of
Specially-Licensed Packages:* For each of those recipes, you can
specify a matching license string in a ``local.conf`` variable named
```LICENSE_FLAGS_WHITELIST`` <&YOCTO_DOCS_REF_URL;#var-LICENSE_FLAGS_WHITELIST>`__.
:term:`LICENSE_FLAGS_WHITELIST`.
Specifying the matching license string signifies that you agree to
the license. Thus, the build system can build the corresponding
recipe and include the component in the image. See the "`Enabling
@@ -1266,12 +1266,12 @@ Project Reference Manual.
"virtual/xserver" is "xserver-xorg", which exists in
``poky/meta/recipes-graphics/xorg-xserver``.
- ```XSERVER`` <&YOCTO_DOCS_REF_URL;#var-XSERVER>`__: The packages that
- :term:`XSERVER`: The packages that
should be installed to provide an X server and drivers for the
machine. In this example, the "xserver-xorg" and
"xf86-video-modesetting" are installed.
- ```MACHINE_EXTRA_RRECOMMENDS`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RRECOMMENDS>`__:
- :term:`MACHINE_EXTRA_RRECOMMENDS`:
A list of machine-dependent packages not essential for booting the
image. Thus, the build does not fail if the packages do not exist.
However, the packages are required for a fully-featured image.
@@ -1283,14 +1283,14 @@ Project Reference Manual.
variables exist that help you configure a particular piece of
hardware.
- ```EXTRA_IMAGEDEPENDS`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGEDEPENDS>`__:
- :term:`EXTRA_IMAGEDEPENDS`:
Recipes to build that do not provide packages for installing into the
root filesystem but building the image depends on the recipes.
Sometimes a recipe is required to build the final image but is not
needed in the root filesystem. In this case, the U-Boot recipe must
be built for the image.
- ```DEFAULTTUNE`` <&YOCTO_DOCS_REF_URL;#var-DEFAULTTUNE>`__: Machines
- :term:`DEFAULTTUNE`: Machines
use tunings to optimize machine, CPU, and application performance.
These features, which are collectively known as "tuning features",
exist in the `OpenEmbedded-Core
@@ -1306,31 +1306,31 @@ Project Reference Manual.
conf/machine/include/tune-cortexa8.inc
file provides many tuning possibilities.
- ```IMAGE_FSTYPES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES>`__: The
- :term:`IMAGE_FSTYPES`: The
formats the OpenEmbedded build system uses during the build when
creating the root filesystem. In this example, four types of images
are supported.
- ```EXTRA_IMAGECMD`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGECMD>`__:
- :term:`EXTRA_IMAGECMD`:
Specifies additional options for image creation commands. In this
example, the "-lnp " option is used when creating the
`JFFS2 <https://en.wikipedia.org/wiki/JFFS2>`__ image.
- ```WKS_FILE`` <&YOCTO_DOCS_REF_URL;#var-WKS_FILE>`__: The location of
- :term:`WKS_FILE`: The location of
the `Wic kickstart <&YOCTO_DOCS_REF_URL;#ref-kickstart>`__ file used
by the OpenEmbedded build system to create a partitioned image
(image.wic).
- ```IMAGE_INSTALL`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL>`__:
- :term:`IMAGE_INSTALL`:
Specifies packages to install into an image through the
```image`` <&YOCTO_DOCS_REF_URL;#ref-classes-image>`__ class. Recipes
:ref:`image <ref-classes-image>` class. Recipes
use the ``IMAGE_INSTALL`` variable.
- ``do_image_wic[depends]``: A task that is constructed during the
build. In this example, the task depends on specific tools in order
to create the sysroot when buiding a Wic image.
- ```SERIAL_CONSOLES`` <&YOCTO_DOCS_REF_URL;#var-SERIAL_CONSOLES>`__:
- :term:`SERIAL_CONSOLES`:
Defines a serial console (TTY) to enable using getty. In this case,
the baud rate is "115200" and the device name is "ttyO0".
@@ -1344,21 +1344,21 @@ Project Reference Manual.
Defines the version of the recipe used to build the kernel, which is
"5.0" in this case.
- ```KERNEL_IMAGETYPE`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_IMAGETYPE>`__:
- :term:`KERNEL_IMAGETYPE`:
The type of kernel to build for the device. In this case, the
OpenEmbedded build system creates a "zImage" image type.
- ```KERNEL_DEVICETREE`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_DEVICETREE>`__:
- :term:`KERNEL_DEVICETREE`:
The names of the generated Linux kernel device trees (i.e. the
``*.dtb``) files. All the device trees for the various BeagleBone
devices are included.
- ```KERNEL_EXTRA_ARGS`` <&YOCTO_DOCS_REF_URL;#var-KERNEL_EXTRA_ARGS>`__:
- :term:`KERNEL_EXTRA_ARGS`:
Additional ``make`` command-line arguments the OpenEmbedded build
system passes on when compiling the kernel. In this example,
"LOADADDR=${UBOOT_ENTRYPOINT}" is passed as a command-line argument.
- ```SPL_BINARY`` <&YOCTO_DOCS_REF_URL;#var-SPL_BINARY>`__: Defines the
- :term:`SPL_BINARY`: Defines the
Secondary Program Loader (SPL) binary type. In this case, the SPL
binary is set to "MLO", which stands for Multimedia card LOader.
@@ -1377,25 +1377,25 @@ Project Reference Manual.
example, a U-Boot image is required to boot the BeagleBone device.
See the following variables for more information:
- ```UBOOT_SUFFIX`` <&YOCTO_DOCS_REF_URL;#var-UBOOT_SUFFIX>`__:
- :term:`UBOOT_SUFFIX`:
Points to the generated U-Boot extension.
- ```UBOOT_MACHINE`` <&YOCTO_DOCS_REF_URL;#var-UBOOT_MACHINE>`__:
- :term:`UBOOT_MACHINE`:
Specifies the value passed on the make command line when building
a U-Boot image.
- ```UBOOT_ENTRYPOINT`` <&YOCTO_DOCS_REF_URL;#var-UBOOT_ENTRYPOINT>`__:
- :term:`UBOOT_ENTRYPOINT`:
Specifies the entry point for the U-Boot image.
- ```UBOOT_LOADADDRESS`` <&YOCTO_DOCS_REF_URL;#var-UBOOT_LOADADDRESS>`__:
- :term:`UBOOT_LOADADDRESS`:
Specifies the load address for the U-Boot image.
- ```MACHINE_FEATURES`` <&YOCTO_DOCS_REF_URL;#var-MACHINE_FEATURES>`__:
- :term:`MACHINE_FEATURES`:
Specifies the list of hardware features the BeagleBone device is
capable of supporting. In this case, the device supports "usbgadget
usbhost vfat alsa".
- ```IMAGE_BOOT_FILES`` <&YOCTO_DOCS_REF_URL;#var-IMAGE_BOOT_FILES>`__:
- :term:`IMAGE_BOOT_FILES`:
Files installed into the device's boot partition when preparing the
image using the Wic tool with the ``bootimg-partition`` or
``bootimg-efi`` source plugin.
@@ -1435,21 +1435,21 @@ appended with the "beaglebone-yocto" string. The OpenEmbedded build
system uses these statements to override similar statements in the
kernel recipe:
- ```KBRANCH`` <&YOCTO_DOCS_REF_URL;#var-KBRANCH>`__: Identifies the
- :term:`KBRANCH`: Identifies the
kernel branch that is validated, patched, and configured during the
build.
- ```KMACHINE`` <&YOCTO_DOCS_REF_URL;#var-KMACHINE>`__: Identifies the
- :term:`KMACHINE`: Identifies the
machine name as known by the kernel, which is sometimes a different
name than what is known by the OpenEmbedded build system.
- ```SRCREV`` <&YOCTO_DOCS_REF_URL;#var-SRCREV>`__: Identifies the
- :term:`SRCREV`: Identifies the
revision of the source code used to build the image.
- ```COMPATIBLE_MACHINE`` <&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE>`__:
- :term:`COMPATIBLE_MACHINE`:
A regular expression that resolves to one or more target machines
with which the recipe is compatible.
- ```LINUX_VERSION`` <&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION>`__: The
- :term:`LINUX_VERSION`: The
Linux version from kernel.org used by the OpenEmbedded build system
to build the kernel image.