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 | 129 |
1 files changed, 120 insertions, 9 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 12aef3cbb7..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 @@ -40,8 +40,7 @@ overview of their function and contents. Azure Storage Shared Access Signature, when using the :ref:`Azure Storage fetcher <bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` This variable can be defined to be used by the fetcher to authenticate - and gain access to non-public artifacts. - :: + and gain access to non-public artifacts:: AZ_SAS = ""se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>"" @@ -100,10 +99,26 @@ overview of their function and contents. the path of the build. BitBake's output should not (and usually does not) depend on the directory in which it was built. + :term:`BB_CACHEDIR` + Specifies the code parser cache directory (distinct from :term:`CACHE` + and :term:`PERSISTENT_DIR` although they can be set to the same value + if desired). The default value is "${TOPDIR}/cache". + :term:`BB_CHECK_SSL_CERTS` Specifies if SSL certificates should be checked when fetching. The default value is ``1`` and certificates are not checked if the value is set to ``0``. + :term:`BB_HASH_CODEPARSER_VALS` + Specifies values for variables to use when populating the codeparser cache. + This can be used selectively to set dummy values for variables to avoid + the codeparser cache growing on every parse. Variables that would typically + be included are those where the value is not significant for where the + codeparser cache is used (i.e. when calculating variable dependencies for + code fragments.) The value is space-separated without quoting values, for + example:: + + BB_HASH_CODEPARSER_VALS = "T=/ WORKDIR=/ DATE=1234 TIME=1234" + :term:`BB_CONSOLELOG` Specifies the path to a log file into which BitBake's user interface writes output during the build. @@ -344,6 +359,14 @@ overview of their function and contents. For example usage, see :term:`BB_GIT_SHALLOW`. + :term:`BB_GLOBAL_PYMODULES` + Specifies the list of Python modules to place in the global namespace. + It is intended that only the core layer should set this and it is meant + to be a very small list, typically just ``os`` and ``sys``. + :term:`BB_GLOBAL_PYMODULES` is expected to be set before the first + ``addpylib`` directive. + See also ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:extending python library code`". + :term:`BB_HASHCHECK_FUNCTION` Specifies the name of the function to call during the "setscene" part of the task's execution in order to validate the list of task hashes. @@ -409,6 +432,15 @@ overview of their function and contents. ``ConfigParsed`` event can set the variable to trigger the re-parse. You must be careful to avoid recursive loops with this functionality. + :term:`BB_LOADFACTOR_MAX` + Setting this to a value will cause BitBake to check the system load + average before executing new tasks. If the load average is above the + the number of CPUs multipled by this factor, no new task will be started + unless there is no task executing. A value of "1.5" has been found to + work reasonably. This is helpful for systems which don't have pressure + regulation enabled, which is more granular. Pressure values take + precedence over loadfactor. + :term:`BB_LOGCONFIG` Specifies the name of a config file that contains the user logging configuration. See @@ -483,13 +515,64 @@ overview of their function and contents. You must set this variable in the external environment in order for it to work. + :term:`BB_PRESSURE_MAX_CPU` + Specifies a maximum CPU pressure threshold, above which BitBake's + scheduler will not start new tasks (providing there is at least + one active task). If no value is set, CPU pressure is not + monitored when starting tasks. + + The pressure data is calculated based upon what Linux kernels since + version 4.20 expose under ``/proc/pressure``. The threshold represents + the difference in "total" pressure from the previous second. The + minimum value is 1.0 (extremely slow builds) and the maximum is + 1000000 (a pressure value unlikely to ever be reached). + + This threshold can be set in ``conf/local.conf`` as:: + + BB_PRESSURE_MAX_CPU = "500" + + :term:`BB_PRESSURE_MAX_IO` + Specifies a maximum I/O pressure threshold, above which BitBake's + scheduler will not start new tasks (providing there is at least + one active task). If no value is set, I/O pressure is not + monitored when starting tasks. + + The pressure data is calculated based upon what Linux kernels since + version 4.20 expose under ``/proc/pressure``. The threshold represents + the difference in "total" pressure from the previous second. The + minimum value is 1.0 (extremely slow builds) and the maximum is + 1000000 (a pressure value unlikely to ever be reached). + + At this point in time, experiments show that IO pressure tends to + be short-lived and regulating just the CPU with + :term:`BB_PRESSURE_MAX_CPU` can help to reduce it. + + :term:`BB_PRESSURE_MAX_MEMORY` + + Specifies a maximum memory pressure threshold, above which BitBake's + scheduler will not start new tasks (providing there is at least + one active task). If no value is set, memory pressure is not + monitored when starting tasks. + + The pressure data is calculated based upon what Linux kernels since + version 4.20 expose under ``/proc/pressure``. The threshold represents + the difference in "total" pressure from the previous second. The + minimum value is 1.0 (extremely slow builds) and the maximum is + 1000000 (a pressure value unlikely to ever be reached). + + Memory pressure is experienced when time is spent swapping, + refaulting pages from the page cache or performing direct reclaim. + This is why memory pressure is rarely seen, but setting this variable + might be useful as a last resort to prevent OOM errors if they are + occurring during builds. + :term:`BB_RUNFMT` Specifies the name of the executable script files (i.e. run files) saved into ``${``\ :term:`T`\ ``}``. By default, the :term:`BB_RUNFMT` variable is undefined and the run filenames get created using the following form:: - run.{task}.{pid} + run.{func}.{pid} If you want to force run files to take a specific name, you can set this variable in a configuration file. @@ -846,9 +929,9 @@ overview of their function and contents. section. :term:`BBPATH` - Used by BitBake to locate class (``.bbclass``) and configuration - (``.conf``) files. This variable is analogous to the ``PATH`` - variable. + A colon-separated list used by BitBake to locate class (``.bbclass``) + and configuration (``.conf``) files. This variable is analogous to the + ``PATH`` variable. If you run BitBake from a directory outside of the build directory, you must be sure to set :term:`BBPATH` to point to the build directory. @@ -940,7 +1023,7 @@ overview of their function and contents. ``bblayers.conf`` configuration file. To exclude a recipe from a world build using this variable, set the - variable to "1" in the recipe. + variable to "1" in the recipe. Set it to "0" to add it back to world build. .. note:: @@ -998,6 +1081,11 @@ overview of their function and contents. environment variable. The value is a colon-separated list of directories that are searched left-to-right in order. + :term:`FILE_LAYERNAME` + During parsing and task execution, this is set to the name of the + layer containing the recipe file. Code can use this to identify which + layer a recipe is from. + :term:`GITDIR` The directory in which a local copy of a Git repository is stored when it is cloned. @@ -1046,6 +1134,29 @@ overview of their function and contents. variable is not available outside of ``layer.conf`` and references are expanded immediately when parsing of the file completes. + :term:`LAYERSERIES_COMPAT` + Lists the versions of the OpenEmbedded-Core (OE-Core) for which + a layer is compatible. Using the :term:`LAYERSERIES_COMPAT` variable + allows the layer maintainer to indicate which combinations of the + layer and OE-Core can be expected to work. The variable gives the + system a way to detect when a layer has not been tested with new + releases of OE-Core (e.g. the layer is not maintained). + + To specify the OE-Core versions for which a layer is compatible, use + this variable in your layer's ``conf/layer.conf`` configuration file. + For the list, use the Yocto Project release name (e.g. "kirkstone", + "mickledore"). To specify multiple OE-Core versions for the layer, use + a space-separated list:: + + LAYERSERIES_COMPAT_layer_root_name = "kirkstone mickledore" + + .. note:: + + Setting :term:`LAYERSERIES_COMPAT` is required by the Yocto Project + Compatible version 2 standard. + The OpenEmbedded build system produces a warning if the variable + is not set for any given layer. + :term:`LAYERVERSION` Optionally specifies the version of a layer as a single number. You can use this variable within @@ -1068,8 +1179,8 @@ overview of their function and contents. order. :term:`OVERRIDES` - BitBake uses :term:`OVERRIDES` to control what variables are overridden - after BitBake parses recipes and configuration files. + A colon-separated list that BitBake uses to control what variables are + overridden after BitBake parses recipes and configuration files. Following is a simple example that uses an overrides list based on machine architectures: OVERRIDES = "arm:x86:mips:powerpc" You can |