diff options
author | Nicolas Dechesne <nicolas.dechesne@linaro.org> | 2020-07-27 17:38:09 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2020-09-17 10:09:33 +0100 |
commit | 424567d629b08785a6594d16427ee0fa8c31f384 (patch) | |
tree | 4985979745b1c5601f7a82c662042fb745bfd7db /documentation/overview-manual | |
parent | 4bf6fc5281d1976ad7113c91a93995406cfab429 (diff) | |
download | poky-424567d629b08785a6594d16427ee0fa8c31f384.tar.gz |
sphinx: manual updates for some links
Some links were not found by the regexp, especially because of they
are spanning across multiple lines. This patch is a manual fixup for
these patterns.
(From yocto-docs rev: 7a5cf8b372903d959d4a1f0882e6198f31f3cba5)
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/overview-manual')
3 files changed, 54 insertions, 55 deletions
diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst index 59096fbebf..9764b25b6d 100644 --- a/documentation/overview-manual/overview-manual-concepts.rst +++ b/documentation/overview-manual/overview-manual-concepts.rst | |||
@@ -6,8 +6,8 @@ Yocto Project Concepts | |||
6 | 6 | ||
7 | This chapter provides explanations for Yocto Project concepts that go | 7 | This chapter provides explanations for Yocto Project concepts that go |
8 | beyond the surface of "how-to" information and reference (or look-up) | 8 | beyond the surface of "how-to" information and reference (or look-up) |
9 | material. Concepts such as components, the `OpenEmbedded build | 9 | material. Concepts such as components, the :term:`OpenEmbedded Build System` |
10 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ workflow, | 10 | workflow, |
11 | cross-development toolchains, shared state cache, and so forth are | 11 | cross-development toolchains, shared state cache, and so forth are |
12 | explained. | 12 | explained. |
13 | 13 | ||
@@ -48,8 +48,8 @@ Concepts <#openembedded-build-system-build-concepts>`__" section. | |||
48 | BitBake | 48 | BitBake |
49 | ------- | 49 | ------- |
50 | 50 | ||
51 | BitBake is the tool at the heart of the `OpenEmbedded build | 51 | BitBake is the tool at the heart of the :term:`OpenEmbedded Build System` |
52 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ and is responsible | 52 | and is responsible |
53 | for parsing the :term:`Metadata`, generating | 53 | for parsing the :term:`Metadata`, generating |
54 | a list of tasks from it, and then executing those tasks. | 54 | a list of tasks from it, and then executing those tasks. |
55 | 55 | ||
@@ -109,7 +109,7 @@ Class files (``.bbclass``) contain information that is useful to share | |||
109 | between recipes files. An example is the | 109 | between recipes files. An example is the |
110 | :ref:`autotools <ref-classes-autotools>` class, | 110 | :ref:`autotools <ref-classes-autotools>` class, |
111 | which contains common settings for any application that Autotools uses. | 111 | which contains common settings for any application that Autotools uses. |
112 | The "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter in the | 112 | The ":ref:`ref-manual/ref-classes:Classes`" chapter in the |
113 | Yocto Project Reference Manual provides details about classes and how to | 113 | Yocto Project Reference Manual provides details about classes and how to |
114 | use them. | 114 | use them. |
115 | 115 | ||
@@ -123,8 +123,8 @@ variables that govern the OpenEmbedded build process. These files fall | |||
123 | into several areas that define machine configuration options, | 123 | into several areas that define machine configuration options, |
124 | distribution configuration options, compiler tuning options, general | 124 | distribution configuration options, compiler tuning options, general |
125 | common configuration options, and user configuration options in | 125 | common configuration options, and user configuration options in |
126 | ``conf/local.conf``, which is found in the `Build | 126 | ``conf/local.conf``, which is found in the :term:`Build Directory`. |
127 | Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. | 127 | |
128 | 128 | ||
129 | .. _overview-layers: | 129 | .. _overview-layers: |
130 | 130 | ||
@@ -164,8 +164,8 @@ OpenEmbedded Build System Concepts | |||
164 | ================================== | 164 | ================================== |
165 | 165 | ||
166 | This section takes a more detailed look inside the build process used by | 166 | This section takes a more detailed look inside the build process used by |
167 | the `OpenEmbedded build | 167 | the :term:`OpenEmbedded Build System`, |
168 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, which is the build | 168 | which is the build |
169 | system specific to the Yocto Project. At the heart of the build system | 169 | system specific to the Yocto Project. At the heart of the build system |
170 | is BitBake, the task executor. | 170 | is BitBake, the task executor. |
171 | 171 | ||
@@ -221,8 +221,8 @@ figure <#general-workflow-figure>`__: | |||
221 | 221 | ||
222 | BitBake needs some basic configuration files in order to complete a | 222 | BitBake needs some basic configuration files in order to complete a |
223 | build. These files are ``*.conf`` files. The minimally necessary ones | 223 | build. These files are ``*.conf`` files. The minimally necessary ones |
224 | reside as example files in the ``build/conf`` directory of the `Source | 224 | reside as example files in the ``build/conf`` directory of the |
225 | Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. For simplicity, | 225 | :term:`Source Directory`. For simplicity, |
226 | this section refers to the Source Directory as the "Poky Directory." | 226 | this section refers to the Source Directory as the "Poky Directory." |
227 | 227 | ||
228 | When you clone the `Poky <&YOCTO_DOCS_REF_URL;#poky>`__ Git repository | 228 | When you clone the `Poky <&YOCTO_DOCS_REF_URL;#poky>`__ Git repository |
@@ -241,8 +241,8 @@ for creating actual configuration files when you source | |||
241 | ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__, which is the | 241 | ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__, which is the |
242 | build environment script. | 242 | build environment script. |
243 | 243 | ||
244 | Sourcing the build environment script creates a `Build | 244 | Sourcing the build environment script creates a |
245 | Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ if one does not | 245 | :term:`Build Directory` if one does not |
246 | already exist. BitBake uses the Build Directory for all its work during | 246 | already exist. BitBake uses the Build Directory for all its work during |
247 | builds. The Build Directory has a ``conf`` directory that contains | 247 | builds. The Build Directory has a ``conf`` directory that contains |
248 | default versions of your ``local.conf`` and ``bblayers.conf`` | 248 | default versions of your ``local.conf`` and ``bblayers.conf`` |
@@ -357,8 +357,8 @@ Configuration Edits" box in the figure. | |||
357 | 357 | ||
358 | When you launch your build with the ``bitbake target`` command, BitBake | 358 | When you launch your build with the ``bitbake target`` command, BitBake |
359 | sorts out the configurations to ultimately define your build | 359 | sorts out the configurations to ultimately define your build |
360 | environment. It is important to understand that the `OpenEmbedded build | 360 | environment. It is important to understand that the |
361 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ reads the | 361 | :term:`OpenEmbedded Build System` reads the |
362 | configuration files in a specific order: ``site.conf``, ``auto.conf``, | 362 | configuration files in a specific order: ``site.conf``, ``auto.conf``, |
363 | and ``local.conf``. And, the build system applies the normal assignment | 363 | and ``local.conf``. And, the build system applies the normal assignment |
364 | statement rules as described in the "`Syntax and | 364 | statement rules as described in the "`Syntax and |
@@ -460,7 +460,7 @@ typically find in the distribution layer: | |||
460 | can be shared among recipes in the distribution. When your recipes | 460 | can be shared among recipes in the distribution. When your recipes |
461 | inherit a class, they take on the settings and functions for that | 461 | inherit a class, they take on the settings and functions for that |
462 | class. You can read more about class files in the | 462 | class. You can read more about class files in the |
463 | "`Classes <&YOCTO_DOCS_REF_URL;#ref-classes>`__" chapter of the Yocto | 463 | ":ref:`ref-manual/ref-classes:Classes`" chapter of the Yocto |
464 | Reference Manual. | 464 | Reference Manual. |
465 | 465 | ||
466 | - *conf:* This area holds configuration files for the layer | 466 | - *conf:* This area holds configuration files for the layer |
@@ -643,8 +643,8 @@ Package Feeds | |||
643 | ------------- | 643 | ------------- |
644 | 644 | ||
645 | When the OpenEmbedded build system generates an image or an SDK, it gets | 645 | When the OpenEmbedded build system generates an image or an SDK, it gets |
646 | the packages from a package feed area located in the `Build | 646 | the packages from a package feed area located in the |
647 | Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The `general | 647 | :term:`Build Directory`. The `general |
648 | workflow figure <#general-workflow-figure>`__ shows this package feeds | 648 | workflow figure <#general-workflow-figure>`__ shows this package feeds |
649 | area in the upper-right corner. | 649 | area in the upper-right corner. |
650 | 650 | ||
@@ -687,7 +687,7 @@ package files are kept: | |||
687 | for the i586 or qemux86 architectures. | 687 | for the i586 or qemux86 architectures. |
688 | 688 | ||
689 | BitBake uses the | 689 | BitBake uses the |
690 | ```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ | 690 | :ref:`do_package_write_* <ref-tasks-package_write_deb>` |
691 | tasks to generate packages and place them into the package holding area | 691 | tasks to generate packages and place them into the package holding area |
692 | (e.g. ``do_package_write_ipk`` for IPK packages). See the | 692 | (e.g. ``do_package_write_ipk`` for IPK packages). See the |
693 | ":ref:`ref-tasks-package_write_deb`", | 693 | ":ref:`ref-tasks-package_write_deb`", |
@@ -733,8 +733,8 @@ code: | |||
733 | 733 | ||
734 | The :ref:`ref-tasks-fetch` and | 734 | The :ref:`ref-tasks-fetch` and |
735 | :ref:`ref-tasks-unpack` tasks fetch | 735 | :ref:`ref-tasks-unpack` tasks fetch |
736 | the source files and unpack them into the `Build | 736 | the source files and unpack them into the |
737 | Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. | 737 | :term:`Build Directory`. |
738 | 738 | ||
739 | .. note:: | 739 | .. note:: |
740 | 740 | ||
@@ -984,7 +984,7 @@ details on how this is accomplished, you can look at | |||
984 | ```package.bbclass`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`__. | 984 | ```package.bbclass`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`__. |
985 | 985 | ||
986 | Depending on the type of packages being created (RPM, DEB, or IPK), the | 986 | Depending on the type of packages being created (RPM, DEB, or IPK), the |
987 | ```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ | 987 | :ref:`do_package_write_* <ref-tasks-package_write_deb>` |
988 | task creates the actual packages and places them in the Package Feed | 988 | task creates the actual packages and places them in the Package Feed |
989 | area, which is ``${TMPDIR}/deploy``. You can see the "`Package | 989 | area, which is ``${TMPDIR}/deploy``. You can see the "`Package |
990 | Feeds <#package-feeds-dev-environment>`__" section for more detail on | 990 | Feeds <#package-feeds-dev-environment>`__" section for more detail on |
@@ -1067,7 +1067,7 @@ processing includes creation of a manifest file and optimizations. | |||
1067 | The manifest file (``.manifest``) resides in the same directory as the | 1067 | The manifest file (``.manifest``) resides in the same directory as the |
1068 | root filesystem image. This file lists out, line-by-line, the installed | 1068 | root filesystem image. This file lists out, line-by-line, the installed |
1069 | packages. The manifest file is useful for the | 1069 | packages. The manifest file is useful for the |
1070 | ```testimage`` <&YOCTO_DOCS_REF_URL;#ref-classes-testimage*>`__ class, | 1070 | :ref:`testimage <ref-classes-testimage*>` class, |
1071 | for example, to determine whether or not to run specific tests. See the | 1071 | for example, to determine whether or not to run specific tests. See the |
1072 | :term:`IMAGE_MANIFEST` | 1072 | :term:`IMAGE_MANIFEST` |
1073 | variable for additional information. | 1073 | variable for additional information. |
@@ -1102,7 +1102,7 @@ as specified by the ``IMAGE_FSTYPES`` were ``ext4``, the dynamically | |||
1102 | generated task would be as follows: do_image_ext4 | 1102 | generated task would be as follows: do_image_ext4 |
1103 | 1103 | ||
1104 | The final task involved in image creation is the | 1104 | The final task involved in image creation is the |
1105 | ```do_image_complete`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image-complete>`__ | 1105 | :ref:`do_image_complete <ref-tasks-image-complete>` |
1106 | task. This task completes the image by applying any image post | 1106 | task. This task completes the image by applying any image post |
1107 | processing as defined through the | 1107 | processing as defined through the |
1108 | :term:`IMAGE_POSTPROCESS_COMMAND` | 1108 | :term:`IMAGE_POSTPROCESS_COMMAND` |
@@ -1242,7 +1242,7 @@ version of the task where instead of building something, BitBake can | |||
1242 | skip to the end result and simply place a set of files into specific | 1242 | skip to the end result and simply place a set of files into specific |
1243 | locations as needed. In some cases, it makes sense to have a setscene | 1243 | locations as needed. In some cases, it makes sense to have a setscene |
1244 | task variant (e.g. generating package files in the | 1244 | task variant (e.g. generating package files in the |
1245 | ```do_package_write_*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__ | 1245 | :ref:`do_package_write_* <ref-tasks-package_write_deb>` |
1246 | task). In other cases, it does not make sense (e.g. a | 1246 | task). In other cases, it does not make sense (e.g. a |
1247 | :ref:`ref-tasks-patch` task or a | 1247 | :ref:`ref-tasks-patch` task or a |
1248 | :ref:`ref-tasks-unpack` task) since | 1248 | :ref:`ref-tasks-unpack` task) since |
@@ -1317,8 +1317,8 @@ this output: | |||
1317 | Images | 1317 | Images |
1318 | " chapter in the Yocto Project Reference Manual. | 1318 | " chapter in the Yocto Project Reference Manual. |
1319 | 1319 | ||
1320 | The build process writes images out to the `Build | 1320 | The build process writes images out to the :term:`Build Directory` |
1321 | Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ inside the | 1321 | inside the |
1322 | ``tmp/deploy/images/machine/`` folder as shown in the figure. This | 1322 | ``tmp/deploy/images/machine/`` folder as shown in the figure. This |
1323 | folder contains any files expected to be loaded on the target device. | 1323 | folder contains any files expected to be loaded on the target device. |
1324 | The :term:`DEPLOY_DIR` variable | 1324 | The :term:`DEPLOY_DIR` variable |
@@ -1775,8 +1775,8 @@ need to fix this situation. | |||
1775 | Thus far, this section has limited discussion to the direct inputs into | 1775 | Thus far, this section has limited discussion to the direct inputs into |
1776 | a task. Information based on direct inputs is referred to as the | 1776 | a task. Information based on direct inputs is referred to as the |
1777 | "basehash" in the code. However, the question of a task's indirect | 1777 | "basehash" in the code. However, the question of a task's indirect |
1778 | inputs still exits - items already built and present in the `Build | 1778 | inputs still exits - items already built and present in the |
1779 | Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__. The checksum (or | 1779 | :term:`Build Directory`. The checksum (or |
1780 | signature) for a particular task needs to add the hashes of all the | 1780 | signature) for a particular task needs to add the hashes of all the |
1781 | tasks on which the particular task depends. Choosing which dependencies | 1781 | tasks on which the particular task depends. Choosing which dependencies |
1782 | to add is a policy decision. However, the effect is to generate a master | 1782 | to add is a policy decision. However, the effect is to generate a master |
@@ -2117,9 +2117,9 @@ Fakeroot and Pseudo | |||
2117 | Some tasks are easier to implement when allowed to perform certain | 2117 | Some tasks are easier to implement when allowed to perform certain |
2118 | operations that are normally reserved for the root user (e.g. | 2118 | operations that are normally reserved for the root user (e.g. |
2119 | :ref:`ref-tasks-install`, | 2119 | :ref:`ref-tasks-install`, |
2120 | ```do_package_write*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package_write_deb>`__, | 2120 | :ref:`do_package_write* <ref-tasks-package_write_deb>`, |
2121 | :ref:`ref-tasks-rootfs`, and | 2121 | :ref:`ref-tasks-rootfs`, and |
2122 | ```do_image*`` <&YOCTO_DOCS_REF_URL;#ref-tasks-image>`__). For example, | 2122 | :ref:`do_image* <ref-tasks-image>`). For example, |
2123 | the ``do_install`` task benefits from being able to set the UID and GID | 2123 | the ``do_install`` task benefits from being able to set the UID and GID |
2124 | of installed files to arbitrary values. | 2124 | of installed files to arbitrary values. |
2125 | 2125 | ||
@@ -2139,8 +2139,8 @@ The capability to run tasks in a fake root environment is known as | |||
2139 | the BitBake keyword/variable flag that requests a fake root environment | 2139 | the BitBake keyword/variable flag that requests a fake root environment |
2140 | for a task. | 2140 | for a task. |
2141 | 2141 | ||
2142 | In the `OpenEmbedded build | 2142 | In the :term:`OpenEmbedded Build System`, |
2143 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, the program that | 2143 | the program that |
2144 | implements fakeroot is known as | 2144 | implements fakeroot is known as |
2145 | `Pseudo <https://www.yoctoproject.org/software-item/pseudo/>`__. Pseudo | 2145 | `Pseudo <https://www.yoctoproject.org/software-item/pseudo/>`__. Pseudo |
2146 | overrides system calls by using the environment variable ``LD_PRELOAD``, | 2146 | overrides system calls by using the environment variable ``LD_PRELOAD``, |
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst index 745d2ecf91..82562bf995 100644 --- a/documentation/overview-manual/overview-manual-development-environment.rst +++ b/documentation/overview-manual/overview-manual-development-environment.rst | |||
@@ -86,8 +86,8 @@ Once your development host is set up to use the Yocto Project, several | |||
86 | methods exist for you to do work in the Yocto Project environment: | 86 | methods exist for you to do work in the Yocto Project environment: |
87 | 87 | ||
88 | - *Command Lines, BitBake, and Shells:* Traditional development in the | 88 | - *Command Lines, BitBake, and Shells:* Traditional development in the |
89 | Yocto Project involves using the `OpenEmbedded build | 89 | Yocto Project involves using the :term:`OpenEmbedded Build System`, |
90 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__, which uses | 90 | which uses |
91 | BitBake, in a command-line environment from a shell on your | 91 | BitBake, in a command-line environment from a shell on your |
92 | development host. You can accomplish this from a host that is a | 92 | development host. You can accomplish this from a host that is a |
93 | native Linux machine or from a host that has been set up with CROPS. | 93 | native Linux machine or from a host that has been set up with CROPS. |
@@ -162,8 +162,8 @@ these tarballs gives you a snapshot of the released files. | |||
162 | 162 | ||
163 | .. note:: | 163 | .. note:: |
164 | 164 | ||
165 | - The recommended method for setting up the Yocto Project `Source | 165 | - The recommended method for setting up the Yocto Project |
166 | Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and the files | 166 | :term:`Source Directory` and the files |
167 | for supported BSPs (e.g., ``meta-intel``) is to use `Git <#git>`__ | 167 | for supported BSPs (e.g., ``meta-intel``) is to use `Git <#git>`__ |
168 | to create a local copy of the upstream repositories. | 168 | to create a local copy of the upstream repositories. |
169 | 169 | ||
@@ -350,8 +350,8 @@ Book <http://book.git-scm.com>`__. | |||
350 | software on which to develop. The Yocto Project has two scripts named | 350 | software on which to develop. The Yocto Project has two scripts named |
351 | ``create-pull-request`` and ``send-pull-request`` that ship with the | 351 | ``create-pull-request`` and ``send-pull-request`` that ship with the |
352 | release to facilitate this workflow. You can find these scripts in | 352 | release to facilitate this workflow. You can find these scripts in |
353 | the ``scripts`` folder of the `Source | 353 | the ``scripts`` folder of the |
354 | Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__. For information | 354 | :term:`Source Directory`. For information |
355 | on how to use these scripts, see the "`Using Scripts to Push a Change | 355 | on how to use these scripts, see the "`Using Scripts to Push a Change |
356 | Upstream and Request a | 356 | Upstream and Request a |
357 | Pull <&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream>`__" section in | 357 | Pull <&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream>`__" section in |
@@ -638,8 +638,8 @@ When you build an image using the Yocto Project, the build process uses | |||
638 | a known list of licenses to ensure compliance. You can find this list in | 638 | a known list of licenses to ensure compliance. You can find this list in |
639 | the :term:`Source Directory` at | 639 | the :term:`Source Directory` at |
640 | ``meta/files/common-licenses``. Once the build completes, the list of | 640 | ``meta/files/common-licenses``. Once the build completes, the list of |
641 | all licenses found and used during that build are kept in the `Build | 641 | all licenses found and used during that build are kept in the |
642 | Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ at | 642 | :term:`Build Directory` at |
643 | ``tmp/deploy/licenses``. | 643 | ``tmp/deploy/licenses``. |
644 | 644 | ||
645 | If a module requires a license that is not in the base list, the build | 645 | If a module requires a license that is not in the base list, the build |
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst index b27412cb25..3f98fa939c 100644 --- a/documentation/overview-manual/overview-manual-yp-intro.rst +++ b/documentation/overview-manual/overview-manual-yp-intro.rst | |||
@@ -180,8 +180,8 @@ developing using the Yocto Project: | |||
180 | changes on the development system within the BitBake environment and | 180 | changes on the development system within the BitBake environment and |
181 | then deploying only the updated packages to the target. | 181 | then deploying only the updated packages to the target. |
182 | 182 | ||
183 | The Yocto Project `OpenEmbedded build | 183 | The Yocto Project :term:`OpenEmbedded Build System` |
184 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ produces packages | 184 | produces packages |
185 | in standard formats (i.e. RPM, DEB, IPK, and TAR). You can deploy | 185 | in standard formats (i.e. RPM, DEB, IPK, and TAR). You can deploy |
186 | these packages into the running system on the target by using | 186 | these packages into the running system on the target by using |
187 | utilities on the target such as ``rpm`` or ``ipk``. | 187 | utilities on the target such as ``rpm`` or ``ipk``. |
@@ -202,8 +202,8 @@ The Yocto Project's "Layer Model" is a development model for embedded | |||
202 | and IoT Linux creation that distinguishes the Yocto Project from other | 202 | and IoT Linux creation that distinguishes the Yocto Project from other |
203 | simple build systems. The Layer Model simultaneously supports | 203 | simple build systems. The Layer Model simultaneously supports |
204 | collaboration and customization. Layers are repositories that contain | 204 | collaboration and customization. Layers are repositories that contain |
205 | related sets of instructions that tell the `OpenEmbedded build | 205 | related sets of instructions that tell the :term:`OpenEmbedded Build System` |
206 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to do. You can | 206 | what to do. You can |
207 | collaborate, share, and reuse layers. | 207 | collaborate, share, and reuse layers. |
208 | 208 | ||
209 | Layers can contain changes to previous instructions or settings at any | 209 | Layers can contain changes to previous instructions or settings at any |
@@ -292,8 +292,8 @@ The Yocto Project employs a collection of components and tools used by | |||
292 | the project itself, by project developers, and by those using the Yocto | 292 | the project itself, by project developers, and by those using the Yocto |
293 | Project. These components and tools are open source projects and | 293 | Project. These components and tools are open source projects and |
294 | metadata that are separate from the reference distribution | 294 | metadata that are separate from the reference distribution |
295 | (`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the `OpenEmbedded build | 295 | (`Poky <&YOCTO_DOCS_REF_URL;#poky>`__) and the |
296 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. Most of the | 296 | :term:`OpenEmbedded Build System`. Most of the |
297 | components and tools are downloaded separately. | 297 | components and tools are downloaded separately. |
298 | 298 | ||
299 | This section provides brief overviews of the components and tools | 299 | This section provides brief overviews of the components and tools |
@@ -367,8 +367,8 @@ The following list consists of tools that help production related | |||
367 | activities using the Yocto Project: | 367 | activities using the Yocto Project: |
368 | 368 | ||
369 | - *Auto Upgrade Helper:* This utility when used in conjunction with the | 369 | - *Auto Upgrade Helper:* This utility when used in conjunction with the |
370 | `OpenEmbedded build | 370 | :term:`OpenEmbedded Build System` |
371 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ (BitBake and | 371 | (BitBake and |
372 | OE-Core) automatically generates upgrades for recipes that are based | 372 | OE-Core) automatically generates upgrades for recipes that are based |
373 | on new versions of the recipes published upstream. | 373 | on new versions of the recipes published upstream. |
374 | 374 | ||
@@ -668,8 +668,8 @@ Project. | |||
668 | 668 | ||
669 | - *Toaster:* Regardless of what your Build Host is running, you can use | 669 | - *Toaster:* Regardless of what your Build Host is running, you can use |
670 | Toaster to develop software using the Yocto Project. Toaster is a web | 670 | Toaster to develop software using the Yocto Project. Toaster is a web |
671 | interface to the Yocto Project's `Open-Embedded build | 671 | interface to the Yocto Project's :term:`OpenEmbedded Build System`. |
672 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__. The interface | 672 | The interface |
673 | enables you to configure and run your builds. Information about | 673 | enables you to configure and run your builds. Information about |
674 | builds is collected and stored in a database. You can use Toaster to | 674 | builds is collected and stored in a database. You can use Toaster to |
675 | configure and start builds on multiple remote build servers. | 675 | configure and start builds on multiple remote build servers. |
@@ -789,8 +789,7 @@ section in the BitBake User's Manual. | |||
789 | The OpenEmbedded Build System Workflow | 789 | The OpenEmbedded Build System Workflow |
790 | ====================================== | 790 | ====================================== |
791 | 791 | ||
792 | The `OpenEmbedded build | 792 | The :term:`OpenEmbedded Build System` uses a "workflow" to |
793 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ uses a "workflow" to | ||
794 | accomplish image and SDK generation. The following figure overviews that | 793 | accomplish image and SDK generation. The following figure overviews that |
795 | workflow: | 794 | workflow: |
796 | 795 | ||
@@ -836,8 +835,8 @@ helpful for getting started: | |||
836 | 835 | ||
837 | - *Configuration Files:* Files that hold global definitions of | 836 | - *Configuration Files:* Files that hold global definitions of |
838 | variables, user-defined variables, and hardware configuration | 837 | variables, user-defined variables, and hardware configuration |
839 | information. These files tell the `Open-Embedded build | 838 | information. These files tell the :term:`OpenEmbedded Build System` |
840 | system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ what to build and | 839 | what to build and |
841 | what to put into the image to support a particular platform. | 840 | what to put into the image to support a particular platform. |
842 | 841 | ||
843 | - *Extensible Software Development Kit (eSDK):* A custom SDK for | 842 | - *Extensible Software Development Kit (eSDK):* A custom SDK for |