diff options
Diffstat (limited to 'bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst')
-rw-r--r-- | bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst | 789 |
1 files changed, 506 insertions, 283 deletions
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst index 6469f9d1a4..899e584f91 100644 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst +++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst | |||
@@ -23,22 +23,31 @@ overview of their function and contents. | |||
23 | systems extend the functionality of the variable as it is | 23 | systems extend the functionality of the variable as it is |
24 | described here in this glossary. | 24 | described here in this glossary. |
25 | 25 | ||
26 | - Finally, there are variables mentioned in this glossary that do | ||
27 | not appear in the BitBake glossary. These other variables are | ||
28 | variables used in systems that use BitBake. | ||
29 | |||
30 | .. glossary:: | 26 | .. glossary:: |
27 | :sorted: | ||
31 | 28 | ||
32 | :term:`ASSUME_PROVIDED` | 29 | :term:`ASSUME_PROVIDED` |
33 | Lists recipe names (:term:`PN` values) BitBake does not | 30 | Lists recipe names (:term:`PN` values) BitBake does not |
34 | attempt to build. Instead, BitBake assumes these recipes have already | 31 | attempt to build. Instead, BitBake assumes these recipes have already |
35 | been built. | 32 | been built. |
36 | 33 | ||
37 | In OpenEmbedded-Core, ``ASSUME_PROVIDED`` mostly specifies native | 34 | In OpenEmbedded-Core, :term:`ASSUME_PROVIDED` mostly specifies native |
38 | tools that should not be built. An example is ``git-native``, which | 35 | tools that should not be built. An example is ``git-native``, which |
39 | when specified allows for the Git binary from the host to be used | 36 | when specified allows for the Git binary from the host to be used |
40 | rather than building ``git-native``. | 37 | rather than building ``git-native``. |
41 | 38 | ||
39 | :term:`AZ_SAS` | ||
40 | Azure Storage Shared Access Signature, when using the | ||
41 | :ref:`Azure Storage fetcher <bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` | ||
42 | This variable can be defined to be used by the fetcher to authenticate | ||
43 | and gain access to non-public artifacts:: | ||
44 | |||
45 | AZ_SAS = ""se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>"" | ||
46 | |||
47 | For more information see Microsoft's Azure Storage documentation at | ||
48 | https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview | ||
49 | |||
50 | |||
42 | :term:`B` | 51 | :term:`B` |
43 | The directory in which BitBake executes functions during a recipe's | 52 | The directory in which BitBake executes functions during a recipe's |
44 | build process. | 53 | build process. |
@@ -74,14 +83,41 @@ overview of their function and contents. | |||
74 | 83 | ||
75 | - Attempts to access networks not in the host list cause a failure. | 84 | - Attempts to access networks not in the host list cause a failure. |
76 | 85 | ||
77 | Using ``BB_ALLOWED_NETWORKS`` in conjunction with | 86 | Using :term:`BB_ALLOWED_NETWORKS` in conjunction with |
78 | :term:`PREMIRRORS` is very useful. Adding the | 87 | :term:`PREMIRRORS` is very useful. Adding the |
79 | host you want to use to ``PREMIRRORS`` results in the source code | 88 | host you want to use to :term:`PREMIRRORS` results in the source code |
80 | being fetched from an allowed location and avoids raising an error | 89 | being fetched from an allowed location and avoids raising an error |
81 | when a host that is not allowed is in a | 90 | when a host that is not allowed is in a |
82 | :term:`SRC_URI` statement. This is because the | 91 | :term:`SRC_URI` statement. This is because the |
83 | fetcher does not attempt to use the host listed in ``SRC_URI`` after | 92 | fetcher does not attempt to use the host listed in :term:`SRC_URI` after |
84 | a successful fetch from the ``PREMIRRORS`` occurs. | 93 | a successful fetch from the :term:`PREMIRRORS` occurs. |
94 | |||
95 | :term:`BB_BASEHASH_IGNORE_VARS` | ||
96 | Lists variables that are excluded from checksum and dependency data. | ||
97 | Variables that are excluded can therefore change without affecting | ||
98 | the checksum mechanism. A common example would be the variable for | ||
99 | the path of the build. BitBake's output should not (and usually does | ||
100 | not) depend on the directory in which it was built. | ||
101 | |||
102 | :term:`BB_CACHEDIR` | ||
103 | Specifies the code parser cache directory (distinct from :term:`CACHE` | ||
104 | and :term:`PERSISTENT_DIR` although they can be set to the same value | ||
105 | if desired). The default value is "${TOPDIR}/cache". | ||
106 | |||
107 | :term:`BB_CHECK_SSL_CERTS` | ||
108 | Specifies if SSL certificates should be checked when fetching. The default | ||
109 | value is ``1`` and certificates are not checked if the value is set to ``0``. | ||
110 | |||
111 | :term:`BB_HASH_CODEPARSER_VALS` | ||
112 | Specifies values for variables to use when populating the codeparser cache. | ||
113 | This can be used selectively to set dummy values for variables to avoid | ||
114 | the codeparser cache growing on every parse. Variables that would typically | ||
115 | be included are those where the value is not significant for where the | ||
116 | codeparser cache is used (i.e. when calculating variable dependencies for | ||
117 | code fragments.) The value is space-separated without quoting values, for | ||
118 | example:: | ||
119 | |||
120 | BB_HASH_CODEPARSER_VALS = "T=/ WORKDIR=/ DATE=1234 TIME=1234" | ||
85 | 121 | ||
86 | :term:`BB_CONSOLELOG` | 122 | :term:`BB_CONSOLELOG` |
87 | Specifies the path to a log file into which BitBake's user interface | 123 | Specifies the path to a log file into which BitBake's user interface |
@@ -117,14 +153,14 @@ overview of their function and contents. | |||
117 | you to control the build based on these parameters. | 153 | you to control the build based on these parameters. |
118 | 154 | ||
119 | Disk space monitoring is disabled by default. When setting this | 155 | Disk space monitoring is disabled by default. When setting this |
120 | variable, use the following form: :: | 156 | variable, use the following form:: |
121 | 157 | ||
122 | BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]" | 158 | BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]" |
123 | 159 | ||
124 | where: | 160 | where: |
125 | 161 | ||
126 | <action> is: | 162 | <action> is: |
127 | ABORT: Immediately abort the build when | 163 | HALT: Immediately halt the build when |
128 | a threshold is broken. | 164 | a threshold is broken. |
129 | STOPTASKS: Stop the build after the currently | 165 | STOPTASKS: Stop the build after the currently |
130 | executing tasks have finished when | 166 | executing tasks have finished when |
@@ -153,48 +189,48 @@ overview of their function and contents. | |||
153 | not specify G, M, or K, Kbytes is assumed by | 189 | not specify G, M, or K, Kbytes is assumed by |
154 | default. Do not use GB, MB, or KB. | 190 | default. Do not use GB, MB, or KB. |
155 | 191 | ||
156 | Here are some examples: :: | 192 | Here are some examples:: |
157 | 193 | ||
158 | BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" | 194 | BB_DISKMON_DIRS = "HALT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" |
159 | BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G" | 195 | BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G" |
160 | BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K" | 196 | BB_DISKMON_DIRS = "HALT,${TMPDIR},,100K" |
161 | 197 | ||
162 | The first example works only if you also set the | 198 | The first example works only if you also set the |
163 | :term:`BB_DISKMON_WARNINTERVAL` | 199 | :term:`BB_DISKMON_WARNINTERVAL` |
164 | variable. This example causes the build system to immediately abort | 200 | variable. This example causes the build system to immediately halt |
165 | when either the disk space in ``${TMPDIR}`` drops below 1 Gbyte or | 201 | when either the disk space in ``${TMPDIR}`` drops below 1 Gbyte or |
166 | the available free inodes drops below 100 Kbytes. Because two | 202 | the available free inodes drops below 100 Kbytes. Because two |
167 | directories are provided with the variable, the build system also | 203 | directories are provided with the variable, the build system also |
168 | issues a warning when the disk space in the ``${SSTATE_DIR}`` | 204 | issues a warning when the disk space in the ``${SSTATE_DIR}`` |
169 | directory drops below 1 Gbyte or the number of free inodes drops | 205 | directory drops below 1 Gbyte or the number of free inodes drops |
170 | below 100 Kbytes. Subsequent warnings are issued during intervals as | 206 | below 100 Kbytes. Subsequent warnings are issued during intervals as |
171 | defined by the ``BB_DISKMON_WARNINTERVAL`` variable. | 207 | defined by the :term:`BB_DISKMON_WARNINTERVAL` variable. |
172 | 208 | ||
173 | The second example stops the build after all currently executing | 209 | The second example stops the build after all currently executing |
174 | tasks complete when the minimum disk space in the ``${TMPDIR}`` | 210 | tasks complete when the minimum disk space in the ``${TMPDIR}`` |
175 | directory drops below 1 Gbyte. No disk monitoring occurs for the free | 211 | directory drops below 1 Gbyte. No disk monitoring occurs for the free |
176 | inodes in this case. | 212 | inodes in this case. |
177 | 213 | ||
178 | The final example immediately aborts the build when the number of | 214 | The final example immediately halts the build when the number of |
179 | free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No | 215 | free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No |
180 | disk space monitoring for the directory itself occurs in this case. | 216 | disk space monitoring for the directory itself occurs in this case. |
181 | 217 | ||
182 | :term:`BB_DISKMON_WARNINTERVAL` | 218 | :term:`BB_DISKMON_WARNINTERVAL` |
183 | Defines the disk space and free inode warning intervals. | 219 | Defines the disk space and free inode warning intervals. |
184 | 220 | ||
185 | If you are going to use the ``BB_DISKMON_WARNINTERVAL`` variable, you | 221 | If you are going to use the :term:`BB_DISKMON_WARNINTERVAL` variable, you |
186 | must also use the :term:`BB_DISKMON_DIRS` | 222 | must also use the :term:`BB_DISKMON_DIRS` |
187 | variable and define its action as "WARN". During the build, | 223 | variable and define its action as "WARN". During the build, |
188 | subsequent warnings are issued each time disk space or number of free | 224 | subsequent warnings are issued each time disk space or number of free |
189 | inodes further reduces by the respective interval. | 225 | inodes further reduces by the respective interval. |
190 | 226 | ||
191 | If you do not provide a ``BB_DISKMON_WARNINTERVAL`` variable and you | 227 | If you do not provide a :term:`BB_DISKMON_WARNINTERVAL` variable and you |
192 | do use ``BB_DISKMON_DIRS`` with the "WARN" action, the disk | 228 | do use :term:`BB_DISKMON_DIRS` with the "WARN" action, the disk |
193 | monitoring interval defaults to the following: | 229 | monitoring interval defaults to the following: |
194 | BB_DISKMON_WARNINTERVAL = "50M,5K" | 230 | BB_DISKMON_WARNINTERVAL = "50M,5K" |
195 | 231 | ||
196 | When specifying the variable in your configuration file, use the | 232 | When specifying the variable in your configuration file, use the |
197 | following form: :: | 233 | following form:: |
198 | 234 | ||
199 | BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>" | 235 | BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>" |
200 | 236 | ||
@@ -210,7 +246,7 @@ overview of their function and contents. | |||
210 | G, M, or K for Gbytes, Mbytes, or Kbytes, | 246 | G, M, or K for Gbytes, Mbytes, or Kbytes, |
211 | respectively. You cannot use GB, MB, or KB. | 247 | respectively. You cannot use GB, MB, or KB. |
212 | 248 | ||
213 | Here is an example: :: | 249 | Here is an example:: |
214 | 250 | ||
215 | BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K" | 251 | BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K" |
216 | BB_DISKMON_WARNINTERVAL = "50M,5K" | 252 | BB_DISKMON_WARNINTERVAL = "50M,5K" |
@@ -222,23 +258,23 @@ overview of their function and contents. | |||
222 | based on the interval occur each time a respective interval is | 258 | based on the interval occur each time a respective interval is |
223 | reached beyond the initial warning (i.e. 1 Gbytes and 100 Kbytes). | 259 | reached beyond the initial warning (i.e. 1 Gbytes and 100 Kbytes). |
224 | 260 | ||
225 | :term:`BB_ENV_WHITELIST` | 261 | :term:`BB_ENV_PASSTHROUGH` |
226 | Specifies the internal whitelist of variables to allow through from | 262 | Specifies the internal list of variables to allow through from |
227 | the external environment into BitBake's datastore. If the value of | 263 | the external environment into BitBake's datastore. If the value of |
228 | this variable is not specified (which is the default), the following | 264 | this variable is not specified (which is the default), the following |
229 | list is used: :term:`BBPATH`, :term:`BB_PRESERVE_ENV`, | 265 | list is used: :term:`BBPATH`, :term:`BB_PRESERVE_ENV`, |
230 | :term:`BB_ENV_WHITELIST`, and :term:`BB_ENV_EXTRAWHITE`. | 266 | :term:`BB_ENV_PASSTHROUGH`, and :term:`BB_ENV_PASSTHROUGH_ADDITIONS`. |
231 | 267 | ||
232 | .. note:: | 268 | .. note:: |
233 | 269 | ||
234 | You must set this variable in the external environment in order | 270 | You must set this variable in the external environment in order |
235 | for it to work. | 271 | for it to work. |
236 | 272 | ||
237 | :term:`BB_ENV_EXTRAWHITE` | 273 | :term:`BB_ENV_PASSTHROUGH_ADDITIONS` |
238 | Specifies an additional set of variables to allow through (whitelist) | 274 | Specifies an additional set of variables to allow through from the |
239 | from the external environment into BitBake's datastore. This list of | 275 | external environment into BitBake's datastore. This list of variables |
240 | variables are on top of the internal list set in | 276 | are on top of the internal list set in |
241 | :term:`BB_ENV_WHITELIST`. | 277 | :term:`BB_ENV_PASSTHROUGH`. |
242 | 278 | ||
243 | .. note:: | 279 | .. note:: |
244 | 280 | ||
@@ -254,76 +290,82 @@ overview of their function and contents. | |||
254 | :term:`BB_FILENAME` | 290 | :term:`BB_FILENAME` |
255 | Contains the filename of the recipe that owns the currently running | 291 | Contains the filename of the recipe that owns the currently running |
256 | task. For example, if the ``do_fetch`` task that resides in the | 292 | task. For example, if the ``do_fetch`` task that resides in the |
257 | ``my-recipe.bb`` is executing, the ``BB_FILENAME`` variable contains | 293 | ``my-recipe.bb`` is executing, the :term:`BB_FILENAME` variable contains |
258 | "/foo/path/my-recipe.bb". | 294 | "/foo/path/my-recipe.bb". |
259 | 295 | ||
260 | :term:`BBFILES_DYNAMIC` | 296 | :term:`BB_GENERATE_MIRROR_TARBALLS` |
261 | Activates content depending on presence of identified layers. You | 297 | Causes tarballs of the Git repositories, including the Git metadata, |
262 | identify the layers by the collections that the layers define. | 298 | to be placed in the :term:`DL_DIR` directory. Anyone |
299 | wishing to create a source mirror would want to enable this variable. | ||
263 | 300 | ||
264 | Use the ``BBFILES_DYNAMIC`` variable to avoid ``.bbappend`` files whose | 301 | For performance reasons, creating and placing tarballs of the Git |
265 | corresponding ``.bb`` file is in a layer that attempts to modify other | 302 | repositories is not the default action by BitBake. :: |
266 | layers through ``.bbappend`` but does not want to introduce a hard | ||
267 | dependency on those other layers. | ||
268 | 303 | ||
269 | Additionally you can prefix the rule with "!" to add ``.bbappend`` and | 304 | BB_GENERATE_MIRROR_TARBALLS = "1" |
270 | ``.bb`` files in case a layer is not present. Use this avoid hard | ||
271 | dependency on those other layers. | ||
272 | 305 | ||
273 | Use the following form for ``BBFILES_DYNAMIC``: :: | 306 | :term:`BB_GENERATE_SHALLOW_TARBALLS` |
307 | Setting this variable to "1" when :term:`BB_GIT_SHALLOW` is also set to | ||
308 | "1" causes bitbake to generate shallow mirror tarballs when fetching git | ||
309 | repositories. The number of commits included in the shallow mirror | ||
310 | tarballs is controlled by :term:`BB_GIT_SHALLOW_DEPTH`. | ||
274 | 311 | ||
275 | collection_name:filename_pattern | 312 | If both :term:`BB_GIT_SHALLOW` and :term:`BB_GENERATE_MIRROR_TARBALLS` are |
313 | enabled, bitbake will generate shallow mirror tarballs by default for git | ||
314 | repositories. This separate variable exists so that shallow tarball | ||
315 | generation can be enabled without needing to also enable normal mirror | ||
316 | generation if it is not desired. | ||
276 | 317 | ||
277 | The following example identifies two collection names and two filename | 318 | For example usage, see :term:`BB_GIT_SHALLOW`. |
278 | patterns: :: | ||
279 | 319 | ||
280 | BBFILES_DYNAMIC += "\ | 320 | :term:`BB_GIT_SHALLOW` |
281 | clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \ | 321 | Setting this variable to "1" enables the support for fetching, using and |
282 | core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \ | 322 | generating mirror tarballs of `shallow git repositories <https://riptutorial.com/git/example/4584/shallow-clone>`_. |
283 | " | 323 | The external `git-make-shallow <https://git.openembedded.org/bitbake/tree/bin/git-make-shallow>`_ |
324 | script is used for shallow mirror tarball creation. | ||
284 | 325 | ||
285 | When the collection name is prefixed with "!" it will add the file pattern in case | 326 | When :term:`BB_GIT_SHALLOW` is enabled, bitbake will attempt to fetch a shallow |
286 | the layer is absent: :: | 327 | mirror tarball. If the shallow mirror tarball cannot be fetched, it will |
328 | try to fetch the full mirror tarball and use that. | ||
287 | 329 | ||
288 | BBFILES_DYNAMIC += "\ | 330 | When a mirror tarball is not available, a full git clone will be performed |
289 | !clang-layer:${LAYERDIR}/backfill/meta-clang/*/*/*.bb \ | 331 | regardless of whether this variable is set or not. Support for shallow |
290 | " | 332 | clones is not currently implemented as git does not directly support |
333 | shallow cloning a particular git commit hash (it only supports cloning | ||
334 | from a tag or branch reference). | ||
291 | 335 | ||
292 | This next example shows an error message that occurs because invalid | 336 | See also :term:`BB_GIT_SHALLOW_DEPTH` and |
293 | entries are found, which cause parsing to abort: :: | 337 | :term:`BB_GENERATE_SHALLOW_TARBALLS`. |
294 | 338 | ||
295 | ERROR: BBFILES_DYNAMIC entries must be of the form {!}<collection name>:<filename pattern>, not: | 339 | Example usage:: |
296 | /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend | ||
297 | /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend | ||
298 | 340 | ||
299 | :term:`BB_GENERATE_MIRROR_TARBALLS` | 341 | BB_GIT_SHALLOW ?= "1" |
300 | Causes tarballs of the Git repositories, including the Git metadata, | ||
301 | to be placed in the :term:`DL_DIR` directory. Anyone | ||
302 | wishing to create a source mirror would want to enable this variable. | ||
303 | 342 | ||
304 | For performance reasons, creating and placing tarballs of the Git | 343 | # Keep only the top commit |
305 | repositories is not the default action by BitBake. :: | 344 | BB_GIT_SHALLOW_DEPTH ?= "1" |
306 | 345 | ||
307 | BB_GENERATE_MIRROR_TARBALLS = "1" | 346 | # This defaults to enabled if both BB_GIT_SHALLOW and |
347 | # BB_GENERATE_MIRROR_TARBALLS are enabled | ||
348 | BB_GENERATE_SHALLOW_TARBALLS ?= "1" | ||
308 | 349 | ||
309 | :term:`BB_HASHCONFIG_WHITELIST` | 350 | :term:`BB_GIT_SHALLOW_DEPTH` |
310 | Lists variables that are excluded from base configuration checksum, | 351 | When used with :term:`BB_GENERATE_SHALLOW_TARBALLS`, this variable sets |
311 | which is used to determine if the cache can be reused. | 352 | the number of commits to include in generated shallow mirror tarballs. |
353 | With a depth of 1, only the commit referenced in :term:`SRCREV` is | ||
354 | included in the shallow mirror tarball. Increasing the depth includes | ||
355 | additional parent commits, working back through the commit history. | ||
312 | 356 | ||
313 | One of the ways BitBake determines whether to re-parse the main | 357 | If this variable is unset, bitbake will default to a depth of 1 when |
314 | metadata is through checksums of the variables in the datastore of | 358 | generating shallow mirror tarballs. |
315 | the base configuration data. There are variables that you typically | ||
316 | want to exclude when checking whether or not to re-parse and thus | ||
317 | rebuild the cache. As an example, you would usually exclude ``TIME`` | ||
318 | and ``DATE`` because these variables are always changing. If you did | ||
319 | not exclude them, BitBake would never reuse the cache. | ||
320 | 359 | ||
321 | :term:`BB_HASHBASE_WHITELIST` | 360 | For example usage, see :term:`BB_GIT_SHALLOW`. |
322 | Lists variables that are excluded from checksum and dependency data. | 361 | |
323 | Variables that are excluded can therefore change without affecting | 362 | :term:`BB_GLOBAL_PYMODULES` |
324 | the checksum mechanism. A common example would be the variable for | 363 | Specifies the list of Python modules to place in the global namespace. |
325 | the path of the build. BitBake's output should not (and usually does | 364 | It is intended that only the core layer should set this and it is meant |
326 | not) depend on the directory in which it was built. | 365 | to be a very small list, typically just ``os`` and ``sys``. |
366 | :term:`BB_GLOBAL_PYMODULES` is expected to be set before the first | ||
367 | ``addpylib`` directive. | ||
368 | See also ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:extending python library code`". | ||
327 | 369 | ||
328 | :term:`BB_HASHCHECK_FUNCTION` | 370 | :term:`BB_HASHCHECK_FUNCTION` |
329 | Specifies the name of the function to call during the "setscene" part | 371 | Specifies the name of the function to call during the "setscene" part |
@@ -339,12 +381,66 @@ overview of their function and contents. | |||
339 | However, the more accurate the data returned, the more efficient the | 381 | However, the more accurate the data returned, the more efficient the |
340 | build will be. | 382 | build will be. |
341 | 383 | ||
384 | :term:`BB_HASHCONFIG_IGNORE_VARS` | ||
385 | Lists variables that are excluded from base configuration checksum, | ||
386 | which is used to determine if the cache can be reused. | ||
387 | |||
388 | One of the ways BitBake determines whether to re-parse the main | ||
389 | metadata is through checksums of the variables in the datastore of | ||
390 | the base configuration data. There are variables that you typically | ||
391 | want to exclude when checking whether or not to re-parse and thus | ||
392 | rebuild the cache. As an example, you would usually exclude ``TIME`` | ||
393 | and ``DATE`` because these variables are always changing. If you did | ||
394 | not exclude them, BitBake would never reuse the cache. | ||
395 | |||
396 | :term:`BB_HASHSERVE` | ||
397 | Specifies the Hash Equivalence server to use. | ||
398 | |||
399 | If set to ``auto``, BitBake automatically starts its own server | ||
400 | over a UNIX domain socket. An option is to connect this server | ||
401 | to an upstream one, by setting :term:`BB_HASHSERVE_UPSTREAM`. | ||
402 | |||
403 | If set to ``unix://path``, BitBake will connect to an existing | ||
404 | hash server available over a UNIX domain socket. | ||
405 | |||
406 | If set to ``host:port``, BitBake will connect to a remote server on the | ||
407 | specified host. This allows multiple clients to share the same | ||
408 | hash equivalence data. | ||
409 | |||
410 | The remote server can be started manually through | ||
411 | the ``bin/bitbake-hashserv`` script provided by BitBake, | ||
412 | which supports UNIX domain sockets too. This script also allows | ||
413 | to start the server in read-only mode, to avoid accepting | ||
414 | equivalences that correspond to Share State caches that are | ||
415 | only available on specific clients. | ||
416 | |||
417 | :term:`BB_HASHSERVE_UPSTREAM` | ||
418 | Specifies an upstream Hash Equivalence server. | ||
419 | |||
420 | This optional setting is only useful when a local Hash Equivalence | ||
421 | server is started (setting :term:`BB_HASHSERVE` to ``auto``), | ||
422 | and you wish the local server to query an upstream server for | ||
423 | Hash Equivalence data. | ||
424 | |||
425 | Example usage:: | ||
426 | |||
427 | BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687" | ||
428 | |||
342 | :term:`BB_INVALIDCONF` | 429 | :term:`BB_INVALIDCONF` |
343 | Used in combination with the ``ConfigParsed`` event to trigger | 430 | Used in combination with the ``ConfigParsed`` event to trigger |
344 | re-parsing the base metadata (i.e. all the recipes). The | 431 | re-parsing the base metadata (i.e. all the recipes). The |
345 | ``ConfigParsed`` event can set the variable to trigger the re-parse. | 432 | ``ConfigParsed`` event can set the variable to trigger the re-parse. |
346 | You must be careful to avoid recursive loops with this functionality. | 433 | You must be careful to avoid recursive loops with this functionality. |
347 | 434 | ||
435 | :term:`BB_LOADFACTOR_MAX` | ||
436 | Setting this to a value will cause BitBake to check the system load | ||
437 | average before executing new tasks. If the load average is above the | ||
438 | the number of CPUs multipled by this factor, no new task will be started | ||
439 | unless there is no task executing. A value of "1.5" has been found to | ||
440 | work reasonably. This is helpful for systems which don't have pressure | ||
441 | regulation enabled, which is more granular. Pressure values take | ||
442 | precedence over loadfactor. | ||
443 | |||
348 | :term:`BB_LOGCONFIG` | 444 | :term:`BB_LOGCONFIG` |
349 | Specifies the name of a config file that contains the user logging | 445 | Specifies the name of a config file that contains the user logging |
350 | configuration. See | 446 | configuration. See |
@@ -353,15 +449,28 @@ overview of their function and contents. | |||
353 | 449 | ||
354 | :term:`BB_LOGFMT` | 450 | :term:`BB_LOGFMT` |
355 | Specifies the name of the log files saved into | 451 | Specifies the name of the log files saved into |
356 | ``${``\ :term:`T`\ ``}``. By default, the ``BB_LOGFMT`` | 452 | ``${``\ :term:`T`\ ``}``. By default, the :term:`BB_LOGFMT` |
357 | variable is undefined and the log file names get created using the | 453 | variable is undefined and the log filenames get created using the |
358 | following form: :: | 454 | following form:: |
359 | 455 | ||
360 | log.{task}.{pid} | 456 | log.{task}.{pid} |
361 | 457 | ||
362 | If you want to force log files to take a specific name, you can set this | 458 | If you want to force log files to take a specific name, you can set this |
363 | variable in a configuration file. | 459 | variable in a configuration file. |
364 | 460 | ||
461 | :term:`BB_MULTI_PROVIDER_ALLOWED` | ||
462 | Allows you to suppress BitBake warnings caused when building two | ||
463 | separate recipes that provide the same output. | ||
464 | |||
465 | BitBake normally issues a warning when building two different recipes | ||
466 | where each provides the same output. This scenario is usually | ||
467 | something the user does not want. However, cases do exist where it | ||
468 | makes sense, particularly in the ``virtual/*`` namespace. You can use | ||
469 | this variable to suppress BitBake's warnings. | ||
470 | |||
471 | To use the variable, list provider names (e.g. recipe names, | ||
472 | ``virtual/kernel``, and so forth). | ||
473 | |||
365 | :term:`BB_NICE_LEVEL` | 474 | :term:`BB_NICE_LEVEL` |
366 | Allows BitBake to run at a specific priority (i.e. nice level). | 475 | Allows BitBake to run at a specific priority (i.e. nice level). |
367 | System permissions usually mean that BitBake can reduce its priority | 476 | System permissions usually mean that BitBake can reduce its priority |
@@ -377,19 +486,20 @@ overview of their function and contents. | |||
377 | running builds when not connected to the Internet, and when operating | 486 | running builds when not connected to the Internet, and when operating |
378 | in certain kinds of firewall environments. | 487 | in certain kinds of firewall environments. |
379 | 488 | ||
489 | :term:`BB_NUMBER_PARSE_THREADS` | ||
490 | Sets the number of threads BitBake uses when parsing. By default, the | ||
491 | number of threads is equal to the number of cores on the system. | ||
492 | |||
380 | :term:`BB_NUMBER_THREADS` | 493 | :term:`BB_NUMBER_THREADS` |
381 | The maximum number of tasks BitBake should run in parallel at any one | 494 | The maximum number of tasks BitBake should run in parallel at any one |
382 | time. If your host development system supports multiple cores, a good | 495 | time. If your host development system supports multiple cores, a good |
383 | rule of thumb is to set this variable to twice the number of cores. | 496 | rule of thumb is to set this variable to twice the number of cores. |
384 | 497 | ||
385 | :term:`BB_NUMBER_PARSE_THREADS` | ||
386 | Sets the number of threads BitBake uses when parsing. By default, the | ||
387 | number of threads is equal to the number of cores on the system. | ||
388 | |||
389 | :term:`BB_ORIGENV` | 498 | :term:`BB_ORIGENV` |
390 | Contains a copy of the original external environment in which BitBake | 499 | Contains a copy of the original external environment in which BitBake |
391 | was run. The copy is taken before any whitelisted variable values are | 500 | was run. The copy is taken before any variable values configured to |
392 | filtered into BitBake's datastore. | 501 | pass through from the external environment are filtered into BitBake's |
502 | datastore. | ||
393 | 503 | ||
394 | .. note:: | 504 | .. note:: |
395 | 505 | ||
@@ -397,21 +507,72 @@ overview of their function and contents. | |||
397 | queried using the normal datastore operations. | 507 | queried using the normal datastore operations. |
398 | 508 | ||
399 | :term:`BB_PRESERVE_ENV` | 509 | :term:`BB_PRESERVE_ENV` |
400 | Disables whitelisting and instead allows all variables through from | 510 | Disables environment filtering and instead allows all variables through |
401 | the external environment into BitBake's datastore. | 511 | from the external environment into BitBake's datastore. |
402 | 512 | ||
403 | .. note:: | 513 | .. note:: |
404 | 514 | ||
405 | You must set this variable in the external environment in order | 515 | You must set this variable in the external environment in order |
406 | for it to work. | 516 | for it to work. |
407 | 517 | ||
518 | :term:`BB_PRESSURE_MAX_CPU` | ||
519 | Specifies a maximum CPU pressure threshold, above which BitBake's | ||
520 | scheduler will not start new tasks (providing there is at least | ||
521 | one active task). If no value is set, CPU pressure is not | ||
522 | monitored when starting tasks. | ||
523 | |||
524 | The pressure data is calculated based upon what Linux kernels since | ||
525 | version 4.20 expose under ``/proc/pressure``. The threshold represents | ||
526 | the difference in "total" pressure from the previous second. The | ||
527 | minimum value is 1.0 (extremely slow builds) and the maximum is | ||
528 | 1000000 (a pressure value unlikely to ever be reached). | ||
529 | |||
530 | This threshold can be set in ``conf/local.conf`` as:: | ||
531 | |||
532 | BB_PRESSURE_MAX_CPU = "500" | ||
533 | |||
534 | :term:`BB_PRESSURE_MAX_IO` | ||
535 | Specifies a maximum I/O pressure threshold, above which BitBake's | ||
536 | scheduler will not start new tasks (providing there is at least | ||
537 | one active task). If no value is set, I/O pressure is not | ||
538 | monitored when starting tasks. | ||
539 | |||
540 | The pressure data is calculated based upon what Linux kernels since | ||
541 | version 4.20 expose under ``/proc/pressure``. The threshold represents | ||
542 | the difference in "total" pressure from the previous second. The | ||
543 | minimum value is 1.0 (extremely slow builds) and the maximum is | ||
544 | 1000000 (a pressure value unlikely to ever be reached). | ||
545 | |||
546 | At this point in time, experiments show that IO pressure tends to | ||
547 | be short-lived and regulating just the CPU with | ||
548 | :term:`BB_PRESSURE_MAX_CPU` can help to reduce it. | ||
549 | |||
550 | :term:`BB_PRESSURE_MAX_MEMORY` | ||
551 | |||
552 | Specifies a maximum memory pressure threshold, above which BitBake's | ||
553 | scheduler will not start new tasks (providing there is at least | ||
554 | one active task). If no value is set, memory pressure is not | ||
555 | monitored when starting tasks. | ||
556 | |||
557 | The pressure data is calculated based upon what Linux kernels since | ||
558 | version 4.20 expose under ``/proc/pressure``. The threshold represents | ||
559 | the difference in "total" pressure from the previous second. The | ||
560 | minimum value is 1.0 (extremely slow builds) and the maximum is | ||
561 | 1000000 (a pressure value unlikely to ever be reached). | ||
562 | |||
563 | Memory pressure is experienced when time is spent swapping, | ||
564 | refaulting pages from the page cache or performing direct reclaim. | ||
565 | This is why memory pressure is rarely seen, but setting this variable | ||
566 | might be useful as a last resort to prevent OOM errors if they are | ||
567 | occurring during builds. | ||
568 | |||
408 | :term:`BB_RUNFMT` | 569 | :term:`BB_RUNFMT` |
409 | Specifies the name of the executable script files (i.e. run files) | 570 | Specifies the name of the executable script files (i.e. run files) |
410 | saved into ``${``\ :term:`T`\ ``}``. By default, the | 571 | saved into ``${``\ :term:`T`\ ``}``. By default, the |
411 | ``BB_RUNFMT`` variable is undefined and the run file names get | 572 | :term:`BB_RUNFMT` variable is undefined and the run filenames get |
412 | created using the following form: :: | 573 | created using the following form:: |
413 | 574 | ||
414 | run.{task}.{pid} | 575 | run.{func}.{pid} |
415 | 576 | ||
416 | If you want to force run files to take a specific name, you can set this | 577 | If you want to force run files to take a specific name, you can set this |
417 | variable in a configuration file. | 578 | variable in a configuration file. |
@@ -425,14 +586,14 @@ overview of their function and contents. | |||
425 | Selects the name of the scheduler to use for the scheduling of | 586 | Selects the name of the scheduler to use for the scheduling of |
426 | BitBake tasks. Three options exist: | 587 | BitBake tasks. Three options exist: |
427 | 588 | ||
428 | - *basic* - The basic framework from which everything derives. Using | 589 | - *basic* --- the basic framework from which everything derives. Using |
429 | this option causes tasks to be ordered numerically as they are | 590 | this option causes tasks to be ordered numerically as they are |
430 | parsed. | 591 | parsed. |
431 | 592 | ||
432 | - *speed* - Executes tasks first that have more tasks depending on | 593 | - *speed* --- executes tasks first that have more tasks depending on |
433 | them. The "speed" option is the default. | 594 | them. The "speed" option is the default. |
434 | 595 | ||
435 | - *completion* - Causes the scheduler to try to complete a given | 596 | - *completion* --- causes the scheduler to try to complete a given |
436 | recipe once its build has started. | 597 | recipe once its build has started. |
437 | 598 | ||
438 | :term:`BB_SCHEDULERS` | 599 | :term:`BB_SCHEDULERS` |
@@ -452,17 +613,6 @@ overview of their function and contents. | |||
452 | The function specified by this variable returns a "True" or "False" | 613 | The function specified by this variable returns a "True" or "False" |
453 | depending on whether the dependency needs to be met. | 614 | depending on whether the dependency needs to be met. |
454 | 615 | ||
455 | :term:`BB_SETSCENE_VERIFY_FUNCTION2` | ||
456 | Specifies a function to call that verifies the list of planned task | ||
457 | execution before the main task execution happens. The function is | ||
458 | called once BitBake has a list of setscene tasks that have run and | ||
459 | either succeeded or failed. | ||
460 | |||
461 | The function allows for a task list check to see if they make sense. | ||
462 | Even if BitBake was planning to skip a task, the returned value of | ||
463 | the function can force BitBake to run the task, which is necessary | ||
464 | under certain metadata defined circumstances. | ||
465 | |||
466 | :term:`BB_SIGNATURE_EXCLUDE_FLAGS` | 616 | :term:`BB_SIGNATURE_EXCLUDE_FLAGS` |
467 | Lists variable flags (varflags) that can be safely excluded from | 617 | Lists variable flags (varflags) that can be safely excluded from |
468 | checksum and dependency data for keys in the datastore. When | 618 | checksum and dependency data for keys in the datastore. When |
@@ -485,40 +635,17 @@ overview of their function and contents. | |||
485 | :term:`BB_SRCREV_POLICY` | 635 | :term:`BB_SRCREV_POLICY` |
486 | Defines the behavior of the fetcher when it interacts with source | 636 | Defines the behavior of the fetcher when it interacts with source |
487 | control systems and dynamic source revisions. The | 637 | control systems and dynamic source revisions. The |
488 | ``BB_SRCREV_POLICY`` variable is useful when working without a | 638 | :term:`BB_SRCREV_POLICY` variable is useful when working without a |
489 | network. | 639 | network. |
490 | 640 | ||
491 | The variable can be set using one of two policies: | 641 | The variable can be set using one of two policies: |
492 | 642 | ||
493 | - *cache* - Retains the value the system obtained previously rather | 643 | - *cache* --- retains the value the system obtained previously rather |
494 | than querying the source control system each time. | 644 | than querying the source control system each time. |
495 | 645 | ||
496 | - *clear* - Queries the source controls system every time. With this | 646 | - *clear* --- queries the source controls system every time. With this |
497 | policy, there is no cache. The "clear" policy is the default. | 647 | policy, there is no cache. The "clear" policy is the default. |
498 | 648 | ||
499 | :term:`BB_STAMP_POLICY` | ||
500 | Defines the mode used for how timestamps of stamp files are compared. | ||
501 | You can set the variable to one of the following modes: | ||
502 | |||
503 | - *perfile* - Timestamp comparisons are only made between timestamps | ||
504 | of a specific recipe. This is the default mode. | ||
505 | |||
506 | - *full* - Timestamp comparisons are made for all dependencies. | ||
507 | |||
508 | - *whitelist* - Identical to "full" mode except timestamp | ||
509 | comparisons are made for recipes listed in the | ||
510 | :term:`BB_STAMP_WHITELIST` variable. | ||
511 | |||
512 | .. note:: | ||
513 | |||
514 | Stamp policies are largely obsolete with the introduction of | ||
515 | setscene tasks. | ||
516 | |||
517 | :term:`BB_STAMP_WHITELIST` | ||
518 | Lists files whose stamp file timestamps are compared when the stamp | ||
519 | policy mode is set to "whitelist". For information on stamp policies, | ||
520 | see the :term:`BB_STAMP_POLICY` variable. | ||
521 | |||
522 | :term:`BB_STRICT_CHECKSUM` | 649 | :term:`BB_STRICT_CHECKSUM` |
523 | Sets a more strict checksum mechanism for non-local URLs. Setting | 650 | Sets a more strict checksum mechanism for non-local URLs. Setting |
524 | this variable to a value causes BitBake to report an error if it | 651 | this variable to a value causes BitBake to report an error if it |
@@ -529,7 +656,7 @@ overview of their function and contents. | |||
529 | Allows adjustment of a task's Input/Output priority. During | 656 | Allows adjustment of a task's Input/Output priority. During |
530 | Autobuilder testing, random failures can occur for tasks due to I/O | 657 | Autobuilder testing, random failures can occur for tasks due to I/O |
531 | starvation. These failures occur during various QEMU runtime | 658 | starvation. These failures occur during various QEMU runtime |
532 | timeouts. You can use the ``BB_TASK_IONICE_LEVEL`` variable to adjust | 659 | timeouts. You can use the :term:`BB_TASK_IONICE_LEVEL` variable to adjust |
533 | the I/O priority of these tasks. | 660 | the I/O priority of these tasks. |
534 | 661 | ||
535 | .. note:: | 662 | .. note:: |
@@ -537,7 +664,7 @@ overview of their function and contents. | |||
537 | This variable works similarly to the :term:`BB_TASK_NICE_LEVEL` | 664 | This variable works similarly to the :term:`BB_TASK_NICE_LEVEL` |
538 | variable except with a task's I/O priorities. | 665 | variable except with a task's I/O priorities. |
539 | 666 | ||
540 | Set the variable as follows: :: | 667 | Set the variable as follows:: |
541 | 668 | ||
542 | BB_TASK_IONICE_LEVEL = "class.prio" | 669 | BB_TASK_IONICE_LEVEL = "class.prio" |
543 | 670 | ||
@@ -555,7 +682,7 @@ overview of their function and contents. | |||
555 | In order for your I/O priority settings to take effect, you need the | 682 | In order for your I/O priority settings to take effect, you need the |
556 | Completely Fair Queuing (CFQ) Scheduler selected for the backing block | 683 | Completely Fair Queuing (CFQ) Scheduler selected for the backing block |
557 | device. To select the scheduler, use the following command form where | 684 | device. To select the scheduler, use the following command form where |
558 | device is the device (e.g. sda, sdb, and so forth): :: | 685 | device is the device (e.g. sda, sdb, and so forth):: |
559 | 686 | ||
560 | $ sudo sh -c "echo cfq > /sys/block/device/queu/scheduler" | 687 | $ sudo sh -c "echo cfq > /sys/block/device/queu/scheduler" |
561 | 688 | ||
@@ -564,7 +691,7 @@ overview of their function and contents. | |||
564 | 691 | ||
565 | You can use this variable in combination with task overrides to raise | 692 | You can use this variable in combination with task overrides to raise |
566 | or lower priorities of specific tasks. For example, on the `Yocto | 693 | or lower priorities of specific tasks. For example, on the `Yocto |
567 | Project <http://www.yoctoproject.org>`__ autobuilder, QEMU emulation | 694 | Project <https://www.yoctoproject.org>`__ autobuilder, QEMU emulation |
568 | in images is given a higher priority as compared to build tasks to | 695 | in images is given a higher priority as compared to build tasks to |
569 | ensure that images do not suffer timeouts on loaded systems. | 696 | ensure that images do not suffer timeouts on loaded systems. |
570 | 697 | ||
@@ -596,20 +723,20 @@ overview of their function and contents. | |||
596 | To build a different variant of the recipe with a minimal amount of | 723 | To build a different variant of the recipe with a minimal amount of |
597 | code, it usually is as simple as adding the variable to your recipe. | 724 | code, it usually is as simple as adding the variable to your recipe. |
598 | Here are two examples. The "native" variants are from the | 725 | Here are two examples. The "native" variants are from the |
599 | OpenEmbedded-Core metadata: :: | 726 | OpenEmbedded-Core metadata:: |
600 | 727 | ||
601 | BBCLASSEXTEND =+ "native nativesdk" | 728 | BBCLASSEXTEND =+ "native nativesdk" |
602 | BBCLASSEXTEND =+ "multilib:multilib_name" | 729 | BBCLASSEXTEND =+ "multilib:multilib_name" |
603 | 730 | ||
604 | .. note:: | 731 | .. note:: |
605 | 732 | ||
606 | Internally, the ``BBCLASSEXTEND`` mechanism generates recipe | 733 | Internally, the :term:`BBCLASSEXTEND` mechanism generates recipe |
607 | variants by rewriting variable values and applying overrides such | 734 | variants by rewriting variable values and applying overrides such |
608 | as ``_class-native``. For example, to generate a native version of | 735 | as ``_class-native``. For example, to generate a native version of |
609 | a recipe, a :term:`DEPENDS` on "foo" is | 736 | a recipe, a :term:`DEPENDS` on "foo" is |
610 | rewritten to a ``DEPENDS`` on "foo-native". | 737 | rewritten to a :term:`DEPENDS` on "foo-native". |
611 | 738 | ||
612 | Even when using ``BBCLASSEXTEND``, the recipe is only parsed once. | 739 | Even when using :term:`BBCLASSEXTEND`, the recipe is only parsed once. |
613 | Parsing once adds some limitations. For example, it is not | 740 | Parsing once adds some limitations. For example, it is not |
614 | possible to include a different file depending on the variant, | 741 | possible to include a different file depending on the variant, |
615 | since ``include`` statements are processed when the recipe is | 742 | since ``include`` statements are processed when the recipe is |
@@ -642,17 +769,17 @@ overview of their function and contents. | |||
642 | This variable is useful in situations where the same recipe appears | 769 | This variable is useful in situations where the same recipe appears |
643 | in more than one layer. Setting this variable allows you to | 770 | in more than one layer. Setting this variable allows you to |
644 | prioritize a layer against other layers that contain the same recipe | 771 | prioritize a layer against other layers that contain the same recipe |
645 | - effectively letting you control the precedence for the multiple | 772 | --- effectively letting you control the precedence for the multiple |
646 | layers. The precedence established through this variable stands | 773 | layers. The precedence established through this variable stands |
647 | regardless of a recipe's version (:term:`PV` variable). | 774 | regardless of a recipe's version (:term:`PV` variable). |
648 | For example, a layer that has a recipe with a higher ``PV`` value but | 775 | For example, a layer that has a recipe with a higher :term:`PV` value but |
649 | for which the ``BBFILE_PRIORITY`` is set to have a lower precedence | 776 | for which the :term:`BBFILE_PRIORITY` is set to have a lower precedence |
650 | still has a lower precedence. | 777 | still has a lower precedence. |
651 | 778 | ||
652 | A larger value for the ``BBFILE_PRIORITY`` variable results in a | 779 | A larger value for the :term:`BBFILE_PRIORITY` variable results in a |
653 | higher precedence. For example, the value 6 has a higher precedence | 780 | higher precedence. For example, the value 6 has a higher precedence |
654 | than the value 5. If not specified, the ``BBFILE_PRIORITY`` variable | 781 | than the value 5. If not specified, the :term:`BBFILE_PRIORITY` variable |
655 | is set based on layer dependencies (see the ``LAYERDEPENDS`` variable | 782 | is set based on layer dependencies (see the :term:`LAYERDEPENDS` variable |
656 | for more information. The default priority, if unspecified for a | 783 | for more information. The default priority, if unspecified for a |
657 | layer with no dependencies, is the lowest defined priority + 1 (or 1 | 784 | layer with no dependencies, is the lowest defined priority + 1 (or 1 |
658 | if no priorities are defined). | 785 | if no priorities are defined). |
@@ -671,6 +798,45 @@ overview of their function and contents. | |||
671 | For details on the syntax, see the documentation by following the | 798 | For details on the syntax, see the documentation by following the |
672 | previous link. | 799 | previous link. |
673 | 800 | ||
801 | :term:`BBFILES_DYNAMIC` | ||
802 | Activates content depending on presence of identified layers. You | ||
803 | identify the layers by the collections that the layers define. | ||
804 | |||
805 | Use the :term:`BBFILES_DYNAMIC` variable to avoid ``.bbappend`` files whose | ||
806 | corresponding ``.bb`` file is in a layer that attempts to modify other | ||
807 | layers through ``.bbappend`` but does not want to introduce a hard | ||
808 | dependency on those other layers. | ||
809 | |||
810 | Additionally you can prefix the rule with "!" to add ``.bbappend`` and | ||
811 | ``.bb`` files in case a layer is not present. Use this avoid hard | ||
812 | dependency on those other layers. | ||
813 | |||
814 | Use the following form for :term:`BBFILES_DYNAMIC`:: | ||
815 | |||
816 | collection_name:filename_pattern | ||
817 | |||
818 | The following example identifies two collection names and two filename | ||
819 | patterns:: | ||
820 | |||
821 | BBFILES_DYNAMIC += "\ | ||
822 | clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \ | ||
823 | core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \ | ||
824 | " | ||
825 | |||
826 | When the collection name is prefixed with "!" it will add the file pattern in case | ||
827 | the layer is absent:: | ||
828 | |||
829 | BBFILES_DYNAMIC += "\ | ||
830 | !clang-layer:${LAYERDIR}/backfill/meta-clang/*/*/*.bb \ | ||
831 | " | ||
832 | |||
833 | This next example shows an error message that occurs because invalid | ||
834 | entries are found, which cause parsing to fail:: | ||
835 | |||
836 | ERROR: BBFILES_DYNAMIC entries must be of the form {!}<collection name>:<filename pattern>, not: | ||
837 | /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend | ||
838 | /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend | ||
839 | |||
674 | :term:`BBINCLUDED` | 840 | :term:`BBINCLUDED` |
675 | Contains a space-separated list of all of all files that BitBake's | 841 | Contains a space-separated list of all of all files that BitBake's |
676 | parser included during parsing of the current file. | 842 | parser included during parsing of the current file. |
@@ -682,13 +848,13 @@ overview of their function and contents. | |||
682 | :term:`BBINCLUDELOGS_LINES` | 848 | :term:`BBINCLUDELOGS_LINES` |
683 | If :term:`BBINCLUDELOGS` is set, specifies | 849 | If :term:`BBINCLUDELOGS` is set, specifies |
684 | the maximum number of lines from the task log file to print when | 850 | the maximum number of lines from the task log file to print when |
685 | reporting a failed task. If you do not set ``BBINCLUDELOGS_LINES``, | 851 | reporting a failed task. If you do not set :term:`BBINCLUDELOGS_LINES`, |
686 | the entire log is printed. | 852 | the entire log is printed. |
687 | 853 | ||
688 | :term:`BBLAYERS` | 854 | :term:`BBLAYERS` |
689 | Lists the layers to enable during the build. This variable is defined | 855 | Lists the layers to enable during the build. This variable is defined |
690 | in the ``bblayers.conf`` configuration file in the build directory. | 856 | in the ``bblayers.conf`` configuration file in the build directory. |
691 | Here is an example: :: | 857 | Here is an example:: |
692 | 858 | ||
693 | BBLAYERS = " \ | 859 | BBLAYERS = " \ |
694 | /home/scottrif/poky/meta \ | 860 | /home/scottrif/poky/meta \ |
@@ -708,7 +874,7 @@ overview of their function and contents. | |||
708 | :term:`BBMASK` | 874 | :term:`BBMASK` |
709 | Prevents BitBake from processing recipes and recipe append files. | 875 | Prevents BitBake from processing recipes and recipe append files. |
710 | 876 | ||
711 | You can use the ``BBMASK`` variable to "hide" these ``.bb`` and | 877 | You can use the :term:`BBMASK` variable to "hide" these ``.bb`` and |
712 | ``.bbappend`` files. BitBake ignores any recipe or recipe append | 878 | ``.bbappend`` files. BitBake ignores any recipe or recipe append |
713 | files that match any of the expressions. It is as if BitBake does not | 879 | files that match any of the expressions. It is as if BitBake does not |
714 | see them at all. Consequently, matching files are not parsed or | 880 | see them at all. Consequently, matching files are not parsed or |
@@ -722,13 +888,13 @@ overview of their function and contents. | |||
722 | 888 | ||
723 | The following example uses a complete regular expression to tell | 889 | The following example uses a complete regular expression to tell |
724 | BitBake to ignore all recipe and recipe append files in the | 890 | BitBake to ignore all recipe and recipe append files in the |
725 | ``meta-ti/recipes-misc/`` directory: :: | 891 | ``meta-ti/recipes-misc/`` directory:: |
726 | 892 | ||
727 | BBMASK = "meta-ti/recipes-misc/" | 893 | BBMASK = "meta-ti/recipes-misc/" |
728 | 894 | ||
729 | If you want to mask out multiple directories or recipes, you can | 895 | If you want to mask out multiple directories or recipes, you can |
730 | specify multiple regular expression fragments. This next example | 896 | specify multiple regular expression fragments. This next example |
731 | masks out multiple directories and individual recipes: :: | 897 | masks out multiple directories and individual recipes:: |
732 | 898 | ||
733 | BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/" | 899 | BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/" |
734 | BBMASK += "/meta-oe/recipes-support/" | 900 | BBMASK += "/meta-oe/recipes-support/" |
@@ -745,11 +911,11 @@ overview of their function and contents. | |||
745 | Enables BitBake to perform multiple configuration builds and lists | 911 | Enables BitBake to perform multiple configuration builds and lists |
746 | each separate configuration (multiconfig). You can use this variable | 912 | each separate configuration (multiconfig). You can use this variable |
747 | to cause BitBake to build multiple targets where each target has a | 913 | to cause BitBake to build multiple targets where each target has a |
748 | separate configuration. Define ``BBMULTICONFIG`` in your | 914 | separate configuration. Define :term:`BBMULTICONFIG` in your |
749 | ``conf/local.conf`` configuration file. | 915 | ``conf/local.conf`` configuration file. |
750 | 916 | ||
751 | As an example, the following line specifies three multiconfigs, each | 917 | As an example, the following line specifies three multiconfigs, each |
752 | having a separate configuration file: :: | 918 | having a separate configuration file:: |
753 | 919 | ||
754 | BBMULTIFONFIG = "configA configB configC" | 920 | BBMULTIFONFIG = "configA configB configC" |
755 | 921 | ||
@@ -757,20 +923,20 @@ overview of their function and contents. | |||
757 | build directory within a directory named ``conf/multiconfig`` (e.g. | 923 | build directory within a directory named ``conf/multiconfig`` (e.g. |
758 | build_directory\ ``/conf/multiconfig/configA.conf``). | 924 | build_directory\ ``/conf/multiconfig/configA.conf``). |
759 | 925 | ||
760 | For information on how to use ``BBMULTICONFIG`` in an environment | 926 | For information on how to use :term:`BBMULTICONFIG` in an environment |
761 | that supports building targets with multiple configurations, see the | 927 | that supports building targets with multiple configurations, see the |
762 | ":ref:`bitbake-user-manual/bitbake-user-manual-intro:executing a multiple configuration build`" | 928 | ":ref:`bitbake-user-manual/bitbake-user-manual-intro:executing a multiple configuration build`" |
763 | section. | 929 | section. |
764 | 930 | ||
765 | :term:`BBPATH` | 931 | :term:`BBPATH` |
766 | Used by BitBake to locate class (``.bbclass``) and configuration | 932 | A colon-separated list used by BitBake to locate class (``.bbclass``) |
767 | (``.conf``) files. This variable is analogous to the ``PATH`` | 933 | and configuration (``.conf``) files. This variable is analogous to the |
768 | variable. | 934 | ``PATH`` variable. |
769 | 935 | ||
770 | If you run BitBake from a directory outside of the build directory, | 936 | If you run BitBake from a directory outside of the build directory, |
771 | you must be sure to set ``BBPATH`` to point to the build directory. | 937 | you must be sure to set :term:`BBPATH` to point to the build directory. |
772 | Set the variable as you would any environment variable and then run | 938 | Set the variable as you would any environment variable and then run |
773 | BitBake: :: | 939 | BitBake:: |
774 | 940 | ||
775 | $ BBPATH="build_directory" | 941 | $ BBPATH="build_directory" |
776 | $ export BBPATH | 942 | $ export BBPATH |
@@ -784,16 +950,6 @@ overview of their function and contents. | |||
784 | Allows you to use a configuration file to add to the list of | 950 | Allows you to use a configuration file to add to the list of |
785 | command-line target recipes you want to build. | 951 | command-line target recipes you want to build. |
786 | 952 | ||
787 | :term:`BBVERSIONS` | ||
788 | Allows a single recipe to build multiple versions of a project from a | ||
789 | single recipe file. You also able to specify conditional metadata | ||
790 | using the :term:`OVERRIDES` mechanism for a | ||
791 | single version or for an optionally named range of versions. | ||
792 | |||
793 | For more information on ``BBVERSIONS``, see the | ||
794 | ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variants - class extension mechanism`" | ||
795 | section. | ||
796 | |||
797 | :term:`BITBAKE_UI` | 953 | :term:`BITBAKE_UI` |
798 | Used to specify the UI module to use when running BitBake. Using this | 954 | Used to specify the UI module to use when running BitBake. Using this |
799 | variable is equivalent to using the ``-u`` command-line option. | 955 | variable is equivalent to using the ``-u`` command-line option. |
@@ -825,7 +981,7 @@ overview of their function and contents. | |||
825 | The most common usage of this is variable is to set it to "-1" within | 981 | The most common usage of this is variable is to set it to "-1" within |
826 | a recipe for a development version of a piece of software. Using the | 982 | a recipe for a development version of a piece of software. Using the |
827 | variable in this way causes the stable version of the recipe to build | 983 | variable in this way causes the stable version of the recipe to build |
828 | by default in the absence of ``PREFERRED_VERSION`` being used to | 984 | by default in the absence of :term:`PREFERRED_VERSION` being used to |
829 | build the development version. | 985 | build the development version. |
830 | 986 | ||
831 | .. note:: | 987 | .. note:: |
@@ -838,8 +994,8 @@ overview of their function and contents. | |||
838 | Lists a recipe's build-time dependencies (i.e. other recipe files). | 994 | Lists a recipe's build-time dependencies (i.e. other recipe files). |
839 | 995 | ||
840 | Consider this simple example for two recipes named "a" and "b" that | 996 | Consider this simple example for two recipes named "a" and "b" that |
841 | produce similarly named packages. In this example, the ``DEPENDS`` | 997 | produce similarly named packages. In this example, the :term:`DEPENDS` |
842 | statement appears in the "a" recipe: :: | 998 | statement appears in the "a" recipe:: |
843 | 999 | ||
844 | DEPENDS = "b" | 1000 | DEPENDS = "b" |
845 | 1001 | ||
@@ -856,7 +1012,7 @@ overview of their function and contents. | |||
856 | 1012 | ||
857 | :term:`DL_DIR` | 1013 | :term:`DL_DIR` |
858 | The central download directory used by the build process to store | 1014 | The central download directory used by the build process to store |
859 | downloads. By default, ``DL_DIR`` gets files suitable for mirroring for | 1015 | downloads. By default, :term:`DL_DIR` gets files suitable for mirroring for |
860 | everything except Git repositories. If you want tarballs of Git | 1016 | everything except Git repositories. If you want tarballs of Git |
861 | repositories, use the :term:`BB_GENERATE_MIRROR_TARBALLS` variable. | 1017 | repositories, use the :term:`BB_GENERATE_MIRROR_TARBALLS` variable. |
862 | 1018 | ||
@@ -867,18 +1023,18 @@ overview of their function and contents. | |||
867 | ``bblayers.conf`` configuration file. | 1023 | ``bblayers.conf`` configuration file. |
868 | 1024 | ||
869 | To exclude a recipe from a world build using this variable, set the | 1025 | To exclude a recipe from a world build using this variable, set the |
870 | variable to "1" in the recipe. | 1026 | variable to "1" in the recipe. Set it to "0" to add it back to world build. |
871 | 1027 | ||
872 | .. note:: | 1028 | .. note:: |
873 | 1029 | ||
874 | Recipes added to ``EXCLUDE_FROM_WORLD`` may still be built during a world | 1030 | Recipes added to :term:`EXCLUDE_FROM_WORLD` may still be built during a world |
875 | build in order to satisfy dependencies of other recipes. Adding a | 1031 | build in order to satisfy dependencies of other recipes. Adding a |
876 | recipe to ``EXCLUDE_FROM_WORLD`` only ensures that the recipe is not | 1032 | recipe to :term:`EXCLUDE_FROM_WORLD` only ensures that the recipe is not |
877 | explicitly added to the list of build targets in a world build. | 1033 | explicitly added to the list of build targets in a world build. |
878 | 1034 | ||
879 | :term:`FAKEROOT` | 1035 | :term:`FAKEROOT` |
880 | Contains the command to use when running a shell script in a fakeroot | 1036 | Contains the command to use when running a shell script in a fakeroot |
881 | environment. The ``FAKEROOT`` variable is obsolete and has been | 1037 | environment. The :term:`FAKEROOT` variable is obsolete and has been |
882 | replaced by the other ``FAKEROOT*`` variables. See these entries in | 1038 | replaced by the other ``FAKEROOT*`` variables. See these entries in |
883 | the glossary for more information. | 1039 | the glossary for more information. |
884 | 1040 | ||
@@ -925,6 +1081,11 @@ overview of their function and contents. | |||
925 | environment variable. The value is a colon-separated list of | 1081 | environment variable. The value is a colon-separated list of |
926 | directories that are searched left-to-right in order. | 1082 | directories that are searched left-to-right in order. |
927 | 1083 | ||
1084 | :term:`FILE_LAYERNAME` | ||
1085 | During parsing and task execution, this is set to the name of the | ||
1086 | layer containing the recipe file. Code can use this to identify which | ||
1087 | layer a recipe is from. | ||
1088 | |||
928 | :term:`GITDIR` | 1089 | :term:`GITDIR` |
929 | The directory in which a local copy of a Git repository is stored | 1090 | The directory in which a local copy of a Git repository is stored |
930 | when it is cloned. | 1091 | when it is cloned. |
@@ -941,9 +1102,9 @@ overview of their function and contents. | |||
941 | Causes the named class or classes to be inherited globally. Anonymous | 1102 | Causes the named class or classes to be inherited globally. Anonymous |
942 | functions in the class or classes are not executed for the base | 1103 | functions in the class or classes are not executed for the base |
943 | configuration and in each individual recipe. The OpenEmbedded build | 1104 | configuration and in each individual recipe. The OpenEmbedded build |
944 | system ignores changes to ``INHERIT`` in individual recipes. | 1105 | system ignores changes to :term:`INHERIT` in individual recipes. |
945 | 1106 | ||
946 | For more information on ``INHERIT``, see the | 1107 | For more information on :term:`INHERIT`, see the |
947 | ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`" | 1108 | ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`" |
948 | section. | 1109 | section. |
949 | 1110 | ||
@@ -973,6 +1134,29 @@ overview of their function and contents. | |||
973 | variable is not available outside of ``layer.conf`` and references | 1134 | variable is not available outside of ``layer.conf`` and references |
974 | are expanded immediately when parsing of the file completes. | 1135 | are expanded immediately when parsing of the file completes. |
975 | 1136 | ||
1137 | :term:`LAYERSERIES_COMPAT` | ||
1138 | Lists the versions of the OpenEmbedded-Core (OE-Core) for which | ||
1139 | a layer is compatible. Using the :term:`LAYERSERIES_COMPAT` variable | ||
1140 | allows the layer maintainer to indicate which combinations of the | ||
1141 | layer and OE-Core can be expected to work. The variable gives the | ||
1142 | system a way to detect when a layer has not been tested with new | ||
1143 | releases of OE-Core (e.g. the layer is not maintained). | ||
1144 | |||
1145 | To specify the OE-Core versions for which a layer is compatible, use | ||
1146 | this variable in your layer's ``conf/layer.conf`` configuration file. | ||
1147 | For the list, use the Yocto Project release name (e.g. "kirkstone", | ||
1148 | "mickledore"). To specify multiple OE-Core versions for the layer, use | ||
1149 | a space-separated list:: | ||
1150 | |||
1151 | LAYERSERIES_COMPAT_layer_root_name = "kirkstone mickledore" | ||
1152 | |||
1153 | .. note:: | ||
1154 | |||
1155 | Setting :term:`LAYERSERIES_COMPAT` is required by the Yocto Project | ||
1156 | Compatible version 2 standard. | ||
1157 | The OpenEmbedded build system produces a warning if the variable | ||
1158 | is not set for any given layer. | ||
1159 | |||
976 | :term:`LAYERVERSION` | 1160 | :term:`LAYERVERSION` |
977 | Optionally specifies the version of a layer as a single number. You | 1161 | Optionally specifies the version of a layer as a single number. You |
978 | can use this variable within | 1162 | can use this variable within |
@@ -991,29 +1175,16 @@ overview of their function and contents. | |||
991 | the build system searches for source code, it first tries the local | 1175 | the build system searches for source code, it first tries the local |
992 | download directory. If that location fails, the build system tries | 1176 | download directory. If that location fails, the build system tries |
993 | locations defined by :term:`PREMIRRORS`, the | 1177 | locations defined by :term:`PREMIRRORS`, the |
994 | upstream source, and then locations specified by ``MIRRORS`` in that | 1178 | upstream source, and then locations specified by :term:`MIRRORS` in that |
995 | order. | 1179 | order. |
996 | 1180 | ||
997 | :term:`MULTI_PROVIDER_WHITELIST` | ||
998 | Allows you to suppress BitBake warnings caused when building two | ||
999 | separate recipes that provide the same output. | ||
1000 | |||
1001 | BitBake normally issues a warning when building two different recipes | ||
1002 | where each provides the same output. This scenario is usually | ||
1003 | something the user does not want. However, cases do exist where it | ||
1004 | makes sense, particularly in the ``virtual/*`` namespace. You can use | ||
1005 | this variable to suppress BitBake's warnings. | ||
1006 | |||
1007 | To use the variable, list provider names (e.g. recipe names, | ||
1008 | ``virtual/kernel``, and so forth). | ||
1009 | |||
1010 | :term:`OVERRIDES` | 1181 | :term:`OVERRIDES` |
1011 | BitBake uses ``OVERRIDES`` to control what variables are overridden | 1182 | A colon-separated list that BitBake uses to control what variables are |
1012 | after BitBake parses recipes and configuration files. | 1183 | overridden after BitBake parses recipes and configuration files. |
1013 | 1184 | ||
1014 | Following is a simple example that uses an overrides list based on | 1185 | Following is a simple example that uses an overrides list based on |
1015 | machine architectures: OVERRIDES = "arm:x86:mips:powerpc" You can | 1186 | machine architectures: OVERRIDES = "arm:x86:mips:powerpc" You can |
1016 | find information on how to use ``OVERRIDES`` in the | 1187 | find information on how to use :term:`OVERRIDES` in the |
1017 | ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax | 1188 | ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax |
1018 | (overrides)`" section. | 1189 | (overrides)`" section. |
1019 | 1190 | ||
@@ -1027,11 +1198,11 @@ overview of their function and contents. | |||
1027 | :term:`PACKAGES_DYNAMIC` | 1198 | :term:`PACKAGES_DYNAMIC` |
1028 | A promise that your recipe satisfies runtime dependencies for | 1199 | A promise that your recipe satisfies runtime dependencies for |
1029 | optional modules that are found in other recipes. | 1200 | optional modules that are found in other recipes. |
1030 | ``PACKAGES_DYNAMIC`` does not actually satisfy the dependencies, it | 1201 | :term:`PACKAGES_DYNAMIC` does not actually satisfy the dependencies, it |
1031 | only states that they should be satisfied. For example, if a hard, | 1202 | only states that they should be satisfied. For example, if a hard, |
1032 | runtime dependency (:term:`RDEPENDS`) of another | 1203 | runtime dependency (:term:`RDEPENDS`) of another |
1033 | package is satisfied during the build through the | 1204 | package is satisfied during the build through the |
1034 | ``PACKAGES_DYNAMIC`` variable, but a package with the module name is | 1205 | :term:`PACKAGES_DYNAMIC` variable, but a package with the module name is |
1035 | never actually produced, then the other package will be broken. | 1206 | never actually produced, then the other package will be broken. |
1036 | 1207 | ||
1037 | :term:`PE` | 1208 | :term:`PE` |
@@ -1061,7 +1232,7 @@ overview of their function and contents. | |||
1061 | recipes provide the same item. You should always suffix the variable | 1232 | recipes provide the same item. You should always suffix the variable |
1062 | with the name of the provided item, and you should set it to the | 1233 | with the name of the provided item, and you should set it to the |
1063 | :term:`PN` of the recipe to which you want to give | 1234 | :term:`PN` of the recipe to which you want to give |
1064 | precedence. Some examples: :: | 1235 | precedence. Some examples:: |
1065 | 1236 | ||
1066 | PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" | 1237 | PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" |
1067 | PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" | 1238 | PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" |
@@ -1070,30 +1241,30 @@ overview of their function and contents. | |||
1070 | :term:`PREFERRED_PROVIDERS` | 1241 | :term:`PREFERRED_PROVIDERS` |
1071 | Determines which recipe should be given preference for cases where | 1242 | Determines which recipe should be given preference for cases where |
1072 | multiple recipes provide the same item. Functionally, | 1243 | multiple recipes provide the same item. Functionally, |
1073 | ``PREFERRED_PROVIDERS`` is identical to | 1244 | :term:`PREFERRED_PROVIDERS` is identical to |
1074 | :term:`PREFERRED_PROVIDER`. However, the ``PREFERRED_PROVIDERS`` variable | 1245 | :term:`PREFERRED_PROVIDER`. However, the :term:`PREFERRED_PROVIDERS` variable |
1075 | lets you define preferences for multiple situations using the following | 1246 | lets you define preferences for multiple situations using the following |
1076 | form: :: | 1247 | form:: |
1077 | 1248 | ||
1078 | PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..." | 1249 | PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..." |
1079 | 1250 | ||
1080 | This form is a convenient replacement for the following: :: | 1251 | This form is a convenient replacement for the following:: |
1081 | 1252 | ||
1082 | PREFERRED_PROVIDER_xxx = "yyy" | 1253 | PREFERRED_PROVIDER_xxx = "yyy" |
1083 | PREFERRED_PROVIDER_aaa = "bbb" | 1254 | PREFERRED_PROVIDER_aaa = "bbb" |
1084 | 1255 | ||
1085 | :term:`PREFERRED_VERSION` | 1256 | :term:`PREFERRED_VERSION` |
1086 | If there are multiple versions of recipes available, this variable | 1257 | If there are multiple versions of a recipe available, this variable |
1087 | determines which recipe should be given preference. You must always | 1258 | determines which version should be given preference. You must always |
1088 | suffix the variable with the :term:`PN` you want to | 1259 | suffix the variable with the :term:`PN` you want to |
1089 | select, and you should set :term:`PV` accordingly for | 1260 | select, and you should set :term:`PV` accordingly for |
1090 | precedence. | 1261 | precedence. |
1091 | 1262 | ||
1092 | The ``PREFERRED_VERSION`` variable supports limited wildcard use | 1263 | The :term:`PREFERRED_VERSION` variable supports limited wildcard use |
1093 | through the "``%``" character. You can use the character to match any | 1264 | through the "``%``" character. You can use the character to match any |
1094 | number of characters, which can be useful when specifying versions | 1265 | number of characters, which can be useful when specifying versions |
1095 | that contain long revision numbers that potentially change. Here are | 1266 | that contain long revision numbers that potentially change. Here are |
1096 | two examples: :: | 1267 | two examples:: |
1097 | 1268 | ||
1098 | PREFERRED_VERSION_python = "2.7.3" | 1269 | PREFERRED_VERSION_python = "2.7.3" |
1099 | PREFERRED_VERSION_linux-yocto = "4.12%" | 1270 | PREFERRED_VERSION_linux-yocto = "4.12%" |
@@ -1104,22 +1275,26 @@ overview of their function and contents. | |||
1104 | end of the string. You cannot use the wildcard character in any other | 1275 | end of the string. You cannot use the wildcard character in any other |
1105 | location of the string. | 1276 | location of the string. |
1106 | 1277 | ||
1278 | If a recipe with the specified version is not available, a warning | ||
1279 | message will be shown. See :term:`REQUIRED_VERSION` if you want this | ||
1280 | to be an error instead. | ||
1281 | |||
1107 | :term:`PREMIRRORS` | 1282 | :term:`PREMIRRORS` |
1108 | Specifies additional paths from which BitBake gets source code. When | 1283 | Specifies additional paths from which BitBake gets source code. When |
1109 | the build system searches for source code, it first tries the local | 1284 | the build system searches for source code, it first tries the local |
1110 | download directory. If that location fails, the build system tries | 1285 | download directory. If that location fails, the build system tries |
1111 | locations defined by ``PREMIRRORS``, the upstream source, and then | 1286 | locations defined by :term:`PREMIRRORS`, the upstream source, and then |
1112 | locations specified by :term:`MIRRORS` in that order. | 1287 | locations specified by :term:`MIRRORS` in that order. |
1113 | 1288 | ||
1114 | Typically, you would add a specific server for the build system to | 1289 | Typically, you would add a specific server for the build system to |
1115 | attempt before any others by adding something like the following to | 1290 | attempt before any others by adding something like the following to |
1116 | your configuration: :: | 1291 | your configuration:: |
1117 | 1292 | ||
1118 | PREMIRRORS_prepend = "\ | 1293 | PREMIRRORS:prepend = "\ |
1119 | git://.*/.* http://www.yoctoproject.org/sources/ \n \ | 1294 | git://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ |
1120 | ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ | 1295 | ftp://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ |
1121 | http://.*/.* http://www.yoctoproject.org/sources/ \n \ | 1296 | http://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \ |
1122 | https://.*/.* http://www.yoctoproject.org/sources/ \n" | 1297 | https://.*/.* http://downloads.yoctoproject.org/mirror/sources/" |
1123 | 1298 | ||
1124 | These changes cause the build system to intercept Git, FTP, HTTP, and | 1299 | These changes cause the build system to intercept Git, FTP, HTTP, and |
1125 | HTTPS requests and direct them to the ``http://`` sources mirror. You can | 1300 | HTTPS requests and direct them to the ``http://`` sources mirror. You can |
@@ -1128,25 +1303,25 @@ overview of their function and contents. | |||
1128 | 1303 | ||
1129 | :term:`PROVIDES` | 1304 | :term:`PROVIDES` |
1130 | A list of aliases by which a particular recipe can be known. By | 1305 | A list of aliases by which a particular recipe can be known. By |
1131 | default, a recipe's own ``PN`` is implicitly already in its | 1306 | default, a recipe's own :term:`PN` is implicitly already in its |
1132 | ``PROVIDES`` list. If a recipe uses ``PROVIDES``, the additional | 1307 | :term:`PROVIDES` list. If a recipe uses :term:`PROVIDES`, the additional |
1133 | aliases are synonyms for the recipe and can be useful satisfying | 1308 | aliases are synonyms for the recipe and can be useful satisfying |
1134 | dependencies of other recipes during the build as specified by | 1309 | dependencies of other recipes during the build as specified by |
1135 | ``DEPENDS``. | 1310 | :term:`DEPENDS`. |
1136 | 1311 | ||
1137 | Consider the following example ``PROVIDES`` statement from a recipe | 1312 | Consider the following example :term:`PROVIDES` statement from a recipe |
1138 | file ``libav_0.8.11.bb``: :: | 1313 | file ``libav_0.8.11.bb``:: |
1139 | 1314 | ||
1140 | PROVIDES += "libpostproc" | 1315 | PROVIDES += "libpostproc" |
1141 | 1316 | ||
1142 | The ``PROVIDES`` statement results in the "libav" recipe also being known | 1317 | The :term:`PROVIDES` statement results in the "libav" recipe also being known |
1143 | as "libpostproc". | 1318 | as "libpostproc". |
1144 | 1319 | ||
1145 | In addition to providing recipes under alternate names, the | 1320 | In addition to providing recipes under alternate names, the |
1146 | ``PROVIDES`` mechanism is also used to implement virtual targets. A | 1321 | :term:`PROVIDES` mechanism is also used to implement virtual targets. A |
1147 | virtual target is a name that corresponds to some particular | 1322 | virtual target is a name that corresponds to some particular |
1148 | functionality (e.g. a Linux kernel). Recipes that provide the | 1323 | functionality (e.g. a Linux kernel). Recipes that provide the |
1149 | functionality in question list the virtual target in ``PROVIDES``. | 1324 | functionality in question list the virtual target in :term:`PROVIDES`. |
1150 | Recipes that depend on the functionality in question can include the | 1325 | Recipes that depend on the functionality in question can include the |
1151 | virtual target in :term:`DEPENDS` to leave the | 1326 | virtual target in :term:`DEPENDS` to leave the |
1152 | choice of provider open. | 1327 | choice of provider open. |
@@ -1158,12 +1333,12 @@ overview of their function and contents. | |||
1158 | :term:`PRSERV_HOST` | 1333 | :term:`PRSERV_HOST` |
1159 | The network based :term:`PR` service host and port. | 1334 | The network based :term:`PR` service host and port. |
1160 | 1335 | ||
1161 | Following is an example of how the ``PRSERV_HOST`` variable is set: :: | 1336 | Following is an example of how the :term:`PRSERV_HOST` variable is set:: |
1162 | 1337 | ||
1163 | PRSERV_HOST = "localhost:0" | 1338 | PRSERV_HOST = "localhost:0" |
1164 | 1339 | ||
1165 | You must set the variable if you want to automatically start a local PR | 1340 | You must set the variable if you want to automatically start a local PR |
1166 | service. You can set ``PRSERV_HOST`` to other values to use a remote PR | 1341 | service. You can set :term:`PRSERV_HOST` to other values to use a remote PR |
1167 | service. | 1342 | service. |
1168 | 1343 | ||
1169 | :term:`PV` | 1344 | :term:`PV` |
@@ -1175,26 +1350,26 @@ overview of their function and contents. | |||
1175 | a package in this list cannot be found during the build, you will get | 1350 | a package in this list cannot be found during the build, you will get |
1176 | a build error. | 1351 | a build error. |
1177 | 1352 | ||
1178 | Because the ``RDEPENDS`` variable applies to packages being built, | 1353 | Because the :term:`RDEPENDS` variable applies to packages being built, |
1179 | you should always use the variable in a form with an attached package | 1354 | you should always use the variable in a form with an attached package |
1180 | name. For example, suppose you are building a development package | 1355 | name. For example, suppose you are building a development package |
1181 | that depends on the ``perl`` package. In this case, you would use the | 1356 | that depends on the ``perl`` package. In this case, you would use the |
1182 | following ``RDEPENDS`` statement: :: | 1357 | following :term:`RDEPENDS` statement:: |
1183 | 1358 | ||
1184 | RDEPENDS_${PN}-dev += "perl" | 1359 | RDEPENDS:${PN}-dev += "perl" |
1185 | 1360 | ||
1186 | In the example, the development package depends on the ``perl`` package. | 1361 | In the example, the development package depends on the ``perl`` package. |
1187 | Thus, the ``RDEPENDS`` variable has the ``${PN}-dev`` package name as part | 1362 | Thus, the :term:`RDEPENDS` variable has the ``${PN}-dev`` package name as part |
1188 | of the variable. | 1363 | of the variable. |
1189 | 1364 | ||
1190 | BitBake supports specifying versioned dependencies. Although the | 1365 | BitBake supports specifying versioned dependencies. Although the |
1191 | syntax varies depending on the packaging format, BitBake hides these | 1366 | syntax varies depending on the packaging format, BitBake hides these |
1192 | differences from you. Here is the general syntax to specify versions | 1367 | differences from you. Here is the general syntax to specify versions |
1193 | with the ``RDEPENDS`` variable: :: | 1368 | with the :term:`RDEPENDS` variable:: |
1194 | 1369 | ||
1195 | RDEPENDS_${PN} = "package (operator version)" | 1370 | RDEPENDS:${PN} = "package (operator version)" |
1196 | 1371 | ||
1197 | For ``operator``, you can specify the following: :: | 1372 | For ``operator``, you can specify the following:: |
1198 | 1373 | ||
1199 | = | 1374 | = |
1200 | < | 1375 | < |
@@ -1203,9 +1378,9 @@ overview of their function and contents. | |||
1203 | >= | 1378 | >= |
1204 | 1379 | ||
1205 | For example, the following sets up a dependency on version 1.2 or | 1380 | For example, the following sets up a dependency on version 1.2 or |
1206 | greater of the package ``foo``: :: | 1381 | greater of the package ``foo``:: |
1207 | 1382 | ||
1208 | RDEPENDS_${PN} = "foo (>= 1.2)" | 1383 | RDEPENDS:${PN} = "foo (>= 1.2)" |
1209 | 1384 | ||
1210 | For information on build-time dependencies, see the :term:`DEPENDS` | 1385 | For information on build-time dependencies, see the :term:`DEPENDS` |
1211 | variable. | 1386 | variable. |
@@ -1214,33 +1389,43 @@ overview of their function and contents. | |||
1214 | The directory in which a local copy of a ``google-repo`` directory is | 1389 | The directory in which a local copy of a ``google-repo`` directory is |
1215 | stored when it is synced. | 1390 | stored when it is synced. |
1216 | 1391 | ||
1392 | :term:`REQUIRED_VERSION` | ||
1393 | If there are multiple versions of a recipe available, this variable | ||
1394 | determines which version should be given preference. :term:`REQUIRED_VERSION` | ||
1395 | works in exactly the same manner as :term:`PREFERRED_VERSION`, except | ||
1396 | that if the specified version is not available then an error message | ||
1397 | is shown and the build fails immediately. | ||
1398 | |||
1399 | If both :term:`REQUIRED_VERSION` and :term:`PREFERRED_VERSION` are set for | ||
1400 | the same recipe, the :term:`REQUIRED_VERSION` value applies. | ||
1401 | |||
1217 | :term:`RPROVIDES` | 1402 | :term:`RPROVIDES` |
1218 | A list of package name aliases that a package also provides. These | 1403 | A list of package name aliases that a package also provides. These |
1219 | aliases are useful for satisfying runtime dependencies of other | 1404 | aliases are useful for satisfying runtime dependencies of other |
1220 | packages both during the build and on the target (as specified by | 1405 | packages both during the build and on the target (as specified by |
1221 | ``RDEPENDS``). | 1406 | :term:`RDEPENDS`). |
1222 | 1407 | ||
1223 | As with all package-controlling variables, you must always use the | 1408 | As with all package-controlling variables, you must always use the |
1224 | variable in conjunction with a package name override. Here is an | 1409 | variable in conjunction with a package name override. Here is an |
1225 | example: :: | 1410 | example:: |
1226 | 1411 | ||
1227 | RPROVIDES_${PN} = "widget-abi-2" | 1412 | RPROVIDES:${PN} = "widget-abi-2" |
1228 | 1413 | ||
1229 | :term:`RRECOMMENDS` | 1414 | :term:`RRECOMMENDS` |
1230 | A list of packages that extends the usability of a package being | 1415 | A list of packages that extends the usability of a package being |
1231 | built. The package being built does not depend on this list of | 1416 | built. The package being built does not depend on this list of |
1232 | packages in order to successfully build, but needs them for the | 1417 | packages in order to successfully build, but needs them for the |
1233 | extended usability. To specify runtime dependencies for packages, see | 1418 | extended usability. To specify runtime dependencies for packages, see |
1234 | the ``RDEPENDS`` variable. | 1419 | the :term:`RDEPENDS` variable. |
1235 | 1420 | ||
1236 | BitBake supports specifying versioned recommends. Although the syntax | 1421 | BitBake supports specifying versioned recommends. Although the syntax |
1237 | varies depending on the packaging format, BitBake hides these | 1422 | varies depending on the packaging format, BitBake hides these |
1238 | differences from you. Here is the general syntax to specify versions | 1423 | differences from you. Here is the general syntax to specify versions |
1239 | with the ``RRECOMMENDS`` variable: :: | 1424 | with the :term:`RRECOMMENDS` variable:: |
1240 | 1425 | ||
1241 | RRECOMMENDS_${PN} = "package (operator version)" | 1426 | RRECOMMENDS:${PN} = "package (operator version)" |
1242 | 1427 | ||
1243 | For ``operator``, you can specify the following: :: | 1428 | For ``operator``, you can specify the following:: |
1244 | 1429 | ||
1245 | = | 1430 | = |
1246 | < | 1431 | < |
@@ -1249,76 +1434,114 @@ overview of their function and contents. | |||
1249 | >= | 1434 | >= |
1250 | 1435 | ||
1251 | For example, the following sets up a recommend on version | 1436 | For example, the following sets up a recommend on version |
1252 | 1.2 or greater of the package ``foo``: :: | 1437 | 1.2 or greater of the package ``foo``:: |
1253 | 1438 | ||
1254 | RRECOMMENDS_${PN} = "foo (>= 1.2)" | 1439 | RRECOMMENDS:${PN} = "foo (>= 1.2)" |
1255 | 1440 | ||
1256 | :term:`SECTION` | 1441 | :term:`SECTION` |
1257 | The section in which packages should be categorized. | 1442 | The section in which packages should be categorized. |
1258 | 1443 | ||
1259 | :term:`SRC_URI` | 1444 | :term:`SRC_URI` |
1260 | The list of source files - local or remote. This variable tells | 1445 | The list of source files --- local or remote. This variable tells |
1261 | BitBake which bits to pull for the build and how to pull them. For | 1446 | BitBake which bits to pull for the build and how to pull them. For |
1262 | example, if the recipe or append file needs to fetch a single tarball | 1447 | example, if the recipe or append file needs to fetch a single tarball |
1263 | from the Internet, the recipe or append file uses a ``SRC_URI`` entry | 1448 | from the Internet, the recipe or append file uses a :term:`SRC_URI` |
1264 | that specifies that tarball. On the other hand, if the recipe or | 1449 | entry that specifies that tarball. On the other hand, if the recipe or |
1265 | append file needs to fetch a tarball and include a custom file, the | 1450 | append file needs to fetch a tarball, apply two patches, and include |
1266 | recipe or append file needs an ``SRC_URI`` variable that specifies | 1451 | a custom file, the recipe or append file needs an :term:`SRC_URI` |
1267 | all those sources. | 1452 | variable that specifies all those sources. |
1268 | 1453 | ||
1269 | The following list explains the available URI protocols: | 1454 | The following list explains the available URI protocols. URI |
1455 | protocols are highly dependent on particular BitBake Fetcher | ||
1456 | submodules. Depending on the fetcher BitBake uses, various URL | ||
1457 | parameters are employed. For specifics on the supported Fetchers, see | ||
1458 | the :ref:`bitbake-user-manual/bitbake-user-manual-fetching:fetchers` | ||
1459 | section. | ||
1270 | 1460 | ||
1271 | - ``file://`` : Fetches files, which are usually files shipped | 1461 | - ``az://``: Fetches files from an Azure Storage account using HTTPS. |
1272 | with the metadata, from the local machine. The path is relative to | ||
1273 | the :term:`FILESPATH` variable. | ||
1274 | 1462 | ||
1275 | - ``bzr://`` : Fetches files from a Bazaar revision control | 1463 | - ``bzr://``: Fetches files from a Bazaar revision control |
1276 | repository. | 1464 | repository. |
1277 | 1465 | ||
1278 | - ``git://`` : Fetches files from a Git revision control | 1466 | - ``ccrc://``: Fetches files from a ClearCase repository. |
1467 | |||
1468 | - ``cvs://``: Fetches files from a CVS revision control | ||
1279 | repository. | 1469 | repository. |
1280 | 1470 | ||
1281 | - ``osc://`` : Fetches files from an OSC (OpenSUSE Build service) | 1471 | - ``file://``: Fetches files, which are usually files shipped |
1282 | revision control repository. | 1472 | with the Metadata, from the local machine. |
1473 | The path is relative to the :term:`FILESPATH` | ||
1474 | variable. Thus, the build system searches, in order, from the | ||
1475 | following directories, which are assumed to be a subdirectories of | ||
1476 | the directory in which the recipe file (``.bb``) or append file | ||
1477 | (``.bbappend``) resides: | ||
1283 | 1478 | ||
1284 | - ``repo://`` : Fetches files from a repo (Git) repository. | 1479 | - ``${BPN}``: the base recipe name without any special suffix |
1480 | or version numbers. | ||
1285 | 1481 | ||
1286 | - ``http://`` : Fetches files from the Internet using HTTP. | 1482 | - ``${BP}`` - ``${BPN}-${PV}``: the base recipe name and |
1483 | version but without any special package name suffix. | ||
1287 | 1484 | ||
1288 | - ``https://`` : Fetches files from the Internet using HTTPS. | 1485 | - ``files``: files within a directory, which is named ``files`` |
1486 | and is also alongside the recipe or append file. | ||
1289 | 1487 | ||
1290 | - ``ftp://`` : Fetches files from the Internet using FTP. | 1488 | - ``ftp://``: Fetches files from the Internet using FTP. |
1291 | 1489 | ||
1292 | - ``cvs://`` : Fetches files from a CVS revision control | 1490 | - ``git://``: Fetches files from a Git revision control |
1293 | repository. | 1491 | repository. |
1294 | 1492 | ||
1295 | - ``hg://`` : Fetches files from a Mercurial (``hg``) revision | 1493 | - ``gitsm://``: Fetches submodules from a Git revision control |
1494 | repository. | ||
1495 | |||
1496 | - ``hg://``: Fetches files from a Mercurial (``hg``) revision | ||
1296 | control repository. | 1497 | control repository. |
1297 | 1498 | ||
1298 | - ``p4://`` : Fetches files from a Perforce (``p4``) revision | 1499 | - ``http://``: Fetches files from the Internet using HTTP. |
1500 | |||
1501 | - ``https://``: Fetches files from the Internet using HTTPS. | ||
1502 | |||
1503 | - ``npm://``: Fetches JavaScript modules from a registry. | ||
1504 | |||
1505 | - ``osc://``: Fetches files from an OSC (OpenSUSE Build service) | ||
1506 | revision control repository. | ||
1507 | |||
1508 | - ``p4://``: Fetches files from a Perforce (``p4``) revision | ||
1299 | control repository. | 1509 | control repository. |
1300 | 1510 | ||
1301 | - ``ssh://`` : Fetches files from a secure shell. | 1511 | - ``repo://``: Fetches files from a repo (Git) repository. |
1512 | |||
1513 | - ``ssh://``: Fetches files from a secure shell. | ||
1302 | 1514 | ||
1303 | - ``svn://`` : Fetches files from a Subversion (``svn``) revision | 1515 | - ``svn://``: Fetches files from a Subversion (``svn``) revision |
1304 | control repository. | 1516 | control repository. |
1305 | 1517 | ||
1306 | Here are some additional options worth mentioning: | 1518 | Here are some additional options worth mentioning: |
1307 | 1519 | ||
1308 | - ``unpack`` : Controls whether or not to unpack the file if it is | 1520 | - ``downloadfilename``: Specifies the filename used when storing |
1309 | an archive. The default action is to unpack the file. | 1521 | the downloaded file. |
1522 | |||
1523 | - ``name``: Specifies a name to be used for association with | ||
1524 | :term:`SRC_URI` checksums or :term:`SRCREV` when you have more than one | ||
1525 | file or git repository specified in :term:`SRC_URI`. For example:: | ||
1526 | |||
1527 | SRC_URI = "git://example.com/foo.git;branch=main;name=first \ | ||
1528 | git://example.com/bar.git;branch=main;name=second \ | ||
1529 | http://example.com/file.tar.gz;name=third" | ||
1310 | 1530 | ||
1311 | - ``subdir`` : Places the file (or extracts its contents) into the | 1531 | SRCREV_first = "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15" |
1532 | SRCREV_second = "e242ed3bffccdf271b7fbaf34ed72d089537b42f" | ||
1533 | SRC_URI[third.sha256sum] = "13550350a8681c84c861aac2e5b440161c2b33a3e4f302ac680ca5b686de48de" | ||
1534 | |||
1535 | - ``subdir``: Places the file (or extracts its contents) into the | ||
1312 | specified subdirectory. This option is useful for unusual tarballs | 1536 | specified subdirectory. This option is useful for unusual tarballs |
1313 | or other archives that do not have their files already in a | 1537 | or other archives that do not have their files already in a |
1314 | subdirectory within the archive. | 1538 | subdirectory within the archive. |
1315 | 1539 | ||
1316 | - ``name`` : Specifies a name to be used for association with | 1540 | - ``subpath``: Limits the checkout to a specific subpath of the |
1317 | ``SRC_URI`` checksums when you have more than one file specified | 1541 | tree when using the Git fetcher is used. |
1318 | in ``SRC_URI``. | ||
1319 | 1542 | ||
1320 | - ``downloadfilename`` : Specifies the filename used when storing | 1543 | - ``unpack``: Controls whether or not to unpack the file if it is |
1321 | the downloaded file. | 1544 | an archive. The default action is to unpack the file. |
1322 | 1545 | ||
1323 | :term:`SRCDATE` | 1546 | :term:`SRCDATE` |
1324 | The date of the source code used to build the package. This variable | 1547 | The date of the source code used to build the package. This variable |
@@ -1330,7 +1553,7 @@ overview of their function and contents. | |||
1330 | variable applies only when using Subversion, Git, Mercurial and | 1553 | variable applies only when using Subversion, Git, Mercurial and |
1331 | Bazaar. If you want to build a fixed revision and you want to avoid | 1554 | Bazaar. If you want to build a fixed revision and you want to avoid |
1332 | performing a query on the remote repository every time BitBake parses | 1555 | performing a query on the remote repository every time BitBake parses |
1333 | your recipe, you should specify a ``SRCREV`` that is a full revision | 1556 | your recipe, you should specify a :term:`SRCREV` that is a full revision |
1334 | identifier and not just a tag. | 1557 | identifier and not just a tag. |
1335 | 1558 | ||
1336 | :term:`SRCREV_FORMAT` | 1559 | :term:`SRCREV_FORMAT` |
@@ -1339,10 +1562,10 @@ overview of their function and contents. | |||
1339 | :term:`SRC_URI`. | 1562 | :term:`SRC_URI`. |
1340 | 1563 | ||
1341 | The system needs help constructing these values under these | 1564 | The system needs help constructing these values under these |
1342 | circumstances. Each component in the ``SRC_URI`` is assigned a name | 1565 | circumstances. Each component in the :term:`SRC_URI` is assigned a name |
1343 | and these are referenced in the ``SRCREV_FORMAT`` variable. Consider | 1566 | and these are referenced in the :term:`SRCREV_FORMAT` variable. Consider |
1344 | an example with URLs named "machine" and "meta". In this case, | 1567 | an example with URLs named "machine" and "meta". In this case, |
1345 | ``SRCREV_FORMAT`` could look like "machine_meta" and those names | 1568 | :term:`SRCREV_FORMAT` could look like "machine_meta" and those names |
1346 | would have the SCM versions substituted into each position. Only one | 1569 | would have the SCM versions substituted into each position. Only one |
1347 | ``AUTOINC`` placeholder is added and if needed. And, this placeholder | 1570 | ``AUTOINC`` placeholder is added and if needed. And, this placeholder |
1348 | is placed at the start of the returned string. | 1571 | is placed at the start of the returned string. |
@@ -1354,7 +1577,7 @@ overview of their function and contents. | |||
1354 | 1577 | ||
1355 | :term:`STAMPCLEAN` | 1578 | :term:`STAMPCLEAN` |
1356 | Specifies the base path used to create recipe stamp files. Unlike the | 1579 | Specifies the base path used to create recipe stamp files. Unlike the |
1357 | :term:`STAMP` variable, ``STAMPCLEAN`` can contain | 1580 | :term:`STAMP` variable, :term:`STAMPCLEAN` can contain |
1358 | wildcards to match the range of files a clean operation should | 1581 | wildcards to match the range of files a clean operation should |
1359 | remove. BitBake uses a clean operation to remove any other stamps it | 1582 | remove. BitBake uses a clean operation to remove any other stamps it |
1360 | should be removing when creating a new stamp. | 1583 | should be removing when creating a new stamp. |