diff options
author | Quentin Schulz <foss@0leil.net> | 2021-05-27 20:41:17 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-06-19 16:54:01 +0100 |
commit | 7d3f57cfd2e4322bcd96d67d330124f221a9aedd (patch) | |
tree | 5d07321b7c8bc59bb7fcc0372fab8b7a1966cf06 /documentation/sdk-manual | |
parent | 7a9b74e9d2a5cf3b1fb3ac7565c50eae6e0d4632 (diff) | |
download | poky-7d3f57cfd2e4322bcd96d67d330124f221a9aedd.tar.gz |
docs: replace ``FOO`` by :term:`FOO` where possible
If a variable has a glossary entry and some rST files write about those
variables, it's better to point to the glossary entry instead of just
highlighting it by surrounding it with two tick quotes.
This was automated by the following python script:
"""
import re
from pathlib import Path
with open('objects.inv.txt', 'r') as f:
objects = f.readlines()
with open('bitbake-objects.inv.txt', 'r') as f:
objects = objects + f.readlines()
re_term = re.compile(r'variables.html#term-([A-Z_0-9]*)')
terms = []
for obj in objects:
match = re_term.search(obj)
if match and match.group(1):
terms.append(match.group(1))
for rst in Path('.').rglob('*.rst'):
with open(rst, 'r') as f:
content = "".joing(f.readlines())
for term in terms:
content = re.sub(r'``({})``(?!.*\s*[~-]+)'.format(term), r':term:`\1`', content)
with open(rst, 'w') as f:
f.write(content)
"""
(From yocto-docs rev: ba49d9babfcb84bc5c26a68c8c3880a1d9c236d3)
Signed-off-by: Quentin Schulz <foss@0leil.net>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/sdk-manual')
-rw-r--r-- | documentation/sdk-manual/appendix-customizing-standard.rst | 4 | ||||
-rw-r--r-- | documentation/sdk-manual/appendix-customizing.rst | 24 | ||||
-rw-r--r-- | documentation/sdk-manual/extensible.rst | 50 | ||||
-rw-r--r-- | documentation/sdk-manual/working-projects.rst | 12 |
4 files changed, 45 insertions, 45 deletions
diff --git a/documentation/sdk-manual/appendix-customizing-standard.rst b/documentation/sdk-manual/appendix-customizing-standard.rst index 90b634529e..9bc70cf55c 100644 --- a/documentation/sdk-manual/appendix-customizing-standard.rst +++ b/documentation/sdk-manual/appendix-customizing-standard.rst | |||
@@ -17,10 +17,10 @@ and | |||
17 | variables control the set of packages adding to the SDK. | 17 | variables control the set of packages adding to the SDK. |
18 | 18 | ||
19 | If you want to add individual packages to the toolchain that runs on the | 19 | If you want to add individual packages to the toolchain that runs on the |
20 | host, simply add those packages to the ``TOOLCHAIN_HOST_TASK`` variable. | 20 | host, simply add those packages to the :term:`TOOLCHAIN_HOST_TASK` variable. |
21 | Similarly, if you want to add packages to the default set that is part | 21 | Similarly, if you want to add packages to the default set that is part |
22 | of the toolchain that runs on the target, add the packages to the | 22 | of the toolchain that runs on the target, add the packages to the |
23 | ``TOOLCHAIN_TARGET_TASK`` variable. | 23 | :term:`TOOLCHAIN_TARGET_TASK` variable. |
24 | 24 | ||
25 | Adding API Documentation to the Standard SDK | 25 | Adding API Documentation to the Standard SDK |
26 | ============================================ | 26 | ============================================ |
diff --git a/documentation/sdk-manual/appendix-customizing.rst b/documentation/sdk-manual/appendix-customizing.rst index c122fb5836..8c635d1662 100644 --- a/documentation/sdk-manual/appendix-customizing.rst +++ b/documentation/sdk-manual/appendix-customizing.rst | |||
@@ -35,13 +35,13 @@ build system applies them against ``local.conf`` and ``auto.conf``: | |||
35 | - Variables listed in | 35 | - Variables listed in |
36 | :term:`SDK_LOCAL_CONF_WHITELIST` | 36 | :term:`SDK_LOCAL_CONF_WHITELIST` |
37 | are included. Including a variable in the value of | 37 | are included. Including a variable in the value of |
38 | ``SDK_LOCAL_CONF_WHITELIST`` overrides either of the previous two | 38 | :term:`SDK_LOCAL_CONF_WHITELIST` overrides either of the previous two |
39 | filters. The default value is blank. | 39 | filters. The default value is blank. |
40 | 40 | ||
41 | - Classes inherited globally with | 41 | - Classes inherited globally with |
42 | :term:`INHERIT` that are listed in | 42 | :term:`INHERIT` that are listed in |
43 | :term:`SDK_INHERIT_BLACKLIST` | 43 | :term:`SDK_INHERIT_BLACKLIST` |
44 | are disabled. Using ``SDK_INHERIT_BLACKLIST`` to disable these | 44 | are disabled. Using :term:`SDK_INHERIT_BLACKLIST` to disable these |
45 | classes is the typical method to disable classes that are problematic | 45 | classes is the typical method to disable classes that are problematic |
46 | or unnecessary in the SDK context. The default value blacklists the | 46 | or unnecessary in the SDK context. The default value blacklists the |
47 | :ref:`buildhistory <ref-classes-buildhistory>` | 47 | :ref:`buildhistory <ref-classes-buildhistory>` |
@@ -95,7 +95,7 @@ adjustments: | |||
95 | 95 | ||
96 | - Disable the tasks if they are added by a class and you do not need | 96 | - Disable the tasks if they are added by a class and you do not need |
97 | the functionality the class provides in the extensible SDK. To | 97 | the functionality the class provides in the extensible SDK. To |
98 | disable the tasks, add the class to the ``SDK_INHERIT_BLACKLIST`` | 98 | disable the tasks, add the class to the :term:`SDK_INHERIT_BLACKLIST` |
99 | variable as described in the previous section. | 99 | variable as described in the previous section. |
100 | 100 | ||
101 | - Generally, you want to have a shared state mirror set up so users of | 101 | - Generally, you want to have a shared state mirror set up so users of |
@@ -142,12 +142,12 @@ section. | |||
142 | 142 | ||
143 | By default, this title is derived from | 143 | By default, this title is derived from |
144 | :term:`DISTRO_NAME` when it is | 144 | :term:`DISTRO_NAME` when it is |
145 | set. If the ``DISTRO_NAME`` variable is not set, the title is derived | 145 | set. If the :term:`DISTRO_NAME` variable is not set, the title is derived |
146 | from the :term:`DISTRO` variable. | 146 | from the :term:`DISTRO` variable. |
147 | 147 | ||
148 | The | 148 | The |
149 | :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` | 149 | :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` |
150 | class defines the default value of the ``SDK_TITLE`` variable as | 150 | class defines the default value of the :term:`SDK_TITLE` variable as |
151 | follows:: | 151 | follows:: |
152 | 152 | ||
153 | SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" | 153 | SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" |
@@ -158,7 +158,7 @@ creates an SDK installer title that applies across your distribution. As | |||
158 | an example, assume you have your own layer for your distribution named | 158 | an example, assume you have your own layer for your distribution named |
159 | "meta-mydistro" and you are using the same type of file hierarchy as | 159 | "meta-mydistro" and you are using the same type of file hierarchy as |
160 | does the default "poky" distribution. If so, you could update the | 160 | does the default "poky" distribution. If so, you could update the |
161 | ``SDK_TITLE`` variable in the | 161 | :term:`SDK_TITLE` variable in the |
162 | ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following | 162 | ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following |
163 | form:: | 163 | form:: |
164 | 164 | ||
@@ -220,7 +220,7 @@ class as follows:: | |||
220 | 220 | ||
221 | You can | 221 | You can |
222 | change this default installation directory by specifically setting the | 222 | change this default installation directory by specifically setting the |
223 | ``SDKEXTPATH`` variable. | 223 | :term:`SDKEXTPATH` variable. |
224 | 224 | ||
225 | While there are several ways of setting this variable, | 225 | While there are several ways of setting this variable, |
226 | the method that makes the most sense is to set the variable in your | 226 | the method that makes the most sense is to set the variable in your |
@@ -229,7 +229,7 @@ default directory that applies across your distribution. As an example, | |||
229 | assume you have your own layer for your distribution named | 229 | assume you have your own layer for your distribution named |
230 | "meta-mydistro" and you are using the same type of file hierarchy as | 230 | "meta-mydistro" and you are using the same type of file hierarchy as |
231 | does the default "poky" distribution. If so, you could update the | 231 | does the default "poky" distribution. If so, you could update the |
232 | ``SDKEXTPATH`` variable in the | 232 | :term:`SDKEXTPATH` variable in the |
233 | ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following | 233 | ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following |
234 | form:: | 234 | form:: |
235 | 235 | ||
@@ -284,11 +284,11 @@ source, you need to do a number of things: | |||
284 | 284 | ||
285 | SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS" | 285 | SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS" |
286 | 286 | ||
287 | - Alternatively, if you just want to set the ``SSTATE_MIRRORS`` | 287 | - Alternatively, if you just want to set the :term:`SSTATE_MIRRORS` |
288 | variable's value for the SDK alone, create a | 288 | variable's value for the SDK alone, create a |
289 | ``conf/sdk-extra.conf`` file either in your | 289 | ``conf/sdk-extra.conf`` file either in your |
290 | :term:`Build Directory` or within any | 290 | :term:`Build Directory` or within any |
291 | layer and put your ``SSTATE_MIRRORS`` setting within that file. | 291 | layer and put your :term:`SSTATE_MIRRORS` setting within that file. |
292 | 292 | ||
293 | .. note:: | 293 | .. note:: |
294 | 294 | ||
@@ -333,7 +333,7 @@ following:: | |||
333 | 333 | ||
334 | See the :term:`SDK_INCLUDE_PKGDATA` variable for additional information. | 334 | See the :term:`SDK_INCLUDE_PKGDATA` variable for additional information. |
335 | 335 | ||
336 | Setting the ``SDK_INCLUDE_PKGDATA`` variable as shown causes the "world" | 336 | Setting the :term:`SDK_INCLUDE_PKGDATA` variable as shown causes the "world" |
337 | target to be built so that information for all of the recipes included | 337 | target to be built so that information for all of the recipes included |
338 | within it are available. Having these recipes available increases build | 338 | within it are available. Having these recipes available increases build |
339 | time significantly and increases the size of the SDK installer by 30-80 | 339 | time significantly and increases the size of the SDK installer by 30-80 |
@@ -358,7 +358,7 @@ You can explicitly control whether or not to include the toolchain when | |||
358 | you build an SDK by setting the | 358 | you build an SDK by setting the |
359 | :term:`SDK_INCLUDE_TOOLCHAIN` | 359 | :term:`SDK_INCLUDE_TOOLCHAIN` |
360 | variable to "1". In particular, it is useful to include the toolchain | 360 | variable to "1". In particular, it is useful to include the toolchain |
361 | when you have set ``SDK_EXT_TYPE`` to "minimal", which by default, | 361 | when you have set :term:`SDK_EXT_TYPE` to "minimal", which by default, |
362 | excludes the toolchain. Also, it is helpful if you are building a small | 362 | excludes the toolchain. Also, it is helpful if you are building a small |
363 | SDK for use with an IDE or some other tool where you do not want to take | 363 | SDK for use with an IDE or some other tool where you do not want to take |
364 | extra steps to install a toolchain. | 364 | extra steps to install a toolchain. |
diff --git a/documentation/sdk-manual/extensible.rst b/documentation/sdk-manual/extensible.rst index d444cad6ea..33032b42a7 100644 --- a/documentation/sdk-manual/extensible.rst +++ b/documentation/sdk-manual/extensible.rst | |||
@@ -438,7 +438,7 @@ command: | |||
438 | 438 | ||
439 | With this scenario, there is no ``srctree`` argument. Consequently, the | 439 | With this scenario, there is no ``srctree`` argument. Consequently, the |
440 | default behavior of the ``devtool modify`` command is to extract | 440 | default behavior of the ``devtool modify`` command is to extract |
441 | the source files pointed to by the ``SRC_URI`` statements into a | 441 | the source files pointed to by the :term:`SRC_URI` statements into a |
442 | local Git structure. Furthermore, the location for the extracted | 442 | local Git structure. Furthermore, the location for the extracted |
443 | source is the default area within the ``devtool`` workspace. The | 443 | source is the default area within the ``devtool`` workspace. The |
444 | result is that the command sets up both the source code and an | 444 | result is that the command sets up both the source code and an |
@@ -446,7 +446,7 @@ command: | |||
446 | original location. | 446 | original location. |
447 | 447 | ||
448 | Additionally, if you have any non-patch local files (i.e. files | 448 | Additionally, if you have any non-patch local files (i.e. files |
449 | referred to with ``file://`` entries in ``SRC_URI`` statement | 449 | referred to with ``file://`` entries in :term:`SRC_URI` statement |
450 | excluding ``*.patch/`` or ``*.diff``), these files are copied to | 450 | excluding ``*.patch/`` or ``*.diff``), these files are copied to |
451 | an ``oe-local-files`` folder under the newly created source tree. | 451 | an ``oe-local-files`` folder under the newly created source tree. |
452 | Copying the files here gives you a convenient area from which you | 452 | Copying the files here gives you a convenient area from which you |
@@ -476,7 +476,7 @@ command: | |||
476 | devtool | 476 | devtool |
477 | command. | 477 | command. |
478 | 478 | ||
479 | As with all extractions, the command uses the recipe's ``SRC_URI`` | 479 | As with all extractions, the command uses the recipe's :term:`SRC_URI` |
480 | statements to locate the source files and any associated patch | 480 | statements to locate the source files and any associated patch |
481 | files. Non-patch files are copied to an ``oe-local-files`` folder | 481 | files. Non-patch files are copied to an ``oe-local-files`` folder |
482 | under the newly created source tree. | 482 | under the newly created source tree. |
@@ -655,18 +655,18 @@ The following diagram shows the common development flow used with the | |||
655 | don't use "-V", the command upgrades the recipe to the latest | 655 | don't use "-V", the command upgrades the recipe to the latest |
656 | version. | 656 | version. |
657 | 657 | ||
658 | If the source files pointed to by the ``SRC_URI`` statement in the | 658 | If the source files pointed to by the :term:`SRC_URI` statement in the |
659 | recipe are in a Git repository, you must provide the "-S" option and | 659 | recipe are in a Git repository, you must provide the "-S" option and |
660 | specify a revision for the software. | 660 | specify a revision for the software. |
661 | 661 | ||
662 | Once ``devtool`` locates the recipe, it uses the ``SRC_URI`` variable | 662 | Once ``devtool`` locates the recipe, it uses the :term:`SRC_URI` variable |
663 | to locate the source code and any local patch files from other | 663 | to locate the source code and any local patch files from other |
664 | developers. The result is that the command sets up the source code, | 664 | developers. The result is that the command sets up the source code, |
665 | the new version of the recipe, and an append file all within the | 665 | the new version of the recipe, and an append file all within the |
666 | workspace. | 666 | workspace. |
667 | 667 | ||
668 | Additionally, if you have any non-patch local files (i.e. files | 668 | Additionally, if you have any non-patch local files (i.e. files |
669 | referred to with ``file://`` entries in ``SRC_URI`` statement | 669 | referred to with ``file://`` entries in :term:`SRC_URI` statement |
670 | excluding ``*.patch/`` or ``*.diff``), these files are copied to an | 670 | excluding ``*.patch/`` or ``*.diff``), these files are copied to an |
671 | ``oe-local-files`` folder under the newly created source tree. | 671 | ``oe-local-files`` folder under the newly created source tree. |
672 | Copying the files here gives you a convenient area from which you can | 672 | Copying the files here gives you a convenient area from which you can |
@@ -676,7 +676,7 @@ The following diagram shows the common development flow used with the | |||
676 | 676 | ||
677 | 2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen | 677 | 2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen |
678 | after upgrading the software to a new version. Conflicts occur | 678 | after upgrading the software to a new version. Conflicts occur |
679 | if your recipe specifies some patch files in ``SRC_URI`` that | 679 | if your recipe specifies some patch files in :term:`SRC_URI` that |
680 | conflict with changes made in the new version of the software. For | 680 | conflict with changes made in the new version of the software. For |
681 | such cases, you need to resolve the conflicts by editing the source | 681 | such cases, you need to resolve the conflicts by editing the source |
682 | and following the normal ``git rebase`` conflict resolution process. | 682 | and following the normal ``git rebase`` conflict resolution process. |
@@ -832,7 +832,7 @@ result from naming not being recognized or because the dependency simply | |||
832 | is not available. For cases where the dependency is not available, you | 832 | is not available. For cases where the dependency is not available, you |
833 | must use the ``devtool add`` command to add an additional recipe that | 833 | must use the ``devtool add`` command to add an additional recipe that |
834 | satisfies the dependency. Once you add that recipe, you need to update | 834 | satisfies the dependency. Once you add that recipe, you need to update |
835 | the ``DEPENDS`` variable in the original recipe to include the new | 835 | the :term:`DEPENDS` variable in the original recipe to include the new |
836 | recipe. | 836 | recipe. |
837 | 837 | ||
838 | If you need to add runtime dependencies, you can do so by adding the | 838 | If you need to add runtime dependencies, you can do so by adding the |
@@ -861,7 +861,7 @@ license. If so, the command sets the | |||
861 | :term:`LICENSE` value accordingly. | 861 | :term:`LICENSE` value accordingly. |
862 | You should double-check the value added by the command against the | 862 | You should double-check the value added by the command against the |
863 | documentation or source files for the software you are building and, if | 863 | documentation or source files for the software you are building and, if |
864 | necessary, update that ``LICENSE`` value. | 864 | necessary, update that :term:`LICENSE` value. |
865 | 865 | ||
866 | The ``devtool add`` command also sets the | 866 | The ``devtool add`` command also sets the |
867 | :term:`LIC_FILES_CHKSUM` | 867 | :term:`LIC_FILES_CHKSUM` |
@@ -869,16 +869,16 @@ value to point to all files that appear to be license-related. Realize | |||
869 | that license statements often appear in comments at the top of source | 869 | that license statements often appear in comments at the top of source |
870 | files or within the documentation. In such cases, the command does not | 870 | files or within the documentation. In such cases, the command does not |
871 | recognize those license statements. Consequently, you might need to | 871 | recognize those license statements. Consequently, you might need to |
872 | amend the ``LIC_FILES_CHKSUM`` variable to point to one or more of those | 872 | amend the :term:`LIC_FILES_CHKSUM` variable to point to one or more of those |
873 | comments if present. Setting ``LIC_FILES_CHKSUM`` is particularly | 873 | comments if present. Setting :term:`LIC_FILES_CHKSUM` is particularly |
874 | important for third-party software. The mechanism attempts to ensure | 874 | important for third-party software. The mechanism attempts to ensure |
875 | correct licensing should you upgrade the recipe to a newer upstream | 875 | correct licensing should you upgrade the recipe to a newer upstream |
876 | version in future. Any change in licensing is detected and you receive | 876 | version in future. Any change in licensing is detected and you receive |
877 | an error prompting you to check the license text again. | 877 | an error prompting you to check the license text again. |
878 | 878 | ||
879 | If the ``devtool add`` command cannot determine licensing information, | 879 | If the ``devtool add`` command cannot determine licensing information, |
880 | ``devtool`` sets the ``LICENSE`` value to "CLOSED" and leaves the | 880 | ``devtool`` sets the :term:`LICENSE` value to "CLOSED" and leaves the |
881 | ``LIC_FILES_CHKSUM`` value unset. This behavior allows you to continue | 881 | :term:`LIC_FILES_CHKSUM` value unset. This behavior allows you to continue |
882 | with development even though the settings are unlikely to be correct in | 882 | with development even though the settings are unlikely to be correct in |
883 | all cases. You should check the documentation or source files for the | 883 | all cases. You should check the documentation or source files for the |
884 | software you are building to determine the actual license. | 884 | software you are building to determine the actual license. |
@@ -904,7 +904,7 @@ mind: | |||
904 | hardcoding tools within the toolchain such as ``gcc`` and ``g++``. | 904 | hardcoding tools within the toolchain such as ``gcc`` and ``g++``. |
905 | 905 | ||
906 | - The environment in which Make runs is set up with various standard | 906 | - The environment in which Make runs is set up with various standard |
907 | variables for compilation (e.g. ``CC``, ``CXX``, and so forth) in a | 907 | variables for compilation (e.g. :term:`CC`, :term:`CXX`, and so forth) in a |
908 | similar manner to the environment set up by the SDK's environment | 908 | similar manner to the environment set up by the SDK's environment |
909 | setup script. One easy way to see these variables is to run the | 909 | setup script. One easy way to see these variables is to run the |
910 | ``devtool build`` command on the recipe and then look in | 910 | ``devtool build`` command on the recipe and then look in |
@@ -920,7 +920,7 @@ mind: | |||
920 | the command line, add the variable setting to | 920 | the command line, add the variable setting to |
921 | :term:`EXTRA_OEMAKE` or | 921 | :term:`EXTRA_OEMAKE` or |
922 | :term:`PACKAGECONFIG_CONFARGS` | 922 | :term:`PACKAGECONFIG_CONFARGS` |
923 | within the recipe. Here is an example using ``EXTRA_OEMAKE``:: | 923 | within the recipe. Here is an example using :term:`EXTRA_OEMAKE`:: |
924 | 924 | ||
925 | EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'" | 925 | EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'" |
926 | 926 | ||
@@ -1086,20 +1086,20 @@ extras specified by | |||
1086 | :term:`EXTRA_OECONF` or | 1086 | :term:`EXTRA_OECONF` or |
1087 | :term:`PACKAGECONFIG_CONFARGS` | 1087 | :term:`PACKAGECONFIG_CONFARGS` |
1088 | set within the recipe. If you wish to pass additional options, add them | 1088 | set within the recipe. If you wish to pass additional options, add them |
1089 | to ``EXTRA_OECONF`` or ``PACKAGECONFIG_CONFARGS``. Other supported build | 1089 | to :term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS`. Other supported build |
1090 | tools have similar variables (e.g. | 1090 | tools have similar variables (e.g. |
1091 | :term:`EXTRA_OECMAKE` for | 1091 | :term:`EXTRA_OECMAKE` for |
1092 | CMake, :term:`EXTRA_OESCONS` | 1092 | CMake, :term:`EXTRA_OESCONS` |
1093 | for Scons, and so forth). If you need to pass anything on the ``make`` | 1093 | for Scons, and so forth). If you need to pass anything on the ``make`` |
1094 | command line, you can use ``EXTRA_OEMAKE`` or the | 1094 | command line, you can use :term:`EXTRA_OEMAKE` or the |
1095 | :term:`PACKAGECONFIG_CONFARGS` | 1095 | :term:`PACKAGECONFIG_CONFARGS` |
1096 | variables to do so. | 1096 | variables to do so. |
1097 | 1097 | ||
1098 | You can use the ``devtool configure-help`` command to help you set the | 1098 | You can use the ``devtool configure-help`` command to help you set the |
1099 | arguments listed in the previous paragraph. The command determines the | 1099 | arguments listed in the previous paragraph. The command determines the |
1100 | exact options being passed, and shows them to you along with any custom | 1100 | exact options being passed, and shows them to you along with any custom |
1101 | arguments specified through ``EXTRA_OECONF`` or | 1101 | arguments specified through :term:`EXTRA_OECONF` or |
1102 | ``PACKAGECONFIG_CONFARGS``. If applicable, the command also shows you | 1102 | :term:`PACKAGECONFIG_CONFARGS`. If applicable, the command also shows you |
1103 | the output of the configure script's "--help" option as a | 1103 | the output of the configure script's "--help" option as a |
1104 | reference. | 1104 | reference. |
1105 | 1105 | ||
@@ -1151,16 +1151,16 @@ the ``oe-workdir/packages-split`` directory, which contains a | |||
1151 | subdirectory for each package. Apart from some advanced cases, the | 1151 | subdirectory for each package. Apart from some advanced cases, the |
1152 | :term:`PACKAGES` and | 1152 | :term:`PACKAGES` and |
1153 | :term:`FILES` variables controls | 1153 | :term:`FILES` variables controls |
1154 | splitting. The ``PACKAGES`` variable lists all of the packages to be | 1154 | splitting. The :term:`PACKAGES` variable lists all of the packages to be |
1155 | produced, while the ``FILES`` variable specifies which files to include | 1155 | produced, while the :term:`FILES` variable specifies which files to include |
1156 | in each package by using an override to specify the package. For | 1156 | in each package by using an override to specify the package. For |
1157 | example, ``FILES_${PN}`` specifies the files to go into the main package | 1157 | example, ``FILES_${PN}`` specifies the files to go into the main package |
1158 | (i.e. the main package has the same name as the recipe and | 1158 | (i.e. the main package has the same name as the recipe and |
1159 | ``${``\ :term:`PN`\ ``}`` evaluates to the | 1159 | ``${``\ :term:`PN`\ ``}`` evaluates to the |
1160 | recipe name). The order of the ``PACKAGES`` value is significant. For | 1160 | recipe name). The order of the :term:`PACKAGES` value is significant. For |
1161 | each installed file, the first package whose ``FILES`` value matches the | 1161 | each installed file, the first package whose :term:`FILES` value matches the |
1162 | file is the package into which the file goes. Both the ``PACKAGES`` and | 1162 | file is the package into which the file goes. Both the :term:`PACKAGES` and |
1163 | ``FILES`` variables have default values. Consequently, you might find | 1163 | :term:`FILES` variables have default values. Consequently, you might find |
1164 | you do not even need to set these variables in your recipe unless the | 1164 | you do not even need to set these variables in your recipe unless the |
1165 | software the recipe is building installs files into non-standard | 1165 | software the recipe is building installs files into non-standard |
1166 | locations. | 1166 | locations. |
diff --git a/documentation/sdk-manual/working-projects.rst b/documentation/sdk-manual/working-projects.rst index c482c38c70..27c69ca7dd 100644 --- a/documentation/sdk-manual/working-projects.rst +++ b/documentation/sdk-manual/working-projects.rst | |||
@@ -278,9 +278,9 @@ example: | |||
278 | $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux | 278 | $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux |
279 | 279 | ||
280 | 3. *Create the Makefile:* For this example, the Makefile contains | 280 | 3. *Create the Makefile:* For this example, the Makefile contains |
281 | two lines that can be used to set the ``CC`` variable. One line is | 281 | two lines that can be used to set the :term:`CC` variable. One line is |
282 | identical to the value that is set when you run the SDK environment | 282 | identical to the value that is set when you run the SDK environment |
283 | setup script, and the other line sets ``CC`` to "gcc", the default | 283 | setup script, and the other line sets :term:`CC` to "gcc", the default |
284 | GNU compiler on the build host:: | 284 | GNU compiler on the build host:: |
285 | 285 | ||
286 | # CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux | 286 | # CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux |
@@ -297,7 +297,7 @@ example: | |||
297 | 297 | ||
298 | 4. *Make the Project:* Use the ``make`` command to create the binary | 298 | 4. *Make the Project:* Use the ``make`` command to create the binary |
299 | output file. Because variables are commented out in the Makefile, the | 299 | output file. Because variables are commented out in the Makefile, the |
300 | value used for ``CC`` is the value set when the SDK environment setup | 300 | value used for :term:`CC` is the value set when the SDK environment setup |
301 | file was run:: | 301 | file was run:: |
302 | 302 | ||
303 | $ make | 303 | $ make |
@@ -306,10 +306,10 @@ example: | |||
306 | i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin | 306 | i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin |
307 | 307 | ||
308 | From the results of the previous command, you can see that | 308 | From the results of the previous command, you can see that |
309 | the compiler used was the compiler established through the ``CC`` | 309 | the compiler used was the compiler established through the :term:`CC` |
310 | variable defined in the setup script. | 310 | variable defined in the setup script. |
311 | 311 | ||
312 | You can override the ``CC`` environment variable with the same | 312 | You can override the :term:`CC` environment variable with the same |
313 | variable as set from the Makefile by uncommenting the line in the | 313 | variable as set from the Makefile by uncommenting the line in the |
314 | Makefile and running ``make`` again. | 314 | Makefile and running ``make`` again. |
315 | :: | 315 | :: |
@@ -333,7 +333,7 @@ example: | |||
333 | variable as part of the command line. Go into the Makefile and | 333 | variable as part of the command line. Go into the Makefile and |
334 | re-insert the comment character so that running ``make`` uses the | 334 | re-insert the comment character so that running ``make`` uses the |
335 | established SDK compiler. However, when you run ``make``, use a | 335 | established SDK compiler. However, when you run ``make``, use a |
336 | command-line argument to set ``CC`` to "gcc":: | 336 | command-line argument to set :term:`CC` to "gcc":: |
337 | 337 | ||
338 | $ make clean | 338 | $ make clean |
339 | rm -rf *.o | 339 | rm -rf *.o |