diff options
| author | Quentin Schulz <foss@0leil.net> | 2020-10-19 19:07:01 +0200 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2020-10-20 11:12:07 +0100 |
| commit | 7c18b7227a7aba5d90b50a40eda5760d7481e706 (patch) | |
| tree | 9712f07a62b6186450c77c4f095018b8a096e466 | |
| parent | 9360f09e57e941e6ae5bf6f595d46529fb67220f (diff) | |
| download | poky-7c18b7227a7aba5d90b50a40eda5760d7481e706.tar.gz | |
docs: ref-manual: ref-terms: add links to terms in glossary
Everything declared in a glossary has a "term-" link that is usable as an
HTML anchor. The link already works, one just cannot get a link from
within the ref-terms page.
Let's make this possible.
Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
(From yocto-docs rev: fcbb267fba968834d4d9d011fc71cc371f910447)
Signed-off-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
| -rw-r--r-- | documentation/ref-manual/ref-terms.rst | 48 |
1 files changed, 24 insertions, 24 deletions
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst index bd8df149e6..b4ceebc0bb 100644 --- a/documentation/ref-manual/ref-terms.rst +++ b/documentation/ref-manual/ref-terms.rst | |||
| @@ -10,7 +10,7 @@ universal, the list includes them just in case: | |||
| 10 | 10 | ||
| 11 | .. glossary:: | 11 | .. glossary:: |
| 12 | 12 | ||
| 13 | Append Files | 13 | :term:`Append Files` |
| 14 | Files that append build information to a recipe file. Append files are | 14 | Files that append build information to a recipe file. Append files are |
| 15 | known as BitBake append files and ``.bbappend`` files. The OpenEmbedded | 15 | known as BitBake append files and ``.bbappend`` files. The OpenEmbedded |
| 16 | build system expects every append file to have a corresponding recipe | 16 | build system expects every append file to have a corresponding recipe |
| @@ -50,18 +50,18 @@ universal, the list includes them just in case: | |||
| 50 | name. You cannot use the wildcard character in any other location of | 50 | name. You cannot use the wildcard character in any other location of |
| 51 | the name. | 51 | the name. |
| 52 | 52 | ||
| 53 | BitBake | 53 | :term:`BitBake` |
| 54 | The task executor and scheduler used by the OpenEmbedded build system to | 54 | The task executor and scheduler used by the OpenEmbedded build system to |
| 55 | build images. For more information on BitBake, see the :doc:`BitBake User | 55 | build images. For more information on BitBake, see the :doc:`BitBake User |
| 56 | Manual <bitbake:index>`. | 56 | Manual <bitbake:index>`. |
| 57 | 57 | ||
| 58 | Board Support Package (BSP) | 58 | :term:`Board Support Package (BSP)` |
| 59 | A group of drivers, definitions, and other components that provide support | 59 | A group of drivers, definitions, and other components that provide support |
| 60 | for a specific hardware configuration. For more information on BSPs, see | 60 | for a specific hardware configuration. For more information on BSPs, see |
| 61 | the :ref:`bsp-guide/bsp-guide:Yocto Project Board Support Package | 61 | the :ref:`bsp-guide/bsp-guide:Yocto Project Board Support Package |
| 62 | Developer's Guide`. | 62 | Developer's Guide`. |
| 63 | 63 | ||
| 64 | Build Directory | 64 | :term:`Build Directory` |
| 65 | This term refers to the area used by the OpenEmbedded build system for | 65 | This term refers to the area used by the OpenEmbedded build system for |
| 66 | builds. The area is created when you ``source`` the setup environment | 66 | builds. The area is created when you ``source`` the setup environment |
| 67 | script that is found in the Source Directory | 67 | script that is found in the Source Directory |
| @@ -109,19 +109,19 @@ universal, the list includes them just in case: | |||
| 109 | drive. Doing so effectively separates ``TMPDIR`` from :term:`TOPDIR`, which is the | 109 | drive. Doing so effectively separates ``TMPDIR`` from :term:`TOPDIR`, which is the |
| 110 | Build Directory. | 110 | Build Directory. |
| 111 | 111 | ||
| 112 | Build Host | 112 | :term:`Build Host` |
| 113 | The system used to build images in a Yocto Project Development | 113 | The system used to build images in a Yocto Project Development |
| 114 | environment. The build system is sometimes referred to as the development | 114 | environment. The build system is sometimes referred to as the development |
| 115 | host. | 115 | host. |
| 116 | 116 | ||
| 117 | Classes | 117 | :term:`Classes` |
| 118 | Files that provide for logic encapsulation and inheritance so that | 118 | Files that provide for logic encapsulation and inheritance so that |
| 119 | commonly used patterns can be defined once and then easily used in | 119 | commonly used patterns can be defined once and then easily used in |
| 120 | multiple recipes. For reference information on the Yocto Project classes, | 120 | multiple recipes. For reference information on the Yocto Project classes, |
| 121 | see the ":ref:`ref-manual/ref-classes:Classes`" chapter. Class files end with the | 121 | see the ":ref:`ref-manual/ref-classes:Classes`" chapter. Class files end with the |
| 122 | ``.bbclass`` filename extension. | 122 | ``.bbclass`` filename extension. |
| 123 | 123 | ||
| 124 | Configuration File | 124 | :term:`Configuration File` |
| 125 | Files that hold global definitions of variables, user-defined variables, | 125 | Files that hold global definitions of variables, user-defined variables, |
| 126 | and hardware configuration information. These files tell the OpenEmbedded | 126 | and hardware configuration information. These files tell the OpenEmbedded |
| 127 | build system what to build and what to put into the image to support a | 127 | build system what to build and what to put into the image to support a |
| @@ -138,13 +138,13 @@ universal, the list includes them just in case: | |||
| 138 | :file:`machine/beaglebone.conf` configuration file defines variables for | 138 | :file:`machine/beaglebone.conf` configuration file defines variables for |
| 139 | the Texas Instruments ARM Cortex-A8 development board). | 139 | the Texas Instruments ARM Cortex-A8 development board). |
| 140 | 140 | ||
| 141 | Container Layer | 141 | :term:`Container Layer` |
| 142 | Layers that hold other layers. An example of a container layer is | 142 | Layers that hold other layers. An example of a container layer is |
| 143 | OpenEmbedded's `meta-openembedded | 143 | OpenEmbedded's `meta-openembedded |
| 144 | <https://github.com/openembedded/meta-openembedded>`_ layer. The | 144 | <https://github.com/openembedded/meta-openembedded>`_ layer. The |
| 145 | ``meta-openembedded`` layer contains many ``meta-*`` layers. | 145 | ``meta-openembedded`` layer contains many ``meta-*`` layers. |
| 146 | 146 | ||
| 147 | Cross-Development Toolchain | 147 | :term:`Cross-Development Toolchain` |
| 148 | In general, a cross-development toolchain is a collection of software | 148 | In general, a cross-development toolchain is a collection of software |
| 149 | development tools and utilities that run on one architecture and allow you | 149 | development tools and utilities that run on one architecture and allow you |
| 150 | to develop software for a different, or targeted, architecture. These | 150 | to develop software for a different, or targeted, architecture. These |
| @@ -167,7 +167,7 @@ universal, the list includes them just in case: | |||
| 167 | toolchain in the :ref:`sdk-manual/sdk-manual:Yocto Project Application | 167 | toolchain in the :ref:`sdk-manual/sdk-manual:Yocto Project Application |
| 168 | Development and the Extensible Software Development Kit (eSDK)` manual. | 168 | Development and the Extensible Software Development Kit (eSDK)` manual. |
| 169 | 169 | ||
| 170 | Extensible Software Development Kit (eSDK) | 170 | :term:`Extensible Software Development Kit (eSDK)` |
| 171 | A custom SDK for application developers. This eSDK allows developers to | 171 | A custom SDK for application developers. This eSDK allows developers to |
| 172 | incorporate their library and programming changes back into the image to | 172 | incorporate their library and programming changes back into the image to |
| 173 | make their code available to other application developers. | 173 | make their code available to other application developers. |
| @@ -176,14 +176,14 @@ universal, the list includes them just in case: | |||
| 176 | Project Application Development and the Extensible Software Development | 176 | Project Application Development and the Extensible Software Development |
| 177 | Kit (eSDK)` manual. | 177 | Kit (eSDK)` manual. |
| 178 | 178 | ||
| 179 | Image | 179 | :term:`Image` |
| 180 | An image is an artifact of the BitBake build process given a collection of | 180 | An image is an artifact of the BitBake build process given a collection of |
| 181 | recipes and related Metadata. Images are the binary output that run on | 181 | recipes and related Metadata. Images are the binary output that run on |
| 182 | specific hardware or QEMU and are used for specific use-cases. For a list | 182 | specific hardware or QEMU and are used for specific use-cases. For a list |
| 183 | of the supported image types that the Yocto Project provides, see the | 183 | of the supported image types that the Yocto Project provides, see the |
| 184 | ":ref:`ref-manual/ref-images:Images`" chapter. | 184 | ":ref:`ref-manual/ref-images:Images`" chapter. |
| 185 | 185 | ||
| 186 | Layer | 186 | :term:`Layer` |
| 187 | A collection of related recipes. Layers allow you to consolidate related | 187 | A collection of related recipes. Layers allow you to consolidate related |
| 188 | metadata to customize your build. Layers also isolate information used | 188 | metadata to customize your build. Layers also isolate information used |
| 189 | when building for multiple architectures. Layers are hierarchical in | 189 | when building for multiple architectures. Layers are hierarchical in |
| @@ -202,7 +202,7 @@ universal, the list includes them just in case: | |||
| 202 | Layers`" section in the Yocto Project Board Support Packages (BSP) | 202 | Layers`" section in the Yocto Project Board Support Packages (BSP) |
| 203 | Developer's Guide. | 203 | Developer's Guide. |
| 204 | 204 | ||
| 205 | Metadata | 205 | :term:`Metadata` |
| 206 | A key element of the Yocto Project is the Metadata that | 206 | A key element of the Yocto Project is the Metadata that |
| 207 | is used to construct a Linux distribution and is contained in the | 207 | is used to construct a Linux distribution and is contained in the |
| 208 | files that the :term:`OpenEmbedded Build System` | 208 | files that the :term:`OpenEmbedded Build System` |
| @@ -221,7 +221,7 @@ universal, the list includes them just in case: | |||
| 221 | :yocto_git:`yocto-kernel-cache </cgit/cgit.cgi/yocto-kernel-cache>` | 221 | :yocto_git:`yocto-kernel-cache </cgit/cgit.cgi/yocto-kernel-cache>` |
| 222 | Git repository. | 222 | Git repository. |
| 223 | 223 | ||
| 224 | OpenEmbedded-Core (OE-Core) | 224 | :term:`OpenEmbedded-Core (OE-Core)` |
| 225 | OE-Core is metadata comprised of | 225 | OE-Core is metadata comprised of |
| 226 | foundational recipes, classes, and associated files that are meant to | 226 | foundational recipes, classes, and associated files that are meant to |
| 227 | be common among many different OpenEmbedded-derived systems, | 227 | be common among many different OpenEmbedded-derived systems, |
| @@ -234,7 +234,7 @@ universal, the list includes them just in case: | |||
| 234 | You can see the Metadata in the ``meta`` directory of the Yocto | 234 | You can see the Metadata in the ``meta`` directory of the Yocto |
| 235 | Project :yocto_git:`Source Repositories </cgit/cgit.cgi/poky>`. | 235 | Project :yocto_git:`Source Repositories </cgit/cgit.cgi/poky>`. |
| 236 | 236 | ||
| 237 | OpenEmbedded Build System | 237 | :term:`OpenEmbedded Build System` |
| 238 | The build system specific to the Yocto | 238 | The build system specific to the Yocto |
| 239 | Project. The OpenEmbedded build system is based on another project | 239 | Project. The OpenEmbedded build system is based on another project |
| 240 | known as "Poky", which uses :term:`BitBake` as the task | 240 | known as "Poky", which uses :term:`BitBake` as the task |
| @@ -248,7 +248,7 @@ universal, the list includes them just in case: | |||
| 248 | 248 | ||
| 249 | For some historical information about Poky, see the :term:`Poky` term. | 249 | For some historical information about Poky, see the :term:`Poky` term. |
| 250 | 250 | ||
| 251 | Package | 251 | :term:`Package` |
| 252 | In the context of the Yocto Project, this term refers to a | 252 | In the context of the Yocto Project, this term refers to a |
| 253 | recipe's packaged output produced by BitBake (i.e. a "baked recipe"). | 253 | recipe's packaged output produced by BitBake (i.e. a "baked recipe"). |
| 254 | A package is generally the compiled binaries produced from the | 254 | A package is generally the compiled binaries produced from the |
| @@ -266,7 +266,7 @@ universal, the list includes them just in case: | |||
| 266 | :term:`PR`, :term:`PV`, and | 266 | :term:`PR`, :term:`PV`, and |
| 267 | :term:`PE`). | 267 | :term:`PE`). |
| 268 | 268 | ||
| 269 | Package Groups | 269 | :term:`Package Groups` |
| 270 | Arbitrary groups of software Recipes. You use | 270 | Arbitrary groups of software Recipes. You use |
| 271 | package groups to hold recipes that, when built, usually accomplish a | 271 | package groups to hold recipes that, when built, usually accomplish a |
| 272 | single task. For example, a package group could contain the recipes | 272 | single task. For example, a package group could contain the recipes |
| @@ -275,7 +275,7 @@ universal, the list includes them just in case: | |||
| 275 | is really just another recipe. Because package group files are | 275 | is really just another recipe. Because package group files are |
| 276 | recipes, they end with the ``.bb`` filename extension. | 276 | recipes, they end with the ``.bb`` filename extension. |
| 277 | 277 | ||
| 278 | Poky | 278 | :term:`Poky` |
| 279 | Poky, which is pronounced *Pock*-ee, is a reference embedded | 279 | Poky, which is pronounced *Pock*-ee, is a reference embedded |
| 280 | distribution and a reference test configuration. Poky provides the | 280 | distribution and a reference test configuration. Poky provides the |
| 281 | following: | 281 | following: |
| @@ -300,7 +300,7 @@ universal, the list includes them just in case: | |||
| 300 | OpenedHand, the poky project became the basis for the Yocto | 300 | OpenedHand, the poky project became the basis for the Yocto |
| 301 | Project's build system. | 301 | Project's build system. |
| 302 | 302 | ||
| 303 | Recipe | 303 | :term:`Recipe` |
| 304 | A set of instructions for building packages. A recipe | 304 | A set of instructions for building packages. A recipe |
| 305 | describes where you get source code, which patches to apply, how to | 305 | describes where you get source code, which patches to apply, how to |
| 306 | configure the source, how to compile it and so on. Recipes also | 306 | configure the source, how to compile it and so on. Recipes also |
| @@ -308,13 +308,13 @@ universal, the list includes them just in case: | |||
| 308 | represent the logical unit of execution, the software to build, the | 308 | represent the logical unit of execution, the software to build, the |
| 309 | images to build, and use the ``.bb`` file extension. | 309 | images to build, and use the ``.bb`` file extension. |
| 310 | 310 | ||
| 311 | Reference Kit | 311 | :term:`Reference Kit` |
| 312 | A working example of a system, which includes a | 312 | A working example of a system, which includes a |
| 313 | :term:`BSP<Board Support Package (BSP)>` as well as a | 313 | :term:`BSP<Board Support Package (BSP)>` as well as a |
| 314 | :term:`build host<Build Host>` and other components, that can | 314 | :term:`build host<Build Host>` and other components, that can |
| 315 | work on specific hardware. | 315 | work on specific hardware. |
| 316 | 316 | ||
| 317 | Source Directory | 317 | :term:`Source Directory` |
| 318 | This term refers to the directory structure | 318 | This term refers to the directory structure |
| 319 | created as a result of creating a local copy of the ``poky`` Git | 319 | created as a result of creating a local copy of the ``poky`` Git |
| 320 | repository ``git://git.yoctoproject.org/poky`` or expanding a | 320 | repository ``git://git.yoctoproject.org/poky`` or expanding a |
| @@ -373,20 +373,20 @@ universal, the list includes them just in case: | |||
| 373 | ":ref:`overview-manual/overview-manual-development-environment:repositories, tags, and branches`" | 373 | ":ref:`overview-manual/overview-manual-development-environment:repositories, tags, and branches`" |
| 374 | section in the Yocto Project Overview and Concepts Manual. | 374 | section in the Yocto Project Overview and Concepts Manual. |
| 375 | 375 | ||
| 376 | Task | 376 | :term:`Task` |
| 377 | A unit of execution for BitBake (e.g. | 377 | A unit of execution for BitBake (e.g. |
| 378 | :ref:`ref-tasks-compile`, | 378 | :ref:`ref-tasks-compile`, |
| 379 | :ref:`ref-tasks-fetch`, | 379 | :ref:`ref-tasks-fetch`, |
| 380 | :ref:`ref-tasks-patch`, and so forth). | 380 | :ref:`ref-tasks-patch`, and so forth). |
| 381 | 381 | ||
| 382 | Toaster | 382 | :term:`Toaster` |
| 383 | A web interface to the Yocto Project's :term:`OpenEmbedded Build System`. | 383 | A web interface to the Yocto Project's :term:`OpenEmbedded Build System`. |
| 384 | The interface enables you to | 384 | The interface enables you to |
| 385 | configure and run your builds. Information about builds is collected | 385 | configure and run your builds. Information about builds is collected |
| 386 | and stored in a database. For information on Toaster, see the | 386 | and stored in a database. For information on Toaster, see the |
| 387 | :doc:`../toaster-manual/toaster-manual`. | 387 | :doc:`../toaster-manual/toaster-manual`. |
| 388 | 388 | ||
| 389 | Upstream | 389 | :term:`Upstream` |
| 390 | A reference to source code or repositories that are not | 390 | A reference to source code or repositories that are not |
| 391 | local to the development system but located in a master area that is | 391 | local to the development system but located in a master area that is |
| 392 | controlled by the maintainer of the source code. For example, in | 392 | controlled by the maintainer of the source code. For example, in |
