diff options
Diffstat (limited to 'documentation/sdk-manual/appendix-customizing.rst')
-rw-r--r-- | documentation/sdk-manual/appendix-customizing.rst | 187 |
1 files changed, 84 insertions, 103 deletions
diff --git a/documentation/sdk-manual/appendix-customizing.rst b/documentation/sdk-manual/appendix-customizing.rst index 97ade0801d..61091d83ba 100644 --- a/documentation/sdk-manual/appendix-customizing.rst +++ b/documentation/sdk-manual/appendix-customizing.rst | |||
@@ -1,11 +1,17 @@ | |||
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 | Customizing the Extensible SDK | 4 | Customizing the Extensible SDK standalone installer |
5 | ****************************** | 5 | *************************************************** |
6 | 6 | ||
7 | This appendix describes customizations you can apply to the extensible | 7 | This appendix describes customizations you can apply to the extensible |
8 | SDK. | 8 | SDK when using in the standalone installer version. |
9 | |||
10 | .. note:: | ||
11 | |||
12 | It is also possible to use the Extensible SDK functionality directly in a | ||
13 | Yocto build, avoiding separate installer artefacts. Please refer to | ||
14 | ":ref:`sdk-manual/extensible:Installing the Extensible SDK`" | ||
9 | 15 | ||
10 | Configuring the Extensible SDK | 16 | Configuring the Extensible SDK |
11 | ============================== | 17 | ============================== |
@@ -21,7 +27,7 @@ build system applies them against ``local.conf`` and ``auto.conf``: | |||
21 | specific to the :term:`Build Host`. | 27 | specific to the :term:`Build Host`. |
22 | 28 | ||
23 | - Variables listed in | 29 | - Variables listed in |
24 | :term:`SDK_LOCAL_CONF_BLACKLIST` | 30 | :term:`ESDK_LOCALCONF_REMOVE` |
25 | are excluded. These variables are not allowed through from the | 31 | are excluded. These variables are not allowed through from the |
26 | OpenEmbedded build system configuration into the extensible SDK | 32 | OpenEmbedded build system configuration into the extensible SDK |
27 | configuration. Typically, these variables are specific to the machine | 33 | configuration. Typically, these variables are specific to the machine |
@@ -29,23 +35,21 @@ build system applies them against ``local.conf`` and ``auto.conf``: | |||
29 | of the extensible SDK configuration. | 35 | of the extensible SDK configuration. |
30 | 36 | ||
31 | For a list of the variables excluded by default, see the | 37 | For a list of the variables excluded by default, see the |
32 | :term:`SDK_LOCAL_CONF_BLACKLIST` | 38 | :term:`ESDK_LOCALCONF_REMOVE` |
33 | in the glossary of the Yocto Project Reference Manual. | 39 | in the glossary of the Yocto Project Reference Manual. |
34 | 40 | ||
35 | - Variables listed in | 41 | - Variables listed in |
36 | :term:`SDK_LOCAL_CONF_WHITELIST` | 42 | :term:`ESDK_LOCALCONF_ALLOW` |
37 | are included. Including a variable in the value of | 43 | are included. Including a variable in the value of |
38 | ``SDK_LOCAL_CONF_WHITELIST`` overrides either of the previous two | 44 | :term:`ESDK_LOCALCONF_ALLOW` overrides either of the previous two |
39 | filters. The default value is blank. | 45 | filters. The default value is blank. |
40 | 46 | ||
41 | - Classes inherited globally with | 47 | - Classes inherited globally with :term:`INHERIT` that are listed in |
42 | :term:`INHERIT` that are listed in | 48 | :term:`ESDK_CLASS_INHERIT_DISABLE` are disabled. Using |
43 | :term:`SDK_INHERIT_BLACKLIST` | 49 | :term:`ESDK_CLASS_INHERIT_DISABLE` to disable these classes is the typical |
44 | are disabled. Using ``SDK_INHERIT_BLACKLIST`` to disable these | 50 | method to disable classes that are problematic or unnecessary in the SDK |
45 | classes is the typical method to disable classes that are problematic | 51 | context. The default value disables the |
46 | or unnecessary in the SDK context. The default value blacklists the | 52 | :ref:`ref-classes-buildhistory` and :ref:`ref-classes-icecc` classes. |
47 | :ref:`buildhistory <ref-classes-buildhistory>` | ||
48 | and :ref:`icecc <ref-classes-icecc>` classes. | ||
49 | 53 | ||
50 | Additionally, the contents of ``conf/sdk-extra.conf``, when present, are | 54 | Additionally, the contents of ``conf/sdk-extra.conf``, when present, are |
51 | appended to the end of ``conf/local.conf`` within the produced SDK, | 55 | appended to the end of ``conf/local.conf`` within the produced SDK, |
@@ -57,29 +61,24 @@ Adjusting the Extensible SDK to Suit Your Build Host's Setup | |||
57 | ============================================================ | 61 | ============================================================ |
58 | 62 | ||
59 | In most cases, the extensible SDK defaults should work with your :term:`Build | 63 | In most cases, the extensible SDK defaults should work with your :term:`Build |
60 | Host`'s setup. | 64 | Host`'s setup. However, there are cases when you might consider making |
61 | However, some cases exist for which you might consider making | ||
62 | adjustments: | 65 | adjustments: |
63 | 66 | ||
64 | - If your SDK configuration inherits additional classes using the | 67 | - If your SDK configuration inherits additional classes using the |
65 | :term:`INHERIT` variable and you | 68 | :term:`INHERIT` variable and you |
66 | do not need or want those classes enabled in the SDK, you can | 69 | do not need or want those classes enabled in the SDK, you can |
67 | blacklist them by adding them to the | 70 | disable them by adding them to the :term:`ESDK_CLASS_INHERIT_DISABLE` |
68 | :term:`SDK_INHERIT_BLACKLIST` | 71 | variable as described in the previous section. |
69 | variable as described in the fourth bullet of the previous section. | ||
70 | 72 | ||
71 | .. note:: | 73 | .. note:: |
72 | 74 | ||
73 | The default value of | 75 | The default value of :term:`ESDK_CLASS_INHERIT_DISABLE` |
74 | SDK_INHERIT_BLACKLIST | ||
75 | is set using the "?=" operator. Consequently, you will need to | 76 | is set using the "?=" operator. Consequently, you will need to |
76 | either define the entire list by using the "=" operator, or you | 77 | either define the entire list by using the "=" operator, or you |
77 | will need to append a value using either "_append" or the "+=" | 78 | will need to append a value using either ":append" or the "+=" |
78 | operator. You can learn more about these operators in the " | 79 | operator. You can learn more about these operators in the |
79 | Basic Syntax | 80 | ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:basic syntax`" |
80 | " section of the BitBake User Manual. | 81 | section of the BitBake User Manual. |
81 | |||
82 | . | ||
83 | 82 | ||
84 | - If you have classes or recipes that add additional tasks to the | 83 | - If you have classes or recipes that add additional tasks to the |
85 | standard build flow (i.e. the tasks execute as the recipe builds as | 84 | standard build flow (i.e. the tasks execute as the recipe builds as |
@@ -96,22 +95,20 @@ adjustments: | |||
96 | 95 | ||
97 | - 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 |
98 | the functionality the class provides in the extensible SDK. To | 97 | the functionality the class provides in the extensible SDK. To |
99 | disable the tasks, add the class to the ``SDK_INHERIT_BLACKLIST`` | 98 | disable the tasks, add the class to the :term:`ESDK_CLASS_INHERIT_DISABLE` |
100 | variable as described in the previous section. | 99 | variable as described in the previous section. |
101 | 100 | ||
102 | - 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 |
103 | the SDK can add additional items to the SDK after installation | 102 | the SDK can add additional items to the SDK after installation |
104 | without needing to build the items from source. See the "`Providing | 103 | without needing to build the items from source. See the |
105 | Additional Installable Extensible SDK | 104 | ":ref:`sdk-manual/appendix-customizing:providing additional installable extensible sdk content`" |
106 | Content <#sdk-providing-additional-installable-extensible-sdk-content>`__" | ||
107 | section for information. | 105 | section for information. |
108 | 106 | ||
109 | - If you want users of the SDK to be able to easily update the SDK, you | 107 | - If you want users of the SDK to be able to easily update the SDK, you |
110 | need to set the | 108 | need to set the |
111 | :term:`SDK_UPDATE_URL` | 109 | :term:`SDK_UPDATE_URL` |
112 | variable. For more information, see the "`Providing Updates to the | 110 | variable. For more information, see the |
113 | Extensible SDK After | 111 | ":ref:`sdk-manual/appendix-customizing:providing updates to the extensible sdk after installation`" |
114 | Installation <#sdk-providing-updates-to-the-extensible-sdk-after-installation>`__" | ||
115 | section. | 112 | section. |
116 | 113 | ||
117 | - If you have adjusted the list of files and directories that appear in | 114 | - If you have adjusted the list of files and directories that appear in |
@@ -131,41 +128,38 @@ adjustments: | |||
131 | .. note:: | 128 | .. note:: |
132 | 129 | ||
133 | You must also reflect this change in the value used for the | 130 | You must also reflect this change in the value used for the |
134 | COREBASE_FILES | 131 | :term:`COREBASE_FILES` variable as previously described. |
135 | variable as previously described. | ||
136 | 132 | ||
137 | Changing the Extensible SDK Installer Title | 133 | Changing the Extensible SDK Installer Title |
138 | =========================================== | 134 | =========================================== |
139 | 135 | ||
140 | You can change the displayed title for the SDK installer by setting the | 136 | You can change the displayed title for the SDK installer by setting the |
141 | :term:`SDK_TITLE` variable and then | 137 | :term:`SDK_TITLE` variable and then |
142 | rebuilding the the SDK installer. For information on how to build an SDK | 138 | rebuilding the SDK installer. For information on how to build an SDK |
143 | installer, see the "`Building an SDK | 139 | installer, see the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" |
144 | Installer <#sdk-building-an-sdk-installer>`__" section. | 140 | section. |
145 | 141 | ||
146 | By default, this title is derived from | 142 | By default, this title is derived from |
147 | :term:`DISTRO_NAME` when it is | 143 | :term:`DISTRO_NAME` when it is |
148 | set. If the ``DISTRO_NAME`` variable is not set, the title is derived | 144 | set. If the :term:`DISTRO_NAME` variable is not set, the title is derived |
149 | from the :term:`DISTRO` variable. | 145 | from the :term:`DISTRO` variable. |
150 | 146 | ||
151 | The | 147 | The |
152 | :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` | 148 | :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` |
153 | class defines the default value of the ``SDK_TITLE`` variable as | 149 | class defines the default value of the :term:`SDK_TITLE` variable as |
154 | follows: | 150 | follows:: |
155 | :: | ||
156 | 151 | ||
157 | SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" | 152 | SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" |
158 | 153 | ||
159 | While several ways exist to change this variable, an efficient method is | 154 | While there are several ways of changing this variable, an efficient method is |
160 | to set the variable in your distribution's configuration file. Doing so | 155 | to set the variable in your distribution's configuration file. Doing so |
161 | creates an SDK installer title that applies across your distribution. As | 156 | creates an SDK installer title that applies across your distribution. As |
162 | an example, assume you have your own layer for your distribution named | 157 | an example, assume you have your own layer for your distribution named |
163 | "meta-mydistro" and you are using the same type of file hierarchy as | 158 | "meta-mydistro" and you are using the same type of file hierarchy as |
164 | does the default "poky" distribution. If so, you could update the | 159 | does the default "poky" distribution. If so, you could update the |
165 | ``SDK_TITLE`` variable in the | 160 | :term:`SDK_TITLE` variable in the |
166 | ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following | 161 | ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following |
167 | form: | 162 | form:: |
168 | :: | ||
169 | 163 | ||
170 | SDK_TITLE = "your_title" | 164 | SDK_TITLE = "your_title" |
171 | 165 | ||
@@ -178,27 +172,24 @@ perform additional steps. These steps make it possible for anyone using | |||
178 | the installed SDKs to update the installed SDKs by using the | 172 | the installed SDKs to update the installed SDKs by using the |
179 | ``devtool sdk-update`` command: | 173 | ``devtool sdk-update`` command: |
180 | 174 | ||
181 | 1. Create a directory that can be shared over HTTP or HTTPS. You can do | 175 | #. Create a directory that can be shared over HTTP or HTTPS. You can do |
182 | this by setting up a web server such as an `Apache HTTP | 176 | this by setting up a web server such as an :wikipedia:`Apache HTTP Server |
183 | Server <https://en.wikipedia.org/wiki/Apache_HTTP_Server>`__ or | 177 | <Apache_HTTP_Server>` or :wikipedia:`Nginx <Nginx>` server in the cloud |
184 | `Nginx <https://en.wikipedia.org/wiki/Nginx>`__ server in the cloud | ||
185 | to host the directory. This directory must contain the published SDK. | 178 | to host the directory. This directory must contain the published SDK. |
186 | 179 | ||
187 | 2. Set the | 180 | #. Set the |
188 | :term:`SDK_UPDATE_URL` | 181 | :term:`SDK_UPDATE_URL` |
189 | variable to point to the corresponding HTTP or HTTPS URL. Setting | 182 | variable to point to the corresponding HTTP or HTTPS URL. Setting |
190 | this variable causes any SDK built to default to that URL and thus, | 183 | this variable causes any SDK built to default to that URL and thus, |
191 | the user does not have to pass the URL to the ``devtool sdk-update`` | 184 | the user does not have to pass the URL to the ``devtool sdk-update`` |
192 | command as described in the "`Applying Updates to an Installed | 185 | command as described in the |
193 | Extensible | 186 | ":ref:`sdk-manual/extensible:applying updates to an installed extensible sdk`" |
194 | SDK <#sdk-applying-updates-to-an-installed-extensible-sdk>`__" | ||
195 | section. | 187 | section. |
196 | 188 | ||
197 | 3. Build the extensible SDK normally (i.e., use the | 189 | #. Build the extensible SDK normally (i.e., use the |
198 | ``bitbake -c populate_sdk_ext`` imagename command). | 190 | ``bitbake -c populate_sdk_ext`` imagename command). |
199 | 191 | ||
200 | 4. Publish the SDK using the following command: | 192 | #. Publish the SDK using the following command:: |
201 | :: | ||
202 | 193 | ||
203 | $ oe-publish-sdk some_path/sdk-installer.sh path_to_shared_http_directory | 194 | $ oe-publish-sdk some_path/sdk-installer.sh path_to_shared_http_directory |
204 | 195 | ||
@@ -208,9 +199,9 @@ the installed SDKs to update the installed SDKs by using the | |||
208 | 199 | ||
209 | Completing the above steps allows users of the existing installed SDKs | 200 | Completing the above steps allows users of the existing installed SDKs |
210 | to simply run ``devtool sdk-update`` to retrieve and apply the latest | 201 | to simply run ``devtool sdk-update`` to retrieve and apply the latest |
211 | updates. See the "`Applying Updates to an Installed Extensible | 202 | updates. See the |
212 | SDK <#sdk-applying-updates-to-an-installed-extensible-sdk>`__" section | 203 | ":ref:`sdk-manual/extensible:applying updates to an installed extensible sdk`" |
213 | for further information. | 204 | section for further information. |
214 | 205 | ||
215 | Changing the Default SDK Installation Directory | 206 | Changing the Default SDK Installation Directory |
216 | =============================================== | 207 | =============================================== |
@@ -221,26 +212,24 @@ installation directory for the SDK is based on the | |||
221 | :term:`SDKEXTPATH` variables from | 212 | :term:`SDKEXTPATH` variables from |
222 | within the | 213 | within the |
223 | :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` | 214 | :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` |
224 | class as follows: | 215 | class as follows:: |
225 | :: | ||
226 | 216 | ||
227 | SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" | 217 | SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" |
228 | 218 | ||
229 | You can | 219 | You can |
230 | change this default installation directory by specifically setting the | 220 | change this default installation directory by specifically setting the |
231 | ``SDKEXTPATH`` variable. | 221 | :term:`SDKEXTPATH` variable. |
232 | 222 | ||
233 | While a number of ways exist through which you can set this variable, | 223 | While there are several ways of setting this variable, |
234 | the method that makes the most sense is to set the variable in your | 224 | the method that makes the most sense is to set the variable in your |
235 | distribution's configuration file. Doing so creates an SDK installer | 225 | distribution's configuration file. Doing so creates an SDK installer |
236 | default directory that applies across your distribution. As an example, | 226 | default directory that applies across your distribution. As an example, |
237 | assume you have your own layer for your distribution named | 227 | assume you have your own layer for your distribution named |
238 | "meta-mydistro" and you are using the same type of file hierarchy as | 228 | "meta-mydistro" and you are using the same type of file hierarchy as |
239 | does the default "poky" distribution. If so, you could update the | 229 | does the default "poky" distribution. If so, you could update the |
240 | ``SDKEXTPATH`` variable in the | 230 | :term:`SDKEXTPATH` variable in the |
241 | ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following | 231 | ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following |
242 | form: | 232 | form:: |
243 | :: | ||
244 | 233 | ||
245 | SDKEXTPATH = "some_path_for_your_installed_sdk" | 234 | SDKEXTPATH = "some_path_for_your_installed_sdk" |
246 | 235 | ||
@@ -255,33 +244,30 @@ If you want the users of an extensible SDK you build to be able to add | |||
255 | items to the SDK without requiring the users to build the items from | 244 | items to the SDK without requiring the users to build the items from |
256 | source, you need to do a number of things: | 245 | source, you need to do a number of things: |
257 | 246 | ||
258 | 1. Ensure the additional items you want the user to be able to install | 247 | #. Ensure the additional items you want the user to be able to install |
259 | are already built: | 248 | are already built: |
260 | 249 | ||
261 | - Build the items explicitly. You could use one or more "meta" | 250 | - Build the items explicitly. You could use one or more "meta" |
262 | recipes that depend on lists of other recipes. | 251 | recipes that depend on lists of other recipes. |
263 | 252 | ||
264 | - Build the "world" target and set | 253 | - Build the "world" target and set |
265 | ``EXCLUDE_FROM_WORLD_pn-``\ recipename for the recipes you do not | 254 | ``EXCLUDE_FROM_WORLD:pn-``\ recipename for the recipes you do not |
266 | want built. See the | 255 | want built. See the |
267 | :term:`EXCLUDE_FROM_WORLD` | 256 | :term:`EXCLUDE_FROM_WORLD` |
268 | variable for additional information. | 257 | variable for additional information. |
269 | 258 | ||
270 | 2. Expose the ``sstate-cache`` directory produced by the build. | 259 | #. Expose the ``sstate-cache`` directory produced by the build. |
271 | Typically, you expose this directory by making it available through | 260 | Typically, you expose this directory by making it available through |
272 | an `Apache HTTP | 261 | an :wikipedia:`Apache HTTP Server <Apache_HTTP_Server>` or |
273 | Server <https://en.wikipedia.org/wiki/Apache_HTTP_Server>`__ or | 262 | :wikipedia:`Nginx <Nginx>` server. |
274 | `Nginx <https://en.wikipedia.org/wiki/Nginx>`__ server. | ||
275 | 263 | ||
276 | 3. Set the appropriate configuration so that the produced SDK knows how | 264 | #. Set the appropriate configuration so that the produced SDK knows how |
277 | to find the configuration. The variable you need to set is | 265 | to find the configuration. The variable you need to set is |
278 | :term:`SSTATE_MIRRORS`: | 266 | :term:`SSTATE_MIRRORS`:: |
279 | :: | ||
280 | 267 | ||
281 | SSTATE_MIRRORS = "file://.* http://example.com/some_path/sstate-cache/PATH" | 268 | SSTATE_MIRRORS = "file://.* https://example.com/some_path/sstate-cache/PATH" |
282 | 269 | ||
283 | You can set the | 270 | You can set the :term:`SSTATE_MIRRORS` variable in two different places: |
284 | ``SSTATE_MIRRORS`` variable in two different places: | ||
285 | 271 | ||
286 | - If the mirror value you are setting is appropriate to be set for | 272 | - If the mirror value you are setting is appropriate to be set for |
287 | both the OpenEmbedded build system that is actually building the | 273 | both the OpenEmbedded build system that is actually building the |
@@ -289,24 +275,21 @@ source, you need to do a number of things: | |||
289 | places or it will fail quickly on the OpenEmbedded build system | 275 | places or it will fail quickly on the OpenEmbedded build system |
290 | side, and its contents will not interfere with the build), then | 276 | side, and its contents will not interfere with the build), then |
291 | you can set the variable in your ``local.conf`` or custom distro | 277 | you can set the variable in your ``local.conf`` or custom distro |
292 | configuration file. You can then "whitelist" the variable through | 278 | configuration file. You can then pass the variable to the SDK by |
293 | to the SDK by adding the following: | 279 | adding the following:: |
294 | :: | ||
295 | 280 | ||
296 | SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS" | 281 | ESDK_LOCALCONF_ALLOW = "SSTATE_MIRRORS" |
297 | 282 | ||
298 | - Alternatively, if you just want to set the ``SSTATE_MIRRORS`` | 283 | - Alternatively, if you just want to set the :term:`SSTATE_MIRRORS` |
299 | variable's value for the SDK alone, create a | 284 | variable's value for the SDK alone, create a ``conf/sdk-extra.conf`` |
300 | ``conf/sdk-extra.conf`` file either in your | 285 | file either in your :term:`Build Directory` or within any |
301 | :term:`Build Directory` or within any | 286 | layer and put your :term:`SSTATE_MIRRORS` setting within that file. |
302 | layer and put your ``SSTATE_MIRRORS`` setting within that file. | ||
303 | 287 | ||
304 | .. note:: | 288 | .. note:: |
305 | 289 | ||
306 | This second option is the safest option should you have any | 290 | This second option is the safest option should you have any |
307 | doubts as to which method to use when setting | 291 | doubts as to which method to use when setting |
308 | SSTATE_MIRRORS | 292 | :term:`SSTATE_MIRRORS` |
309 | . | ||
310 | 293 | ||
311 | Minimizing the Size of the Extensible SDK Installer Download | 294 | Minimizing the Size of the Extensible SDK Installer Download |
312 | ============================================================ | 295 | ============================================================ |
@@ -316,8 +299,7 @@ everything needed to reconstruct the image for which the SDK was built. | |||
316 | This bundling can lead to an SDK installer file that is a Gigabyte or | 299 | This bundling can lead to an SDK installer file that is a Gigabyte or |
317 | more in size. If the size of this file causes a problem, you can build | 300 | more in size. If the size of this file causes a problem, you can build |
318 | an SDK that has just enough in it to install and provide access to the | 301 | an SDK that has just enough in it to install and provide access to the |
319 | ``devtool command`` by setting the following in your configuration: | 302 | ``devtool command`` by setting the following in your configuration:: |
320 | :: | ||
321 | 303 | ||
322 | SDK_EXT_TYPE = "minimal" | 304 | SDK_EXT_TYPE = "minimal" |
323 | 305 | ||
@@ -339,20 +321,19 @@ information enables the ``devtool search`` command to return useful | |||
339 | results. | 321 | results. |
340 | 322 | ||
341 | To facilitate this wider range of information, you would need to set the | 323 | To facilitate this wider range of information, you would need to set the |
342 | following: | 324 | following:: |
343 | :: | ||
344 | 325 | ||
345 | SDK_INCLUDE_PKGDATA = "1" | 326 | SDK_INCLUDE_PKGDATA = "1" |
346 | 327 | ||
347 | See the :term:`SDK_INCLUDE_PKGDATA` variable for additional information. | 328 | See the :term:`SDK_INCLUDE_PKGDATA` variable for additional information. |
348 | 329 | ||
349 | Setting the ``SDK_INCLUDE_PKGDATA`` variable as shown causes the "world" | 330 | Setting the :term:`SDK_INCLUDE_PKGDATA` variable as shown causes the "world" |
350 | target to be built so that information for all of the recipes included | 331 | target to be built so that information for all of the recipes included |
351 | within it are available. Having these recipes available increases build | 332 | within it are available. Having these recipes available increases build |
352 | time significantly and increases the size of the SDK installer by 30-80 | 333 | time significantly and increases the size of the SDK installer by 30-80 |
353 | Mbytes depending on how many recipes are included in your configuration. | 334 | Mbytes depending on how many recipes are included in your configuration. |
354 | 335 | ||
355 | You can use ``EXCLUDE_FROM_WORLD_pn-``\ recipename for recipes you want | 336 | You can use ``EXCLUDE_FROM_WORLD:pn-``\ recipename for recipes you want |
356 | to exclude. However, it is assumed that you would need to be building | 337 | to exclude. However, it is assumed that you would need to be building |
357 | the "world" target if you want to provide additional items to the SDK. | 338 | the "world" target if you want to provide additional items to the SDK. |
358 | Consequently, building for "world" should not represent undue overhead | 339 | Consequently, building for "world" should not represent undue overhead |
@@ -363,15 +344,15 @@ in most cases. | |||
363 | If you set | 344 | If you set |
364 | SDK_EXT_TYPE | 345 | SDK_EXT_TYPE |
365 | to "minimal", then providing a shared state mirror is mandatory so | 346 | to "minimal", then providing a shared state mirror is mandatory so |
366 | that items can be installed as needed. See the " | 347 | that items can be installed as needed. See the |
367 | Providing Additional Installable Extensible SDK Content | 348 | :ref:`sdk-manual/appendix-customizing:providing additional installable extensible sdk content` |
368 | " section for more information. | 349 | section for more information. |
369 | 350 | ||
370 | You can explicitly control whether or not to include the toolchain when | 351 | You can explicitly control whether or not to include the toolchain when |
371 | you build an SDK by setting the | 352 | you build an SDK by setting the |
372 | :term:`SDK_INCLUDE_TOOLCHAIN` | 353 | :term:`SDK_INCLUDE_TOOLCHAIN` |
373 | variable to "1". In particular, it is useful to include the toolchain | 354 | variable to "1". In particular, it is useful to include the toolchain |
374 | when you have set ``SDK_EXT_TYPE`` to "minimal", which by default, | 355 | when you have set :term:`SDK_EXT_TYPE` to "minimal", which by default, |
375 | excludes the toolchain. Also, it is helpful if you are building a small | 356 | excludes the toolchain. Also, it is helpful if you are building a small |
376 | SDK for use with an IDE or some other tool where you do not want to take | 357 | SDK for use with an IDE or some other tool where you do not want to take |
377 | extra steps to install a toolchain. | 358 | extra steps to install a toolchain. |