diff options
29 files changed, 127 insertions, 128 deletions
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst index 280b160807..7e17b42886 100644 --- a/documentation/bsp-guide/bsp.rst +++ b/documentation/bsp-guide/bsp.rst | |||
@@ -1,8 +1,8 @@ | |||
1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK | 1 | .. SPDX-License-Identifier: CC-BY-SA-2.0-UK |
2 | 2 | ||
3 | ************************************************ | 3 | ************************************************** |
4 | Board Support Packages (BSP) - Developer's Guide | 4 | Board Support Packages (BSP) --- Developer's Guide |
5 | ************************************************ | 5 | ************************************************** |
6 | 6 | ||
7 | A Board Support Package (BSP) is a collection of information that | 7 | A Board Support Package (BSP) is a collection of information that |
8 | defines how to support a particular hardware device, set of devices, or | 8 | defines how to support a particular hardware device, set of devices, or |
diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst index a6c7ba3ce1..01dac39c6f 100644 --- a/documentation/dev-manual/common-tasks.rst +++ b/documentation/dev-manual/common-tasks.rst | |||
@@ -2306,7 +2306,7 @@ under ``files``) requires a recipe that has the file listed in the | |||
2306 | :term:`SRC_URI` variable. Additionally, you need to manually write the | 2306 | :term:`SRC_URI` variable. Additionally, you need to manually write the |
2307 | ``do_compile`` and ``do_install`` tasks. The :term:`S` variable defines the | 2307 | ``do_compile`` and ``do_install`` tasks. The :term:`S` variable defines the |
2308 | directory containing the source code, which is set to | 2308 | directory containing the source code, which is set to |
2309 | :term:`WORKDIR` in this case - the | 2309 | :term:`WORKDIR` in this case --- the |
2310 | directory BitBake uses for the build. | 2310 | directory BitBake uses for the build. |
2311 | :: | 2311 | :: |
2312 | 2312 | ||
@@ -2780,7 +2780,7 @@ in the BitBake User Manual. | |||
2780 | functionality. The same considerations apply to various system | 2780 | functionality. The same considerations apply to various system |
2781 | utilities (e.g. ``sed``, ``grep``, ``awk``, and so forth) that you | 2781 | utilities (e.g. ``sed``, ``grep``, ``awk``, and so forth) that you |
2782 | might wish to use. If in doubt, you should check with multiple | 2782 | might wish to use. If in doubt, you should check with multiple |
2783 | implementations - including those from BusyBox. | 2783 | implementations --- including those from BusyBox. |
2784 | 2784 | ||
2785 | Adding a New Machine | 2785 | Adding a New Machine |
2786 | ==================== | 2786 | ==================== |
@@ -3348,9 +3348,9 @@ The actual directory depends on several things: | |||
3348 | 3348 | ||
3349 | - :term:`PN`: The recipe name. | 3349 | - :term:`PN`: The recipe name. |
3350 | 3350 | ||
3351 | - :term:`EXTENDPE`: The epoch - (if | 3351 | - :term:`EXTENDPE`: The epoch --- if |
3352 | :term:`PE` is not specified, which is | 3352 | :term:`PE` is not specified, which is |
3353 | usually the case for most recipes, then :term:`EXTENDPE` is blank). | 3353 | usually the case for most recipes, then :term:`EXTENDPE` is blank. |
3354 | 3354 | ||
3355 | - :term:`PV`: The recipe version. | 3355 | - :term:`PV`: The recipe version. |
3356 | 3356 | ||
@@ -6602,7 +6602,7 @@ the following: | |||
6602 | installed into an image. | 6602 | installed into an image. |
6603 | 6603 | ||
6604 | - Binary Package Version: The binary package version is composed of two | 6604 | - Binary Package Version: The binary package version is composed of two |
6605 | components - a version and a revision. | 6605 | components --- a version and a revision. |
6606 | 6606 | ||
6607 | .. note:: | 6607 | .. note:: |
6608 | 6608 | ||
@@ -6939,7 +6939,7 @@ optional arguments:: | |||
6939 | Postinstall script to use for all packages | 6939 | Postinstall script to use for all packages |
6940 | (as a string) | 6940 | (as a string) |
6941 | recursive | 6941 | recursive |
6942 | True to perform a recursive search - default | 6942 | True to perform a recursive search --- default |
6943 | False | 6943 | False |
6944 | hook | 6944 | hook |
6945 | A hook function to be called for every match. | 6945 | A hook function to be called for every match. |
@@ -6960,7 +6960,7 @@ optional arguments:: | |||
6960 | Extra runtime dependencies (RDEPENDS) to be | 6960 | Extra runtime dependencies (RDEPENDS) to be |
6961 | set for all packages. The default value of None | 6961 | set for all packages. The default value of None |
6962 | causes a dependency on the main package | 6962 | causes a dependency on the main package |
6963 | (${PN}) - if you do not want this, pass empty | 6963 | (${PN}) --- if you do not want this, pass empty |
6964 | string '' for this parameter. | 6964 | string '' for this parameter. |
6965 | aux_files_pattern | 6965 | aux_files_pattern |
6966 | Extra item(s) to be added to FILES for each | 6966 | Extra item(s) to be added to FILES for each |
@@ -6986,7 +6986,7 @@ optional arguments:: | |||
6986 | or a list of strings for multiple items. Must | 6986 | or a list of strings for multiple items. Must |
6987 | include %s. | 6987 | include %s. |
6988 | allow_links | 6988 | allow_links |
6989 | True to allow symlinks to be matched - default | 6989 | True to allow symlinks to be matched --- default |
6990 | False | 6990 | False |
6991 | summary | 6991 | summary |
6992 | Summary to set for each package. Must include %s; | 6992 | Summary to set for each package. Must include %s; |
@@ -7431,7 +7431,7 @@ A Package Test (ptest) runs tests against packages built by the | |||
7431 | OpenEmbedded build system on the target machine. A ptest contains at | 7431 | OpenEmbedded build system on the target machine. A ptest contains at |
7432 | least two items: the actual test, and a shell script (``run-ptest``) | 7432 | least two items: the actual test, and a shell script (``run-ptest``) |
7433 | that starts the test. The shell script that starts the test must not | 7433 | that starts the test. The shell script that starts the test must not |
7434 | contain the actual test - the script only starts the test. On the other | 7434 | contain the actual test --- the script only starts the test. On the other |
7435 | hand, the test can be anything from a simple shell script that runs a | 7435 | hand, the test can be anything from a simple shell script that runs a |
7436 | binary and checks the output to an elaborate system of test binaries and | 7436 | binary and checks the output to an elaborate system of test binaries and |
7437 | data files. | 7437 | data files. |
@@ -9132,13 +9132,13 @@ The JSON file must include an object with the test name as keys of an | |||
9132 | object or an array. This object (or array of objects) uses the following | 9132 | object or an array. This object (or array of objects) uses the following |
9133 | data: | 9133 | data: |
9134 | 9134 | ||
9135 | - "pkg" - A mandatory string that is the name of the package to be | 9135 | - "pkg" --- a mandatory string that is the name of the package to be |
9136 | installed. | 9136 | installed. |
9137 | 9137 | ||
9138 | - "rm" - An optional boolean, which defaults to "false", that specifies | 9138 | - "rm" --- an optional boolean, which defaults to "false", that specifies |
9139 | to remove the package after the test. | 9139 | to remove the package after the test. |
9140 | 9140 | ||
9141 | - "extract" - An optional boolean, which defaults to "false", that | 9141 | - "extract" --- an optional boolean, which defaults to "false", that |
9142 | specifies if the package must be extracted from the package format. | 9142 | specifies if the package must be extracted from the package format. |
9143 | When set to "true", the package is not automatically installed into | 9143 | When set to "true", the package is not automatically installed into |
9144 | the DUT. | 9144 | the DUT. |
@@ -9803,7 +9803,7 @@ Logging With Bash | |||
9803 | ~~~~~~~~~~~~~~~~~ | 9803 | ~~~~~~~~~~~~~~~~~ |
9804 | 9804 | ||
9805 | When creating recipes using Bash and inserting code that handles build | 9805 | When creating recipes using Bash and inserting code that handles build |
9806 | logs, you have the same goals - informative with minimal console output. | 9806 | logs, you have the same goals --- informative with minimal console output. |
9807 | The syntax you use for recipes written in Bash is similar to that of | 9807 | The syntax you use for recipes written in Bash is similar to that of |
9808 | recipes written in Python described in the previous section. | 9808 | recipes written in Python described in the previous section. |
9809 | 9809 | ||
@@ -10076,7 +10076,7 @@ to use GDB directly on the remote target to debug applications. These | |||
10076 | constraints arise because GDB needs to load the debugging information | 10076 | constraints arise because GDB needs to load the debugging information |
10077 | and the binaries of the process being debugged. Additionally, GDB needs | 10077 | and the binaries of the process being debugged. Additionally, GDB needs |
10078 | to perform many computations to locate information such as function | 10078 | to perform many computations to locate information such as function |
10079 | names, variable names and values, stack traces and so forth - even | 10079 | names, variable names and values, stack traces and so forth --- even |
10080 | before starting the debugging process. These extra computations place | 10080 | before starting the debugging process. These extra computations place |
10081 | more load on the target system and can alter the characteristics of the | 10081 | more load on the target system and can alter the characteristics of the |
10082 | program being debugged. | 10082 | program being debugged. |
@@ -10653,7 +10653,7 @@ Preparing Changes for Submission | |||
10653 | - If the change addresses a specific bug or issue that is associated | 10653 | - If the change addresses a specific bug or issue that is associated |
10654 | with a bug-tracking ID, include a reference to that ID in your | 10654 | with a bug-tracking ID, include a reference to that ID in your |
10655 | detailed description. For example, the Yocto Project uses a | 10655 | detailed description. For example, the Yocto Project uses a |
10656 | specific convention for bug references - any commit that addresses | 10656 | specific convention for bug references --- any commit that addresses |
10657 | a specific bug should use the following form for the detailed | 10657 | a specific bug should use the following form for the detailed |
10658 | description. Be sure to use the actual bug-tracking ID from | 10658 | description. Be sure to use the actual bug-tracking ID from |
10659 | Bugzilla for bug-id:: | 10659 | Bugzilla for bug-id:: |
@@ -10916,20 +10916,20 @@ follows: | |||
10916 | result in the most straightforward path into the stable branch for the | 10916 | result in the most straightforward path into the stable branch for the |
10917 | fix. | 10917 | fix. |
10918 | 10918 | ||
10919 | a. *If the fix is present in the master branch - Submit a backport request | 10919 | a. *If the fix is present in the master branch --- submit a backport request |
10920 | by email:* You should send an email to the relevant stable branch | 10920 | by email:* You should send an email to the relevant stable branch |
10921 | maintainer and the mailing list with details of the bug or CVE to be | 10921 | maintainer and the mailing list with details of the bug or CVE to be |
10922 | fixed, the commit hash on the master branch that fixes the issue and | 10922 | fixed, the commit hash on the master branch that fixes the issue and |
10923 | the stable branches which you would like this fix to be backported to. | 10923 | the stable branches which you would like this fix to be backported to. |
10924 | 10924 | ||
10925 | b. *If the fix is not present in the master branch - Submit the fix to the | 10925 | b. *If the fix is not present in the master branch --- submit the fix to the |
10926 | master branch first:* This will ensure that the fix passes through the | 10926 | master branch first:* This will ensure that the fix passes through the |
10927 | project's usual patch review and test processes before being accepted. | 10927 | project's usual patch review and test processes before being accepted. |
10928 | It will also ensure that bugs are not left unresolved in the master | 10928 | It will also ensure that bugs are not left unresolved in the master |
10929 | branch itself. Once the fix is accepted in the master branch a backport | 10929 | branch itself. Once the fix is accepted in the master branch a backport |
10930 | request can be submitted as above. | 10930 | request can be submitted as above. |
10931 | 10931 | ||
10932 | c. *If the fix is unsuitable for the master branch - Submit a patch | 10932 | c. *If the fix is unsuitable for the master branch --- submit a patch |
10933 | directly for the stable branch:* This method should be considered as a | 10933 | directly for the stable branch:* This method should be considered as a |
10934 | last resort. It is typically necessary when the master branch is using | 10934 | last resort. It is typically necessary when the master branch is using |
10935 | a newer version of the software which includes an upstream fix for the | 10935 | a newer version of the software which includes an upstream fix for the |
@@ -11260,7 +11260,7 @@ Providing the Source Code | |||
11260 | 11260 | ||
11261 | Compliance activities should begin before you generate the final image. | 11261 | Compliance activities should begin before you generate the final image. |
11262 | The first thing you should look at is the requirement that tops the list | 11262 | The first thing you should look at is the requirement that tops the list |
11263 | for most compliance groups - providing the source. The Yocto Project has | 11263 | for most compliance groups --- providing the source. The Yocto Project has |
11264 | a few ways of meeting this requirement. | 11264 | a few ways of meeting this requirement. |
11265 | 11265 | ||
11266 | One of the easiest ways to meet this requirement is to provide the | 11266 | One of the easiest ways to meet this requirement is to provide the |
diff --git a/documentation/kernel-dev/advanced.rst b/documentation/kernel-dev/advanced.rst index b5290b61b3..b16b3e0517 100644 --- a/documentation/kernel-dev/advanced.rst +++ b/documentation/kernel-dev/advanced.rst | |||
@@ -183,7 +183,7 @@ the structure: | |||
183 | order to define a base kernel policy or major kernel type to be | 183 | order to define a base kernel policy or major kernel type to be |
184 | reused across multiple BSPs, place the file in ``ktypes`` directory. | 184 | reused across multiple BSPs, place the file in ``ktypes`` directory. |
185 | 185 | ||
186 | These distinctions can easily become blurred - especially as out-of-tree | 186 | These distinctions can easily become blurred --- especially as out-of-tree |
187 | features slowly merge upstream over time. Also, remember that how the | 187 | features slowly merge upstream over time. Also, remember that how the |
188 | description files are placed is a purely logical organization and has no | 188 | description files are placed is a purely logical organization and has no |
189 | impact on the functionality of the kernel Metadata. There is no impact | 189 | impact on the functionality of the kernel Metadata. There is no impact |
diff --git a/documentation/kernel-dev/concepts-appx.rst b/documentation/kernel-dev/concepts-appx.rst index b3a2f3abbf..63c5124a57 100644 --- a/documentation/kernel-dev/concepts-appx.rst +++ b/documentation/kernel-dev/concepts-appx.rst | |||
@@ -117,7 +117,7 @@ upstream Linux kernel development and are managed by the Yocto Project | |||
117 | team's Yocto Linux kernel development strategy. It is the Yocto Project | 117 | team's Yocto Linux kernel development strategy. It is the Yocto Project |
118 | team's policy to not back-port minor features to the released Yocto | 118 | team's policy to not back-port minor features to the released Yocto |
119 | Linux kernel. They only consider back-porting significant technological | 119 | Linux kernel. They only consider back-porting significant technological |
120 | jumps - and, that is done after a complete gap analysis. The reason | 120 | jumps --- and, that is done after a complete gap analysis. The reason |
121 | for this policy is that back-porting any small to medium sized change | 121 | for this policy is that back-porting any small to medium sized change |
122 | from an evolving Linux kernel can easily create mismatches, | 122 | from an evolving Linux kernel can easily create mismatches, |
123 | incompatibilities and very subtle errors. | 123 | incompatibilities and very subtle errors. |
diff --git a/documentation/migration-guides/migration-1.6.rst b/documentation/migration-guides/migration-1.6.rst index 358086560b..f54d4ba729 100644 --- a/documentation/migration-guides/migration-1.6.rst +++ b/documentation/migration-guides/migration-1.6.rst | |||
@@ -341,39 +341,39 @@ Removed and Renamed Recipes | |||
341 | 341 | ||
342 | The following recipes have been removed: | 342 | The following recipes have been removed: |
343 | 343 | ||
344 | - ``packagegroup-toolset-native`` - This recipe is largely unused. | 344 | - ``packagegroup-toolset-native`` --- this recipe is largely unused. |
345 | 345 | ||
346 | - ``linux-yocto-3.8`` - Support for the Linux yocto 3.8 kernel has been | 346 | - ``linux-yocto-3.8`` --- support for the Linux yocto 3.8 kernel has been |
347 | dropped. Support for the 3.10 and 3.14 kernels have been added with | 347 | dropped. Support for the 3.10 and 3.14 kernels have been added with |
348 | the ``linux-yocto-3.10`` and ``linux-yocto-3.14`` recipes. | 348 | the ``linux-yocto-3.10`` and ``linux-yocto-3.14`` recipes. |
349 | 349 | ||
350 | - ``ocf-linux`` - This recipe has been functionally replaced using | 350 | - ``ocf-linux`` --- this recipe has been functionally replaced using |
351 | ``cryptodev-linux``. | 351 | ``cryptodev-linux``. |
352 | 352 | ||
353 | - ``genext2fs`` - ``genext2fs`` is no longer used by the build system | 353 | - ``genext2fs`` --- ``genext2fs`` is no longer used by the build system |
354 | and is unmaintained upstream. | 354 | and is unmaintained upstream. |
355 | 355 | ||
356 | - ``js`` - This provided an ancient version of Mozilla's javascript | 356 | - ``js`` --- this provided an ancient version of Mozilla's javascript |
357 | engine that is no longer needed. | 357 | engine that is no longer needed. |
358 | 358 | ||
359 | - ``zaurusd`` - The recipe has been moved to the ``meta-handheld`` | 359 | - ``zaurusd`` --- the recipe has been moved to the ``meta-handheld`` |
360 | layer. | 360 | layer. |
361 | 361 | ||
362 | - ``eglibc 2.17`` - Replaced by the ``eglibc 2.19`` recipe. | 362 | - ``eglibc 2.17`` --- replaced by the ``eglibc 2.19`` recipe. |
363 | 363 | ||
364 | - ``gcc 4.7.2`` - Replaced by the now stable ``gcc 4.8.2``. | 364 | - ``gcc 4.7.2`` --- replaced by the now stable ``gcc 4.8.2``. |
365 | 365 | ||
366 | - ``external-sourcery-toolchain`` - this recipe is now maintained in | 366 | - ``external-sourcery-toolchain`` --- this recipe is now maintained in |
367 | the ``meta-sourcery`` layer. | 367 | the ``meta-sourcery`` layer. |
368 | 368 | ||
369 | - ``linux-libc-headers-yocto 3.4+git`` - Now using version 3.10 of the | 369 | - ``linux-libc-headers-yocto 3.4+git`` --- now using version 3.10 of the |
370 | ``linux-libc-headers`` by default. | 370 | ``linux-libc-headers`` by default. |
371 | 371 | ||
372 | - ``meta-toolchain-gmae`` - This recipe is obsolete. | 372 | - ``meta-toolchain-gmae`` --- this recipe is obsolete. |
373 | 373 | ||
374 | - ``packagegroup-core-sdk-gmae`` - This recipe is obsolete. | 374 | - ``packagegroup-core-sdk-gmae`` --- this recipe is obsolete. |
375 | 375 | ||
376 | - ``packagegroup-core-standalone-gmae-sdk-target`` - This recipe is | 376 | - ``packagegroup-core-standalone-gmae-sdk-target`` --- this recipe is |
377 | obsolete. | 377 | obsolete. |
378 | 378 | ||
379 | .. _migration-1.6-removed-classes: | 379 | .. _migration-1.6-removed-classes: |
diff --git a/documentation/migration-guides/migration-3.0.rst b/documentation/migration-guides/migration-3.0.rst index 1219edf921..96aea2f332 100644 --- a/documentation/migration-guides/migration-3.0.rst +++ b/documentation/migration-guides/migration-3.0.rst | |||
@@ -216,11 +216,11 @@ The following sanity check changes occurred. | |||
216 | - :term:`SRC_URI` is now checked for usage of two | 216 | - :term:`SRC_URI` is now checked for usage of two |
217 | problematic items: | 217 | problematic items: |
218 | 218 | ||
219 | - "${PN}" prefix/suffix use - Warnings always appear if ${PN} is | 219 | - "${PN}" prefix/suffix use --- warnings always appear if ${PN} is |
220 | used. You must fix the issue regardless of whether multiconfig or | 220 | used. You must fix the issue regardless of whether multiconfig or |
221 | anything else that would cause prefixing/suffixing to happen. | 221 | anything else that would cause prefixing/suffixing to happen. |
222 | 222 | ||
223 | - Github archive tarballs - these are not guaranteed to be stable. | 223 | - Github archive tarballs --- these are not guaranteed to be stable. |
224 | Consequently, it is likely that the tarballs will be refreshed and | 224 | Consequently, it is likely that the tarballs will be refreshed and |
225 | thus the SRC_URI checksums will fail to apply. It is recommended | 225 | thus the SRC_URI checksums will fail to apply. It is recommended |
226 | that you fetch either an official release tarball or a specific | 226 | that you fetch either an official release tarball or a specific |
diff --git a/documentation/migration-guides/migration-3.1.rst b/documentation/migration-guides/migration-3.1.rst index e3fdbbe425..cc788efeba 100644 --- a/documentation/migration-guides/migration-3.1.rst +++ b/documentation/migration-guides/migration-3.1.rst | |||
@@ -200,7 +200,7 @@ Packaging changes | |||
200 | ----------------- | 200 | ----------------- |
201 | 201 | ||
202 | - ``intltool`` has been removed from ``packagegroup-core-sdk`` as it is | 202 | - ``intltool`` has been removed from ``packagegroup-core-sdk`` as it is |
203 | rarely needed to build modern software - gettext can do most of the | 203 | rarely needed to build modern software --- gettext can do most of the |
204 | things it used to be needed for. ``intltool`` has also been removed | 204 | things it used to be needed for. ``intltool`` has also been removed |
205 | from ``packagegroup-core-self-hosted`` as it is not needed to for | 205 | from ``packagegroup-core-self-hosted`` as it is not needed to for |
206 | standard builds. | 206 | standard builds. |
diff --git a/documentation/migration-guides/migration-3.2.rst b/documentation/migration-guides/migration-3.2.rst index a376eced52..92b7f91f2c 100644 --- a/documentation/migration-guides/migration-3.2.rst +++ b/documentation/migration-guides/migration-3.2.rst | |||
@@ -23,7 +23,7 @@ Removed recipes | |||
23 | The following recipes have been removed: | 23 | The following recipes have been removed: |
24 | 24 | ||
25 | - ``bjam-native``: replaced by ``boost-build-native`` | 25 | - ``bjam-native``: replaced by ``boost-build-native`` |
26 | - ``avahi-ui``: folded into the main ``avahi`` recipe - the GTK UI can be disabled using :term:`PACKAGECONFIG` for ``avahi``. | 26 | - ``avahi-ui``: folded into the main ``avahi`` recipe --- the GTK UI can be disabled using :term:`PACKAGECONFIG` for ``avahi``. |
27 | - ``build-compare``: no longer needed with the removal of the ``packagefeed-stability`` class | 27 | - ``build-compare``: no longer needed with the removal of the ``packagefeed-stability`` class |
28 | - ``dhcp``: obsolete, functionally replaced by ``dhcpcd`` and ``kea`` | 28 | - ``dhcp``: obsolete, functionally replaced by ``dhcpcd`` and ``kea`` |
29 | - ``libmodulemd-v1``: replaced by ``libmodulemd`` | 29 | - ``libmodulemd-v1``: replaced by ``libmodulemd`` |
@@ -37,7 +37,7 @@ Removed classes | |||
37 | 37 | ||
38 | The following classes (.bbclass files) have been removed: | 38 | The following classes (.bbclass files) have been removed: |
39 | 39 | ||
40 | - ``spdx``: obsolete - the Yocto Project is a strong supporter of SPDX, but this class was old code using a dated approach and had the potential to be misleading. The ``meta-sdpxscanner`` layer is a much more modern and active approach to handling this and is recommended as a replacement. | 40 | - ``spdx``: obsolete --- the Yocto Project is a strong supporter of SPDX, but this class was old code using a dated approach and had the potential to be misleading. The ``meta-sdpxscanner`` layer is a much more modern and active approach to handling this and is recommended as a replacement. |
41 | 41 | ||
42 | - ``packagefeed-stability``: this class had become obsolete with the advent of hash equivalence and reproducible builds. | 42 | - ``packagefeed-stability``: this class had become obsolete with the advent of hash equivalence and reproducible builds. |
43 | 43 | ||
@@ -46,7 +46,7 @@ pseudo path filtering and mismatch behaviour | |||
46 | -------------------------------------------- | 46 | -------------------------------------------- |
47 | 47 | ||
48 | pseudo now operates on a filtered subset of files. This is a significant change | 48 | pseudo now operates on a filtered subset of files. This is a significant change |
49 | to the way pseudo operates within OpenEmbedded - by default, pseudo monitors and | 49 | to the way pseudo operates within OpenEmbedded --- by default, pseudo monitors and |
50 | logs (adds to its database) any file created or modified whilst in a ``fakeroot`` | 50 | logs (adds to its database) any file created or modified whilst in a ``fakeroot`` |
51 | environment. However, there are large numbers of files that we simply don't care | 51 | environment. However, there are large numbers of files that we simply don't care |
52 | about the permissions of whilst in that ``fakeroot`` context, for example ${:term:`S`}, ${:term:`B`}, ${:term:`T`}, | 52 | about the permissions of whilst in that ``fakeroot`` context, for example ${:term:`S`}, ${:term:`B`}, ${:term:`T`}, |
@@ -68,7 +68,7 @@ structure above that subdirectory. For these types of cases in your own recipes, | |||
68 | extend :term:`PSEUDO_IGNORE_PATHS` to cover additional paths that pseudo should not | 68 | extend :term:`PSEUDO_IGNORE_PATHS` to cover additional paths that pseudo should not |
69 | be monitoring. | 69 | be monitoring. |
70 | 70 | ||
71 | In addition, pseudo's behaviour on mismatches has now been changed - rather | 71 | In addition, pseudo's behaviour on mismatches has now been changed --- rather |
72 | than doing what turns out to be a rather dangerous "fixup" if it sees a file | 72 | than doing what turns out to be a rather dangerous "fixup" if it sees a file |
73 | with a different path but the same inode as another file it has previously seen, | 73 | with a different path but the same inode as another file it has previously seen, |
74 | pseudo will throw an ``abort()`` and direct you to a :yocto_wiki:`wiki page </Pseudo_Abort>` | 74 | pseudo will throw an ``abort()`` and direct you to a :yocto_wiki:`wiki page </Pseudo_Abort>` |
@@ -137,10 +137,10 @@ DHCP server/client replaced | |||
137 | 137 | ||
138 | The ``dhcp`` software package has become unmaintained and thus has been | 138 | The ``dhcp`` software package has become unmaintained and thus has been |
139 | functionally replaced by ``dhcpcd`` (client) and ``kea`` (server). You will | 139 | functionally replaced by ``dhcpcd`` (client) and ``kea`` (server). You will |
140 | need to replace references to the recipe/package names as appropriate - most | 140 | need to replace references to the recipe/package names as appropriate --- most |
141 | commonly, at the package level ``dhcp-client`` should be replaced by | 141 | commonly, at the package level ``dhcp-client`` should be replaced by |
142 | ``dhcpcd`` and ``dhcp-server`` should be replaced by ``kea``. If you have any | 142 | ``dhcpcd`` and ``dhcp-server`` should be replaced by ``kea``. If you have any |
143 | custom configuration files for these they will need to be adapted - refer to | 143 | custom configuration files for these they will need to be adapted --- refer to |
144 | the upstream documentation for ``dhcpcd`` and ``kea`` for further details. | 144 | the upstream documentation for ``dhcpcd`` and ``kea`` for further details. |
145 | 145 | ||
146 | 146 | ||
@@ -181,7 +181,7 @@ In addition, the following new checks were added and default to triggering an er | |||
181 | 181 | ||
182 | - :ref:`missing-update-alternatives <qa-check-missing-update-alternatives>`: Check if the recipe sets the :term:`ALTERNATIVE` variable for any of its packages, and does not inherit the :ref:`update-alternatives <ref-classes-update-alternatives>` class. | 182 | - :ref:`missing-update-alternatives <qa-check-missing-update-alternatives>`: Check if the recipe sets the :term:`ALTERNATIVE` variable for any of its packages, and does not inherit the :ref:`update-alternatives <ref-classes-update-alternatives>` class. |
183 | 183 | ||
184 | - A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B` will now trigger a warning so that they can be removed and path comparisons can be more reliable - remove any instances of these in your recipes if the warning is displayed. | 184 | - A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B` will now trigger a warning so that they can be removed and path comparisons can be more reliable --- remove any instances of these in your recipes if the warning is displayed. |
185 | 185 | ||
186 | 186 | ||
187 | .. _migration-3.2-src-uri-file-globbing: | 187 | .. _migration-3.2-src-uri-file-globbing: |
@@ -209,7 +209,7 @@ deploy class now cleans ``DEPLOYDIR`` before ``do_deploy`` | |||
209 | 209 | ||
210 | ``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds. | 210 | ``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds. |
211 | 211 | ||
212 | Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` - these should be refactored to use ``do_deploy_prepend`` instead. | 212 | Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead. |
213 | 213 | ||
214 | 214 | ||
215 | .. _migration-3.2-nativesdk-sdk-provides-dummy: | 215 | .. _migration-3.2-nativesdk-sdk-provides-dummy: |
@@ -303,7 +303,7 @@ now need to be changed to ``inherit image-artifact-names``. | |||
303 | Miscellaneous changes | 303 | Miscellaneous changes |
304 | --------------------- | 304 | --------------------- |
305 | 305 | ||
306 | - Support for the long-deprecated ``PACKAGE_GROUP`` variable has now been removed - replace any remaining instances with :term:`FEATURE_PACKAGES`. | 306 | - Support for the long-deprecated ``PACKAGE_GROUP`` variable has now been removed --- replace any remaining instances with :term:`FEATURE_PACKAGES`. |
307 | - The ``FILESPATHPKG`` variable, having been previously deprecated, has now been removed. Replace any remaining references with appropriate use of :term:`FILESEXTRAPATHS`. | 307 | - The ``FILESPATHPKG`` variable, having been previously deprecated, has now been removed. Replace any remaining references with appropriate use of :term:`FILESEXTRAPATHS`. |
308 | - Erroneous use of ``inherit +=`` (instead of ``INHERIT +=``) in a configuration file now triggers an error instead of silently being ignored. | 308 | - Erroneous use of ``inherit +=`` (instead of ``INHERIT +=``) in a configuration file now triggers an error instead of silently being ignored. |
309 | - ptest support has been removed from the ``kbd`` recipe, as upstream has moved to autotest which is difficult to work with in a cross-compilation environment. | 309 | - ptest support has been removed from the ``kbd`` recipe, as upstream has moved to autotest which is difficult to work with in a cross-compilation environment. |
diff --git a/documentation/migration-guides/migration-3.3.rst b/documentation/migration-guides/migration-3.3.rst index d65f1c7b1f..aba5c4237c 100644 --- a/documentation/migration-guides/migration-3.3.rst +++ b/documentation/migration-guides/migration-3.3.rst | |||
@@ -13,11 +13,10 @@ Minimum system requirements | |||
13 | You will now need at least Python 3.6 installed on your build host. Most recent | 13 | You will now need at least Python 3.6 installed on your build host. Most recent |
14 | distributions provide this, but should you be building on a distribution that | 14 | distributions provide this, but should you be building on a distribution that |
15 | does not have it, you can use the ``buildtools-tarball`` (easily installable | 15 | does not have it, you can use the ``buildtools-tarball`` (easily installable |
16 | using ``scripts/install-buildtools``) - see | 16 | using ``scripts/install-buildtools``) --- see |
17 | :ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions` | 17 | :ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions` |
18 | for details. | 18 | for details. |
19 | 19 | ||
20 | |||
21 | .. _migration-3.3-removed-recipes: | 20 | .. _migration-3.3-removed-recipes: |
22 | 21 | ||
23 | Removed recipes | 22 | Removed recipes |
diff --git a/documentation/migration-guides/migration-3.4.rst b/documentation/migration-guides/migration-3.4.rst index 8db43a1454..c55c0b8c3c 100644 --- a/documentation/migration-guides/migration-3.4.rst +++ b/documentation/migration-guides/migration-3.4.rst | |||
@@ -146,7 +146,7 @@ Virtual runtime provides | |||
146 | ~~~~~~~~~~~~~~~~~~~~~~~~ | 146 | ~~~~~~~~~~~~~~~~~~~~~~~~ |
147 | 147 | ||
148 | Recipes shouldn't use the ``virtual/`` string in :term:`RPROVIDES` and | 148 | Recipes shouldn't use the ``virtual/`` string in :term:`RPROVIDES` and |
149 | :term:`RDEPENDS` - it is confusing because ``virtual/`` has no special | 149 | :term:`RDEPENDS` --- it is confusing because ``virtual/`` has no special |
150 | meaning in :term:`RPROVIDES` and :term:`RDEPENDS` (unlike in the | 150 | meaning in :term:`RPROVIDES` and :term:`RDEPENDS` (unlike in the |
151 | corresponding build-time :term:`PROVIDES` and :term:`DEPENDS`). | 151 | corresponding build-time :term:`PROVIDES` and :term:`DEPENDS`). |
152 | 152 | ||
@@ -171,7 +171,7 @@ Extensible SDK host extension | |||
171 | For a normal SDK, some layers append to :term:`TOOLCHAIN_HOST_TASK` | 171 | For a normal SDK, some layers append to :term:`TOOLCHAIN_HOST_TASK` |
172 | unconditionally which is fine, until the eSDK tries to override the | 172 | unconditionally which is fine, until the eSDK tries to override the |
173 | variable to its own values. Instead of installing packages specified | 173 | variable to its own values. Instead of installing packages specified |
174 | in this variable it uses native recipes instead - a very different | 174 | in this variable it uses native recipes instead --- a very different |
175 | approach. This has led to confusing errors when binaries are added | 175 | approach. This has led to confusing errors when binaries are added |
176 | to the SDK but not relocated. | 176 | to the SDK but not relocated. |
177 | 177 | ||
diff --git a/documentation/migration-guides/release-notes-3.4.rst b/documentation/migration-guides/release-notes-3.4.rst index 5a8fb4b5a9..323e4df7ae 100644 --- a/documentation/migration-guides/release-notes-3.4.rst +++ b/documentation/migration-guides/release-notes-3.4.rst | |||
@@ -5,7 +5,7 @@ New Features / Enhancements in 3.4 | |||
5 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 5 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
6 | 6 | ||
7 | - Linux kernel 5.14, glibc 2.34 and ~280 other recipe upgrades | 7 | - Linux kernel 5.14, glibc 2.34 and ~280 other recipe upgrades |
8 | - Switched override character to ':' (replacing '_') for more robust parsing and improved performance - see the above migration guide for help | 8 | - Switched override character to ':' (replacing '_') for more robust parsing and improved performance --- see the above migration guide for help |
9 | - Rust integrated into core, providing rust support for cross-compilation and SDK | 9 | - Rust integrated into core, providing rust support for cross-compilation and SDK |
10 | - New create-spdx class for creating SPDX SBoM documents | 10 | - New create-spdx class for creating SPDX SBoM documents |
11 | - New recipes: cargo, core-image-ptest-all, core-image-ptest-fast, core-image-weston-sdk, erofs-utils, gcompat, gi-docgen, libmicrohttpd, libseccomp, libstd-rs, perlcross, python3-markdown, python3-pyyaml, python3-smartypants, python3-typogrify, rust, rust-cross, rust-cross-canadian, rust-hello-world, rust-llvm, rust-tools-cross-canadian, rustfmt, xwayland | 11 | - New recipes: cargo, core-image-ptest-all, core-image-ptest-fast, core-image-weston-sdk, erofs-utils, gcompat, gi-docgen, libmicrohttpd, libseccomp, libstd-rs, perlcross, python3-markdown, python3-pyyaml, python3-smartypants, python3-typogrify, rust, rust-cross, rust-cross-canadian, rust-hello-world, rust-llvm, rust-tools-cross-canadian, rustfmt, xwayland |
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst index 016577e07e..83339da98f 100644 --- a/documentation/overview-manual/concepts.rst +++ b/documentation/overview-manual/concepts.rst | |||
@@ -557,7 +557,7 @@ Local Projects | |||
557 | ~~~~~~~~~~~~~~ | 557 | ~~~~~~~~~~~~~~ |
558 | 558 | ||
559 | Local projects are custom bits of software the user provides. These bits | 559 | Local projects are custom bits of software the user provides. These bits |
560 | reside somewhere local to a project - perhaps a directory into which the | 560 | reside somewhere local to a project --- perhaps a directory into which the |
561 | user checks in items (e.g. a local directory containing a development | 561 | user checks in items (e.g. a local directory containing a development |
562 | source tree used by the group). | 562 | source tree used by the group). |
563 | 563 | ||
@@ -1641,7 +1641,7 @@ you a good idea of when the task's data changes. | |||
1641 | 1641 | ||
1642 | To complicate the problem, there are things that should not be included | 1642 | To complicate the problem, there are things that should not be included |
1643 | in the checksum. First, there is the actual specific build path of a | 1643 | in the checksum. First, there is the actual specific build path of a |
1644 | given task - the :term:`WORKDIR`. It | 1644 | given task --- the :term:`WORKDIR`. It |
1645 | does not matter if the work directory changes because it should not | 1645 | does not matter if the work directory changes because it should not |
1646 | affect the output for target packages. Also, the build process has the | 1646 | affect the output for target packages. Also, the build process has the |
1647 | objective of making native or cross packages relocatable. | 1647 | objective of making native or cross packages relocatable. |
@@ -1700,7 +1700,7 @@ need to fix this situation. | |||
1700 | Thus far, this section has limited discussion to the direct inputs into | 1700 | Thus far, this section has limited discussion to the direct inputs into |
1701 | a task. Information based on direct inputs is referred to as the | 1701 | a task. Information based on direct inputs is referred to as the |
1702 | "basehash" in the code. However, the question of a task's indirect | 1702 | "basehash" in the code. However, the question of a task's indirect |
1703 | inputs still exits - items already built and present in the | 1703 | inputs still exits --- items already built and present in the |
1704 | :term:`Build Directory`. The checksum (or | 1704 | :term:`Build Directory`. The checksum (or |
1705 | signature) for a particular task needs to add the hashes of all the | 1705 | signature) for a particular task needs to add the hashes of all the |
1706 | tasks on which the particular task depends. Choosing which dependencies | 1706 | tasks on which the particular task depends. Choosing which dependencies |
diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst index f1001e0bd3..43a6f1b480 100644 --- a/documentation/overview-manual/development-environment.rst +++ b/documentation/overview-manual/development-environment.rst | |||
@@ -52,7 +52,7 @@ A development host or :term:`Build Host` is key to | |||
52 | using the Yocto Project. Because the goal of the Yocto Project is to | 52 | using the Yocto Project. Because the goal of the Yocto Project is to |
53 | develop images or applications that run on embedded hardware, | 53 | develop images or applications that run on embedded hardware, |
54 | development of those images and applications generally takes place on a | 54 | development of those images and applications generally takes place on a |
55 | system not intended to run the software - the development host. | 55 | system not intended to run the software --- the development host. |
56 | 56 | ||
57 | You need to set up a development host in order to use it with the Yocto | 57 | You need to set up a development host in order to use it with the Yocto |
58 | Project. Most find that it is best to have a native Linux machine | 58 | Project. Most find that it is best to have a native Linux machine |
diff --git a/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst index a2e0862459..4e3b7c3250 100644 --- a/documentation/overview-manual/yp-intro.rst +++ b/documentation/overview-manual/yp-intro.rst | |||
@@ -842,7 +842,7 @@ helpful for getting started: | |||
842 | distribution. | 842 | distribution. |
843 | 843 | ||
844 | Another point worth noting is that historically within the Yocto | 844 | Another point worth noting is that historically within the Yocto |
845 | Project, recipes were referred to as packages - thus, the existence | 845 | Project, recipes were referred to as packages --- thus, the existence |
846 | of several BitBake variables that are seemingly mis-named, (e.g. | 846 | of several BitBake variables that are seemingly mis-named, (e.g. |
847 | :term:`PR`, | 847 | :term:`PR`, |
848 | :term:`PV`, and | 848 | :term:`PV`, and |
diff --git a/documentation/profile-manual/intro.rst b/documentation/profile-manual/intro.rst index 9c8fa3dbfa..e9208dfde8 100644 --- a/documentation/profile-manual/intro.rst +++ b/documentation/profile-manual/intro.rst | |||
@@ -7,7 +7,7 @@ Yocto Project Profiling and Tracing Manual | |||
7 | Introduction | 7 | Introduction |
8 | ============ | 8 | ============ |
9 | 9 | ||
10 | Yocto bundles a number of tracing and profiling tools - this 'HOWTO' | 10 | Yocto bundles a number of tracing and profiling tools --- this 'HOWTO' |
11 | describes their basic usage and shows by example how to make use of them | 11 | describes their basic usage and shows by example how to make use of them |
12 | to examine application and system behavior. | 12 | to examine application and system behavior. |
13 | 13 | ||
@@ -26,7 +26,7 @@ please see the documentation and/or websites listed for each tool. | |||
26 | 26 | ||
27 | The final section of this 'HOWTO' is a collection of real-world examples | 27 | The final section of this 'HOWTO' is a collection of real-world examples |
28 | which we'll be continually adding to as we solve more problems using the | 28 | which we'll be continually adding to as we solve more problems using the |
29 | tools - feel free to add your own examples to the list! | 29 | tools --- feel free to add your own examples to the list! |
30 | 30 | ||
31 | General Setup | 31 | General Setup |
32 | ============= | 32 | ============= |
diff --git a/documentation/profile-manual/usage.rst b/documentation/profile-manual/usage.rst index 0ff9d921fd..49f8af4a74 100644 --- a/documentation/profile-manual/usage.rst +++ b/documentation/profile-manual/usage.rst | |||
@@ -17,7 +17,7 @@ The 'perf' tool is the profiling and tracing tool that comes bundled | |||
17 | with the Linux kernel. | 17 | with the Linux kernel. |
18 | 18 | ||
19 | Don't let the fact that it's part of the kernel fool you into thinking | 19 | Don't let the fact that it's part of the kernel fool you into thinking |
20 | that it's only for tracing and profiling the kernel - you can indeed use | 20 | that it's only for tracing and profiling the kernel --- you can indeed use |
21 | it to trace and profile just the kernel, but you can also use it to | 21 | it to trace and profile just the kernel, but you can also use it to |
22 | profile specific applications separately (with or without kernel | 22 | profile specific applications separately (with or without kernel |
23 | context), and you can also use it to trace and profile the kernel and | 23 | context), and you can also use it to trace and profile the kernel and |
@@ -176,7 +176,7 @@ interactive text-based UI (or simply as text if we specify ``--stdio`` to | |||
176 | 176 | ||
177 | As our first attempt at profiling this workload, we'll simply run 'perf | 177 | As our first attempt at profiling this workload, we'll simply run 'perf |
178 | record', handing it the workload we want to profile (everything after | 178 | record', handing it the workload we want to profile (everything after |
179 | 'perf record' and any perf options we hand it - here none - will be | 179 | 'perf record' and any perf options we hand it --- here none, will be |
180 | executed in a new shell). perf collects samples until the process exits | 180 | executed in a new shell). perf collects samples until the process exits |
181 | and records them in a file named 'perf.data' in the current working | 181 | and records them in a file named 'perf.data' in the current working |
182 | directory. :: | 182 | directory. :: |
@@ -203,7 +203,7 @@ The above screenshot displays a 'flat' profile, one entry for each | |||
203 | 'bucket' corresponding to the functions that were profiled during the | 203 | 'bucket' corresponding to the functions that were profiled during the |
204 | profiling run, ordered from the most popular to the least (perf has | 204 | profiling run, ordered from the most popular to the least (perf has |
205 | options to sort in various orders and keys as well as display entries | 205 | options to sort in various orders and keys as well as display entries |
206 | only above a certain threshold and so on - see the perf documentation | 206 | only above a certain threshold and so on --- see the perf documentation |
207 | for details). Note that this includes both userspace functions (entries | 207 | for details). Note that this includes both userspace functions (entries |
208 | containing a [.]) and kernel functions accounted to the process (entries | 208 | containing a [.]) and kernel functions accounted to the process (entries |
209 | containing a [k]). (perf has command-line modifiers that can be used to | 209 | containing a [k]). (perf has command-line modifiers that can be used to |
@@ -608,7 +608,7 @@ and tell perf to do a profile using it as the sampling event:: | |||
608 | The screenshot above shows the results of running a profile using | 608 | The screenshot above shows the results of running a profile using |
609 | sched:sched_switch tracepoint, which shows the relative costs of various | 609 | sched:sched_switch tracepoint, which shows the relative costs of various |
610 | paths to sched_wakeup (note that sched_wakeup is the name of the | 610 | paths to sched_wakeup (note that sched_wakeup is the name of the |
611 | tracepoint - it's actually defined just inside ttwu_do_wakeup(), which | 611 | tracepoint --- it's actually defined just inside ttwu_do_wakeup(), which |
612 | accounts for the function name actually displayed in the profile: | 612 | accounts for the function name actually displayed in the profile: |
613 | 613 | ||
614 | .. code-block:: c | 614 | .. code-block:: c |
@@ -877,7 +877,7 @@ System-Wide Tracing and Profiling | |||
877 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 877 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
878 | 878 | ||
879 | The examples so far have focused on tracing a particular program or | 879 | The examples so far have focused on tracing a particular program or |
880 | workload - in other words, every profiling run has specified the program | 880 | workload --- in other words, every profiling run has specified the program |
881 | to profile in the command-line e.g. 'perf record wget ...'. | 881 | to profile in the command-line e.g. 'perf record wget ...'. |
882 | 882 | ||
883 | It's also possible, and more interesting in many cases, to run a | 883 | It's also possible, and more interesting in many cases, to run a |
@@ -964,7 +964,7 @@ Filtering | |||
964 | Notice that there are a lot of events that don't really have anything to | 964 | Notice that there are a lot of events that don't really have anything to |
965 | do with what we're interested in, namely events that schedule 'perf' | 965 | do with what we're interested in, namely events that schedule 'perf' |
966 | itself in and out or that wake perf up. We can get rid of those by using | 966 | itself in and out or that wake perf up. We can get rid of those by using |
967 | the '--filter' option - for each event we specify using -e, we can add a | 967 | the '--filter' option --- for each event we specify using -e, we can add a |
968 | --filter after that to filter out trace events that contain fields with | 968 | --filter after that to filter out trace events that contain fields with |
969 | specific values:: | 969 | specific values:: |
970 | 970 | ||
@@ -1135,7 +1135,7 @@ callgraphs from starting a few programs during those 30 seconds: | |||
1135 | .. admonition:: Tying it Together | 1135 | .. admonition:: Tying it Together |
1136 | 1136 | ||
1137 | The trace events subsystem accommodate static and dynamic tracepoints | 1137 | The trace events subsystem accommodate static and dynamic tracepoints |
1138 | in exactly the same way - there's no difference as far as the | 1138 | in exactly the same way --- there's no difference as far as the |
1139 | infrastructure is concerned. See the ftrace section for more details | 1139 | infrastructure is concerned. See the ftrace section for more details |
1140 | on the trace event subsystem. | 1140 | on the trace event subsystem. |
1141 | 1141 | ||
@@ -1201,7 +1201,7 @@ For this section, we'll assume you've already performed the basic setup | |||
1201 | outlined in the ":ref:`profile-manual/intro:General Setup`" section. | 1201 | outlined in the ":ref:`profile-manual/intro:General Setup`" section. |
1202 | 1202 | ||
1203 | ftrace, trace-cmd, and kernelshark run on the target system, and are | 1203 | ftrace, trace-cmd, and kernelshark run on the target system, and are |
1204 | ready to go out-of-the-box - no additional setup is necessary. For the | 1204 | ready to go out-of-the-box --- no additional setup is necessary. For the |
1205 | rest of this section we assume you've ssh'ed to the host and will be | 1205 | rest of this section we assume you've ssh'ed to the host and will be |
1206 | running ftrace on the target. kernelshark is a GUI application and if | 1206 | running ftrace on the target. kernelshark is a GUI application and if |
1207 | you use the '-X' option to ssh you can have the kernelshark GUI run on | 1207 | you use the '-X' option to ssh you can have the kernelshark GUI run on |
@@ -1321,7 +1321,7 @@ great way to learn about how the kernel code works in a dynamic sense. | |||
1321 | ftrace:function tracepoint. | 1321 | ftrace:function tracepoint. |
1322 | 1322 | ||
1323 | It is a little more difficult to follow the call chains than it needs to | 1323 | It is a little more difficult to follow the call chains than it needs to |
1324 | be - luckily there's a variant of the function tracer that displays the | 1324 | be --- luckily there's a variant of the function tracer that displays the |
1325 | callchains explicitly, called the 'function_graph' tracer:: | 1325 | callchains explicitly, called the 'function_graph' tracer:: |
1326 | 1326 | ||
1327 | root@sugarbay:/sys/kernel/debug/tracing# echo function_graph > current_tracer | 1327 | root@sugarbay:/sys/kernel/debug/tracing# echo function_graph > current_tracer |
@@ -2138,7 +2138,7 @@ You can now view the trace in text form on the target:: | |||
2138 | . | 2138 | . |
2139 | 2139 | ||
2140 | You can now safely destroy the trace | 2140 | You can now safely destroy the trace |
2141 | session (note that this doesn't delete the trace - it's still there in | 2141 | session (note that this doesn't delete the trace --- it's still there in |
2142 | ~/lttng-traces):: | 2142 | ~/lttng-traces):: |
2143 | 2143 | ||
2144 | root@crownbay:~# lttng destroy | 2144 | root@crownbay:~# lttng destroy |
@@ -2222,7 +2222,7 @@ You can now view the trace in text form on the target:: | |||
2222 | . | 2222 | . |
2223 | 2223 | ||
2224 | You can now safely destroy the trace session (note that this doesn't delete the | 2224 | You can now safely destroy the trace session (note that this doesn't delete the |
2225 | trace - it's still there in ~/lttng-traces):: | 2225 | trace --- it's still there in ~/lttng-traces):: |
2226 | 2226 | ||
2227 | root@crownbay:~# lttng destroy | 2227 | root@crownbay:~# lttng destroy |
2228 | Session auto-20190303-021943 destroyed at /home/root | 2228 | Session auto-20190303-021943 destroyed at /home/root |
@@ -2557,7 +2557,7 @@ Execute the workload you're interested in:: | |||
2557 | root@crownbay:/sys/kernel/debug/tracing# cat /media/sdc/testfile.txt | 2557 | root@crownbay:/sys/kernel/debug/tracing# cat /media/sdc/testfile.txt |
2558 | 2558 | ||
2559 | And look at the output (note here that we're using 'trace_pipe' instead of | 2559 | And look at the output (note here that we're using 'trace_pipe' instead of |
2560 | trace to capture this trace - this allows us to wait around on the pipe | 2560 | trace to capture this trace --- this allows us to wait around on the pipe |
2561 | for data to appear):: | 2561 | for data to appear):: |
2562 | 2562 | ||
2563 | root@crownbay:/sys/kernel/debug/tracing# cat trace_pipe | 2563 | root@crownbay:/sys/kernel/debug/tracing# cat trace_pipe |
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst index 729aa259e0..d0ed539229 100644 --- a/documentation/ref-manual/classes.rst +++ b/documentation/ref-manual/classes.rst | |||
@@ -108,18 +108,18 @@ support is either not present or is broken. | |||
108 | It's useful to have some idea of how the tasks defined by the | 108 | It's useful to have some idea of how the tasks defined by the |
109 | ``autotools*`` classes work and what they do behind the scenes. | 109 | ``autotools*`` classes work and what they do behind the scenes. |
110 | 110 | ||
111 | - :ref:`ref-tasks-configure` - Regenerates the | 111 | - :ref:`ref-tasks-configure` --- regenerates the |
112 | configure script (using ``autoreconf``) and then launches it with a | 112 | configure script (using ``autoreconf``) and then launches it with a |
113 | standard set of arguments used during cross-compilation. You can pass | 113 | standard set of arguments used during cross-compilation. You can pass |
114 | additional parameters to ``configure`` through the :term:`EXTRA_OECONF` | 114 | additional parameters to ``configure`` through the :term:`EXTRA_OECONF` |
115 | or :term:`PACKAGECONFIG_CONFARGS` | 115 | or :term:`PACKAGECONFIG_CONFARGS` |
116 | variables. | 116 | variables. |
117 | 117 | ||
118 | - :ref:`ref-tasks-compile` - Runs ``make`` with | 118 | - :ref:`ref-tasks-compile` --- runs ``make`` with |
119 | arguments that specify the compiler and linker. You can pass | 119 | arguments that specify the compiler and linker. You can pass |
120 | additional arguments through the :term:`EXTRA_OEMAKE` variable. | 120 | additional arguments through the :term:`EXTRA_OEMAKE` variable. |
121 | 121 | ||
122 | - :ref:`ref-tasks-install` - Runs ``make install`` and | 122 | - :ref:`ref-tasks-install` --- runs ``make install`` and |
123 | passes in ``${``\ :term:`D`\ ``}`` as ``DESTDIR``. | 123 | passes in ``${``\ :term:`D`\ ``}`` as ``DESTDIR``. |
124 | 124 | ||
125 | .. _ref-classes-base: | 125 | .. _ref-classes-base: |
diff --git a/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst index 10ca70a2b3..997ec0351c 100644 --- a/documentation/ref-manual/devtool-reference.rst +++ b/documentation/ref-manual/devtool-reference.rst | |||
@@ -164,7 +164,7 @@ Adding a New Recipe to the Workspace Layer | |||
164 | ========================================== | 164 | ========================================== |
165 | 165 | ||
166 | Use the ``devtool add`` command to add a new recipe to the workspace | 166 | Use the ``devtool add`` command to add a new recipe to the workspace |
167 | layer. The recipe you add should not exist - ``devtool`` creates it for | 167 | layer. The recipe you add should not exist --- ``devtool`` creates it for |
168 | you. The source files the recipe uses should exist in an external area. | 168 | you. The source files the recipe uses should exist in an external area. |
169 | 169 | ||
170 | The following example creates and adds a new recipe named ``jackson`` to | 170 | The following example creates and adds a new recipe named ``jackson`` to |
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst index 3eee9e1be5..2fcbf7da96 100644 --- a/documentation/ref-manual/faq.rst +++ b/documentation/ref-manual/faq.rst | |||
@@ -364,7 +364,7 @@ redirect requests through proxy servers. | |||
364 | 364 | ||
365 | **Q:** Can I get rid of build output so I can start over? | 365 | **Q:** Can I get rid of build output so I can start over? |
366 | 366 | ||
367 | **A:** Yes - you can easily do this. When you use BitBake to build an | 367 | **A:** Yes --- you can easily do this. When you use BitBake to build an |
368 | image, all the build output goes into the directory created when you run | 368 | image, all the build output goes into the directory created when you run |
369 | the build environment setup script (i.e. | 369 | the build environment setup script (i.e. |
370 | :ref:`structure-core-script`). By default, this :term:`Build Directory` | 370 | :ref:`structure-core-script`). By default, this :term:`Build Directory` |
@@ -428,7 +428,7 @@ relatively normal and the second is not: | |||
428 | build/tmp/sysroots/x86_64-linux/usr/bin | 428 | build/tmp/sysroots/x86_64-linux/usr/bin |
429 | 429 | ||
430 | Even if the paths look unusual, | 430 | Even if the paths look unusual, |
431 | they both are correct - the first for a target and the second for a | 431 | they both are correct --- the first for a target and the second for a |
432 | native recipe. These paths are a consequence of the ``DESTDIR`` | 432 | native recipe. These paths are a consequence of the ``DESTDIR`` |
433 | mechanism and while they appear strange, they are correct and in | 433 | mechanism and while they appear strange, they are correct and in |
434 | practice very effective. | 434 | practice very effective. |
diff --git a/documentation/ref-manual/qa-checks.rst b/documentation/ref-manual/qa-checks.rst index 8c475d0f72..fbab1dc92e 100644 --- a/documentation/ref-manual/qa-checks.rst +++ b/documentation/ref-manual/qa-checks.rst | |||
@@ -613,7 +613,7 @@ Errors and Warnings | |||
613 | so using ${:term:`BPN`} rather than ${:term:`PN`} as the latter will change | 613 | so using ${:term:`BPN`} rather than ${:term:`PN`} as the latter will change |
614 | for different variants of the same recipe e.g. when :term:`BBCLASSEXTEND` | 614 | for different variants of the same recipe e.g. when :term:`BBCLASSEXTEND` |
615 | or multilib are being used. This check will fail if a reference to ``${PN}`` | 615 | or multilib are being used. This check will fail if a reference to ``${PN}`` |
616 | is found within the :term:`SRC_URI` value - change it to ``${BPN}`` instead. | 616 | is found within the :term:`SRC_URI` value --- change it to ``${BPN}`` instead. |
617 | 617 | ||
618 | 618 | ||
619 | .. _qa-check-unhandled-features-check: | 619 | .. _qa-check-unhandled-features-check: |
@@ -727,7 +727,7 @@ Errors and Warnings | |||
727 | devtool modify <recipe> | 727 | devtool modify <recipe> |
728 | 728 | ||
729 | This will apply all of the patches, and create new commits out of them in | 729 | This will apply all of the patches, and create new commits out of them in |
730 | the workspace - with the patch context updated. | 730 | the workspace --- with the patch context updated. |
731 | 731 | ||
732 | Then, replace the patches in the recipe layer:: | 732 | Then, replace the patches in the recipe layer:: |
733 | 733 | ||
diff --git a/documentation/ref-manual/resources.rst b/documentation/ref-manual/resources.rst index c942384662..292a9d6f61 100644 --- a/documentation/ref-manual/resources.rst +++ b/documentation/ref-manual/resources.rst | |||
@@ -64,22 +64,22 @@ and announcements. To subscribe to one of the following mailing lists, | |||
64 | click on the appropriate URL in the following list and follow the | 64 | click on the appropriate URL in the following list and follow the |
65 | instructions: | 65 | instructions: |
66 | 66 | ||
67 | - :yocto_lists:`/g/yocto` - General Yocto Project | 67 | - :yocto_lists:`/g/yocto` --- general Yocto Project |
68 | discussion mailing list. | 68 | discussion mailing list. |
69 | 69 | ||
70 | - :oe_lists:`/g/openembedded-core` - Discussion mailing | 70 | - :oe_lists:`/g/openembedded-core` --- discussion mailing |
71 | list about OpenEmbedded-Core (the core metadata). | 71 | list about OpenEmbedded-Core (the core metadata). |
72 | 72 | ||
73 | - :oe_lists:`/g/openembedded-devel` - Discussion | 73 | - :oe_lists:`/g/openembedded-devel` --- discussion |
74 | mailing list about OpenEmbedded. | 74 | mailing list about OpenEmbedded. |
75 | 75 | ||
76 | - :oe_lists:`/g/bitbake-devel` - Discussion mailing | 76 | - :oe_lists:`/g/bitbake-devel` --- discussion mailing |
77 | list about the :term:`BitBake` build tool. | 77 | list about the :term:`BitBake` build tool. |
78 | 78 | ||
79 | - :yocto_lists:`/g/poky` - Discussion mailing list | 79 | - :yocto_lists:`/g/poky` --- discussion mailing list |
80 | about :term:`Poky`. | 80 | about :term:`Poky`. |
81 | 81 | ||
82 | - :yocto_lists:`/g/yocto-announce` - Mailing list to | 82 | - :yocto_lists:`/g/yocto-announce` --- mailing list to |
83 | receive official Yocto Project release and milestone announcements. | 83 | receive official Yocto Project release and milestone announcements. |
84 | 84 | ||
85 | For more Yocto Project-related mailing lists, see the | 85 | For more Yocto Project-related mailing lists, see the |
diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst index 12a085552f..bdcffc1947 100644 --- a/documentation/ref-manual/structure.rst +++ b/documentation/ref-manual/structure.rst | |||
@@ -213,8 +213,8 @@ These files are standard top-level files. | |||
213 | 213 | ||
214 | .. _structure-build: | 214 | .. _structure-build: |
215 | 215 | ||
216 | The Build Directory - ``build/`` | 216 | The Build Directory --- ``build/`` |
217 | ================================ | 217 | ================================== |
218 | 218 | ||
219 | The OpenEmbedded build system creates the :term:`Build Directory` | 219 | The OpenEmbedded build system creates the :term:`Build Directory` |
220 | when you run the build environment setup | 220 | when you run the build environment setup |
@@ -589,7 +589,7 @@ install" places its output that is then split into sub-packages within | |||
589 | ``build/tmp/work/tunearch/recipename/version/`` | 589 | ``build/tmp/work/tunearch/recipename/version/`` |
590 | ----------------------------------------------- | 590 | ----------------------------------------------- |
591 | 591 | ||
592 | The recipe work directory - ``${WORKDIR}``. | 592 | The recipe work directory --- ``${WORKDIR}``. |
593 | 593 | ||
594 | As described earlier in the | 594 | As described earlier in the |
595 | ":ref:`structure-build-tmp-sysroots`" section, | 595 | ":ref:`structure-build-tmp-sysroots`" section, |
@@ -654,8 +654,8 @@ recipes. In practice, this is only used for ``gcc`` and its variants | |||
654 | 654 | ||
655 | .. _structure-meta: | 655 | .. _structure-meta: |
656 | 656 | ||
657 | The Metadata - ``meta/`` | 657 | The Metadata --- ``meta/`` |
658 | ======================== | 658 | ========================== |
659 | 659 | ||
660 | As mentioned previously, :term:`Metadata` is the core of the | 660 | As mentioned previously, :term:`Metadata` is the core of the |
661 | Yocto Project. Metadata has several important subdivisions: | 661 | Yocto Project. Metadata has several important subdivisions: |
diff --git a/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst index 512032a67e..1e3f718a8f 100644 --- a/documentation/ref-manual/terms.rst +++ b/documentation/ref-manual/terms.rst | |||
@@ -270,7 +270,7 @@ universal, the list includes them just in case: | |||
270 | your Linux distribution. | 270 | your Linux distribution. |
271 | 271 | ||
272 | Another point worth noting is that historically within the Yocto | 272 | Another point worth noting is that historically within the Yocto |
273 | Project, recipes were referred to as packages - thus, the existence | 273 | Project, recipes were referred to as packages --- thus, the existence |
274 | of several BitBake variables that are seemingly mis-named, (e.g. | 274 | of several BitBake variables that are seemingly mis-named, (e.g. |
275 | :term:`PR`, :term:`PV`, and | 275 | :term:`PR`, :term:`PV`, and |
276 | :term:`PE`). | 276 | :term:`PE`). |
@@ -369,7 +369,7 @@ universal, the list includes them just in case: | |||
369 | Directory created by unpacking a released tarball as compared to | 369 | Directory created by unpacking a released tarball as compared to |
370 | cloning ``git://git.yoctoproject.org/poky``. When you unpack a | 370 | cloning ``git://git.yoctoproject.org/poky``. When you unpack a |
371 | tarball, you have an exact copy of the files based on the time of | 371 | tarball, you have an exact copy of the files based on the time of |
372 | release - a fixed release point. Any changes you make to your local | 372 | release --- a fixed release point. Any changes you make to your local |
373 | files in the Source Directory are on top of the release and will | 373 | files in the Source Directory are on top of the release and will |
374 | remain local only. On the other hand, when you clone the ``poky`` Git | 374 | remain local only. On the other hand, when you clone the ``poky`` Git |
375 | repository, you have an active development repository with access to | 375 | repository, you have an active development repository with access to |
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index f723e38d1a..b42854caaa 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst | |||
@@ -591,7 +591,7 @@ system and gives an overview of their function and contents. | |||
591 | This variable is useful in situations where the same recipe appears | 591 | This variable is useful in situations where the same recipe appears |
592 | in more than one layer. Setting this variable allows you to | 592 | in more than one layer. Setting this variable allows you to |
593 | prioritize a layer against other layers that contain the same recipe | 593 | prioritize a layer against other layers that contain the same recipe |
594 | - effectively letting you control the precedence for the multiple | 594 | --- effectively letting you control the precedence for the multiple |
595 | layers. The precedence established through this variable stands | 595 | layers. The precedence established through this variable stands |
596 | regardless of a recipe's version (:term:`PV` variable). For | 596 | regardless of a recipe's version (:term:`PV` variable). For |
597 | example, a layer that has a recipe with a higher :term:`PV` value but for | 597 | example, a layer that has a recipe with a higher :term:`PV` value but for |
@@ -889,7 +889,7 @@ system and gives an overview of their function and contents. | |||
889 | :term:`BUILD_OS` | 889 | :term:`BUILD_OS` |
890 | Specifies the operating system in use on the build host (e.g. | 890 | Specifies the operating system in use on the build host (e.g. |
891 | "linux"). The OpenEmbedded build system sets the value of | 891 | "linux"). The OpenEmbedded build system sets the value of |
892 | :term:`BUILD_OS` from the OS reported by the ``uname`` command - the | 892 | :term:`BUILD_OS` from the OS reported by the ``uname`` command --- the |
893 | first word, converted to lower-case characters. | 893 | first word, converted to lower-case characters. |
894 | 894 | ||
895 | :term:`BUILD_PREFIX` | 895 | :term:`BUILD_PREFIX` |
@@ -1689,7 +1689,7 @@ system and gives an overview of their function and contents. | |||
1689 | ``${TMPDIR}/deploy``. | 1689 | ``${TMPDIR}/deploy``. |
1690 | 1690 | ||
1691 | For more information on the structure of the Build Directory, see | 1691 | For more information on the structure of the Build Directory, see |
1692 | ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section. | 1692 | ":ref:`ref-manual/structure:the build directory --- \`\`build/\`\``" section. |
1693 | For more detail on the contents of the ``deploy`` directory, see the | 1693 | For more detail on the contents of the ``deploy`` directory, see the |
1694 | ":ref:`overview-manual/concepts:images`", | 1694 | ":ref:`overview-manual/concepts:images`", |
1695 | ":ref:`overview-manual/concepts:package feeds`", and | 1695 | ":ref:`overview-manual/concepts:package feeds`", and |
@@ -1733,7 +1733,7 @@ system and gives an overview of their function and contents. | |||
1733 | <ref-classes-image>` class. | 1733 | <ref-classes-image>` class. |
1734 | 1734 | ||
1735 | For more information on the structure of the Build Directory, see | 1735 | For more information on the structure of the Build Directory, see |
1736 | ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section. | 1736 | ":ref:`ref-manual/structure:the build directory --- \`\`build/\`\``" section. |
1737 | For more detail on the contents of the ``deploy`` directory, see the | 1737 | For more detail on the contents of the ``deploy`` directory, see the |
1738 | ":ref:`overview-manual/concepts:images`" and | 1738 | ":ref:`overview-manual/concepts:images`" and |
1739 | ":ref:`overview-manual/concepts:application development sdk`" sections both in | 1739 | ":ref:`overview-manual/concepts:application development sdk`" sections both in |
@@ -2248,24 +2248,24 @@ system and gives an overview of their function and contents. | |||
2248 | 2248 | ||
2249 | Here are some examples of features you can add: | 2249 | Here are some examples of features you can add: |
2250 | 2250 | ||
2251 | - "dbg-pkgs" - Adds -dbg packages for all installed packages including | 2251 | - "dbg-pkgs" --- adds -dbg packages for all installed packages including |
2252 | symbol information for debugging and profiling. | 2252 | symbol information for debugging and profiling. |
2253 | 2253 | ||
2254 | - "debug-tweaks" - Makes an image suitable for debugging. For example, allows root logins without passwords and | 2254 | - "debug-tweaks" --- makes an image suitable for debugging. For example, allows root logins without passwords and |
2255 | enables post-installation logging. See the 'allow-empty-password' and | 2255 | enables post-installation logging. See the 'allow-empty-password' and |
2256 | 'post-install-logging' features in the ":ref:`ref-features-image`" | 2256 | 'post-install-logging' features in the ":ref:`ref-features-image`" |
2257 | section for more information. | 2257 | section for more information. |
2258 | - "dev-pkgs" - Adds -dev packages for all installed packages. This is | 2258 | - "dev-pkgs" --- adds -dev packages for all installed packages. This is |
2259 | useful if you want to develop against the libraries in the image. | 2259 | useful if you want to develop against the libraries in the image. |
2260 | - "read-only-rootfs" - Creates an image whose root filesystem is | 2260 | - "read-only-rootfs" --- creates an image whose root filesystem is |
2261 | read-only. See the | 2261 | read-only. See the |
2262 | ":ref:`dev-manual/common-tasks:creating a read-only root filesystem`" | 2262 | ":ref:`dev-manual/common-tasks:creating a read-only root filesystem`" |
2263 | section in the Yocto Project Development Tasks Manual for more | 2263 | section in the Yocto Project Development Tasks Manual for more |
2264 | information | 2264 | information |
2265 | - "tools-debug" - Adds debugging tools such as gdb and strace. | 2265 | - "tools-debug" --- adds debugging tools such as gdb and strace. |
2266 | - "tools-sdk" - Adds development tools such as gcc, make, | 2266 | - "tools-sdk" --- adds development tools such as gcc, make, |
2267 | pkgconfig and so forth. | 2267 | pkgconfig and so forth. |
2268 | - "tools-testapps" - Adds useful testing tools | 2268 | - "tools-testapps" --- adds useful testing tools |
2269 | such as ts_print, aplay, arecord and so forth. | 2269 | such as ts_print, aplay, arecord and so forth. |
2270 | 2270 | ||
2271 | For a complete list of image features that ships with the Yocto | 2271 | For a complete list of image features that ships with the Yocto |
@@ -3259,7 +3259,7 @@ system and gives an overview of their function and contents. | |||
3259 | IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}" | 3259 | IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}" |
3260 | 3260 | ||
3261 | :term:`IMAGE_NAME_SUFFIX` | 3261 | :term:`IMAGE_NAME_SUFFIX` |
3262 | Suffix used for the image output filename - defaults to ``".rootfs"`` | 3262 | Suffix used for the image output filename --- defaults to ``".rootfs"`` |
3263 | to distinguish the image file from other files created during image | 3263 | to distinguish the image file from other files created during image |
3264 | building; however if this suffix is redundant or not desired you can | 3264 | building; however if this suffix is redundant or not desired you can |
3265 | clear the value of this variable (set the value to ""). For example, | 3265 | clear the value of this variable (set the value to ""). For example, |
@@ -6217,7 +6217,7 @@ system and gives an overview of their function and contents. | |||
6217 | ``baz``. | 6217 | ``baz``. |
6218 | 6218 | ||
6219 | The names of the packages you list within :term:`RDEPENDS` must be the | 6219 | The names of the packages you list within :term:`RDEPENDS` must be the |
6220 | names of other packages - they cannot be recipe names. Although | 6220 | names of other packages --- they cannot be recipe names. Although |
6221 | package names and recipe names usually match, the important point | 6221 | package names and recipe names usually match, the important point |
6222 | here is that you are providing package names within the :term:`RDEPENDS` | 6222 | here is that you are providing package names within the :term:`RDEPENDS` |
6223 | variable. For an example of the default list of packages created from | 6223 | variable. For an example of the default list of packages created from |
@@ -7120,35 +7120,35 @@ system and gives an overview of their function and contents. | |||
7120 | 7120 | ||
7121 | There are standard and recipe-specific options. Here are standard ones: | 7121 | There are standard and recipe-specific options. Here are standard ones: |
7122 | 7122 | ||
7123 | - ``apply`` - Whether to apply the patch or not. The default | 7123 | - ``apply`` --- whether to apply the patch or not. The default |
7124 | action is to apply the patch. | 7124 | action is to apply the patch. |
7125 | 7125 | ||
7126 | - ``striplevel`` - Which striplevel to use when applying the | 7126 | - ``striplevel`` --- which striplevel to use when applying the |
7127 | patch. The default level is 1. | 7127 | patch. The default level is 1. |
7128 | 7128 | ||
7129 | - ``patchdir`` - Specifies the directory in which the patch should | 7129 | - ``patchdir`` --- specifies the directory in which the patch should |
7130 | be applied. The default is ``${``\ :term:`S`\ ``}``. | 7130 | be applied. The default is ``${``\ :term:`S`\ ``}``. |
7131 | 7131 | ||
7132 | Here are options specific to recipes building code from a revision | 7132 | Here are options specific to recipes building code from a revision |
7133 | control system: | 7133 | control system: |
7134 | 7134 | ||
7135 | - ``mindate`` - Apply the patch only if | 7135 | - ``mindate`` --- apply the patch only if |
7136 | :term:`SRCDATE` is equal to or greater than | 7136 | :term:`SRCDATE` is equal to or greater than |
7137 | ``mindate``. | 7137 | ``mindate``. |
7138 | 7138 | ||
7139 | - ``maxdate`` - Apply the patch only if :term:`SRCDATE` is not later | 7139 | - ``maxdate`` --- apply the patch only if :term:`SRCDATE` is not later |
7140 | than ``maxdate``. | 7140 | than ``maxdate``. |
7141 | 7141 | ||
7142 | - ``minrev`` - Apply the patch only if :term:`SRCREV` is equal to or | 7142 | - ``minrev`` --- apply the patch only if :term:`SRCREV` is equal to or |
7143 | greater than ``minrev``. | 7143 | greater than ``minrev``. |
7144 | 7144 | ||
7145 | - ``maxrev`` - Apply the patch only if :term:`SRCREV` is not later | 7145 | - ``maxrev`` --- apply the patch only if :term:`SRCREV` is not later |
7146 | than ``maxrev``. | 7146 | than ``maxrev``. |
7147 | 7147 | ||
7148 | - ``rev`` - Apply the patch only if :term:`SRCREV` is equal to | 7148 | - ``rev`` --- apply the patch only if :term:`SRCREV` is equal to |
7149 | ``rev``. | 7149 | ``rev``. |
7150 | 7150 | ||
7151 | - ``notrev`` - Apply the patch only if :term:`SRCREV` is not equal to | 7151 | - ``notrev`` --- apply the patch only if :term:`SRCREV` is not equal to |
7152 | ``rev``. | 7152 | ``rev``. |
7153 | 7153 | ||
7154 | .. note:: | 7154 | .. note:: |
@@ -8857,8 +8857,8 @@ system and gives an overview of their function and contents. | |||
8857 | - :term:`TMPDIR`: The top-level build output directory | 8857 | - :term:`TMPDIR`: The top-level build output directory |
8858 | - :term:`MULTIMACH_TARGET_SYS`: The target system identifier | 8858 | - :term:`MULTIMACH_TARGET_SYS`: The target system identifier |
8859 | - :term:`PN`: The recipe name | 8859 | - :term:`PN`: The recipe name |
8860 | - :term:`EXTENDPE`: The epoch - (if :term:`PE` is not specified, which | 8860 | - :term:`EXTENDPE`: The epoch --- if :term:`PE` is not specified, which |
8861 | is usually the case for most recipes, then `EXTENDPE` is blank) | 8861 | is usually the case for most recipes, then `EXTENDPE` is blank. |
8862 | - :term:`PV`: The recipe version | 8862 | - :term:`PV`: The recipe version |
8863 | - :term:`PR`: The recipe revision | 8863 | - :term:`PR`: The recipe revision |
8864 | 8864 | ||
diff --git a/documentation/ref-manual/varlocality.rst b/documentation/ref-manual/varlocality.rst index 5f7dba8775..e2c086ffa0 100644 --- a/documentation/ref-manual/varlocality.rst +++ b/documentation/ref-manual/varlocality.rst | |||
@@ -113,7 +113,7 @@ This section lists variables that are required for recipes. | |||
113 | 113 | ||
114 | - :term:`LIC_FILES_CHKSUM` | 114 | - :term:`LIC_FILES_CHKSUM` |
115 | 115 | ||
116 | - :term:`SRC_URI` - used in recipes that fetch local or remote files. | 116 | - :term:`SRC_URI` --- used in recipes that fetch local or remote files. |
117 | 117 | ||
118 | .. _ref-varlocality-recipe-dependencies: | 118 | .. _ref-varlocality-recipe-dependencies: |
119 | 119 | ||
diff --git a/documentation/sdk-manual/extensible.rst b/documentation/sdk-manual/extensible.rst index 6bb262273d..ed9e43a2d8 100644 --- a/documentation/sdk-manual/extensible.rst +++ b/documentation/sdk-manual/extensible.rst | |||
@@ -252,7 +252,7 @@ command: | |||
252 | - *Left*: The left scenario in the figure represents a common | 252 | - *Left*: The left scenario in the figure represents a common |
253 | situation where the source code does not exist locally and needs | 253 | situation where the source code does not exist locally and needs |
254 | to be extracted. In this situation, the source code is extracted | 254 | to be extracted. In this situation, the source code is extracted |
255 | to the default workspace - you do not want the files in some | 255 | to the default workspace --- you do not want the files in some |
256 | specific location outside of the workspace. Thus, everything you | 256 | specific location outside of the workspace. Thus, everything you |
257 | need will be located in the workspace:: | 257 | need will be located in the workspace:: |
258 | 258 | ||
@@ -267,7 +267,7 @@ command: | |||
267 | - *Middle*: The middle scenario in the figure also represents a | 267 | - *Middle*: The middle scenario in the figure also represents a |
268 | situation where the source code does not exist locally. In this | 268 | situation where the source code does not exist locally. In this |
269 | case, the code is again upstream and needs to be extracted to some | 269 | case, the code is again upstream and needs to be extracted to some |
270 | local area - this time outside of the default workspace. | 270 | local area --- this time outside of the default workspace. |
271 | 271 | ||
272 | .. note:: | 272 | .. note:: |
273 | 273 | ||
@@ -302,7 +302,7 @@ command: | |||
302 | recipe for the code and places the recipe into the workspace. | 302 | recipe for the code and places the recipe into the workspace. |
303 | 303 | ||
304 | Because the extracted source code already exists, ``devtool`` does | 304 | Because the extracted source code already exists, ``devtool`` does |
305 | not try to relocate the source code into the workspace - only the | 305 | not try to relocate the source code into the workspace --- only the |
306 | new recipe is placed in the workspace. | 306 | new recipe is placed in the workspace. |
307 | 307 | ||
308 | Aside from a recipe folder, the command also creates an associated | 308 | Aside from a recipe folder, the command also creates an associated |
diff --git a/documentation/sdk-manual/working-projects.rst b/documentation/sdk-manual/working-projects.rst index efef5c8bd2..7f8d9b8491 100644 --- a/documentation/sdk-manual/working-projects.rst +++ b/documentation/sdk-manual/working-projects.rst | |||
@@ -174,19 +174,19 @@ variables and Makefile variables during development. | |||
174 | The main point of this section is to explain the following three cases | 174 | The main point of this section is to explain the following three cases |
175 | regarding variable behavior: | 175 | regarding variable behavior: |
176 | 176 | ||
177 | - *Case 1 - No Variables Set in the Makefile Map to Equivalent | 177 | - *Case 1 --- No Variables Set in the Makefile Map to Equivalent |
178 | Environment Variables Set in the SDK Setup Script:* Because matching | 178 | Environment Variables Set in the SDK Setup Script:* Because matching |
179 | variables are not specifically set in the ``Makefile``, the variables | 179 | variables are not specifically set in the ``Makefile``, the variables |
180 | retain their values based on the environment setup script. | 180 | retain their values based on the environment setup script. |
181 | 181 | ||
182 | - *Case 2 - Variables Are Set in the Makefile that Map to Equivalent | 182 | - *Case 2 --- Variables Are Set in the Makefile that Map to Equivalent |
183 | Environment Variables from the SDK Setup Script:* Specifically | 183 | Environment Variables from the SDK Setup Script:* Specifically |
184 | setting matching variables in the ``Makefile`` during the build | 184 | setting matching variables in the ``Makefile`` during the build |
185 | results in the environment settings of the variables being | 185 | results in the environment settings of the variables being |
186 | overwritten. In this case, the variables you set in the ``Makefile`` | 186 | overwritten. In this case, the variables you set in the ``Makefile`` |
187 | are used. | 187 | are used. |
188 | 188 | ||
189 | - *Case 3 - Variables Are Set Using the Command Line that Map to | 189 | - *Case 3 --- Variables Are Set Using the Command Line that Map to |
190 | Equivalent Environment Variables from the SDK Setup Script:* | 190 | Equivalent Environment Variables from the SDK Setup Script:* |
191 | Executing the ``Makefile`` from the command line results in the | 191 | Executing the ``Makefile`` from the command line results in the |
192 | environment variables being overwritten. In this case, the | 192 | environment variables being overwritten. In this case, the |
diff --git a/documentation/test-manual/intro.rst b/documentation/test-manual/intro.rst index 12324e592c..6421dd53c9 100644 --- a/documentation/test-manual/intro.rst +++ b/documentation/test-manual/intro.rst | |||
@@ -85,8 +85,8 @@ topology that includes a controller and a cluster of workers: | |||
85 | :align: center | 85 | :align: center |
86 | :width: 70% | 86 | :width: 70% |
87 | 87 | ||
88 | Yocto Project Tests - Types of Testing Overview | 88 | Yocto Project Tests --- Types of Testing Overview |
89 | =============================================== | 89 | ================================================= |
90 | 90 | ||
91 | The Autobuilder tests different elements of the project by using | 91 | The Autobuilder tests different elements of the project by using |
92 | the following types of tests: | 92 | the following types of tests: |
diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst index 6b34fedc26..ee1fc891ab 100644 --- a/documentation/transitioning-to-a-custom-environment.rst +++ b/documentation/transitioning-to-a-custom-environment.rst | |||
@@ -84,7 +84,7 @@ Transitioning to a custom environment for systems development | |||
84 | 84 | ||
85 | #. **Now you're ready to create an image recipe**. | 85 | #. **Now you're ready to create an image recipe**. |
86 | There are a number of ways to do this. However, it is strongly recommended | 86 | There are a number of ways to do this. However, it is strongly recommended |
87 | that you have your own image recipe - don't try appending to existing image | 87 | that you have your own image recipe --- don't try appending to existing image |
88 | recipes. Recipes for images are trivial to create and you usually want to | 88 | recipes. Recipes for images are trivial to create and you usually want to |
89 | fully customize their contents. | 89 | fully customize their contents. |
90 | 90 | ||