diff options
Diffstat (limited to 'external/poky/bitbake/doc/bitbake-user-manual')
6 files changed, 589 insertions, 400 deletions
diff --git a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml index f1caaecd..e4251dff 100644 --- a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml +++ b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml @@ -31,7 +31,7 @@ <para> Prior to executing BitBake, you should take advantage of available parallel thread execution on your build host by setting the - <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> + <link linkend='var-bb-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> variable in your project's <filename>local.conf</filename> configuration file. </para> @@ -87,9 +87,9 @@ <para> The <filename>layer.conf</filename> files are used to construct key variables such as - <link linkend='var-BBPATH'><filename>BBPATH</filename></link> + <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link> and - <link linkend='var-BBFILES'><filename>BBFILES</filename></link>. + <link linkend='var-bb-BBFILES'><filename>BBFILES</filename></link>. <filename>BBPATH</filename> is used to search for configuration and class files under the <filename>conf</filename> and <filename>classes</filename> @@ -113,23 +113,23 @@ </para> <para> - Prior to parsing configuration files, Bitbake looks + Prior to parsing configuration files, BitBake looks at certain variables, including: <itemizedlist> <listitem><para> - <link linkend='var-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link> + <link linkend='var-bb-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link> </para></listitem> <listitem><para> - <link linkend='var-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link> + <link linkend='var-bb-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link> </para></listitem> <listitem><para> - <link linkend='var-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link> + <link linkend='var-bb-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link> </para></listitem> <listitem><para> - <link linkend='var-BB_ORIGENV'><filename>BB_ORIGENV</filename></link> + <link linkend='var-bb-BB_ORIGENV'><filename>BB_ORIGENV</filename></link> </para></listitem> <listitem><para> - <link linkend='var-BITBAKE_UI'><filename>BITBAKE_UI</filename></link> + <link linkend='var-bb-BITBAKE_UI'><filename>BITBAKE_UI</filename></link> </para></listitem> </itemizedlist> The first four variables in this list relate to how BitBake treats shell @@ -156,7 +156,7 @@ BitBake first searches the current working directory for an optional <filename>conf/bblayers.conf</filename> configuration file. This file is expected to contain a - <link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link> + <link linkend='var-bb-BBLAYERS'><filename>BBLAYERS</filename></link> variable that is a space-delimited list of 'layer' directories. Recall that if BitBake cannot find a <filename>bblayers.conf</filename> file, then it is assumed the user has set the <filename>BBPATH</filename> @@ -166,10 +166,10 @@ <para> For each directory (layer) in this list, a <filename>conf/layer.conf</filename> file is located and parsed with the - <link linkend='var-LAYERDIR'><filename>LAYERDIR</filename></link> + <link linkend='var-bb-LAYERDIR'><filename>LAYERDIR</filename></link> variable being set to the directory where the layer was found. The idea is these files automatically set up - <link linkend='var-BBPATH'><filename>BBPATH</filename></link> + <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link> and other variables correctly for a given build directory. </para> @@ -189,7 +189,7 @@ depending on the environment variables previously mentioned or set in the configuration files. The - "<link linkend='ref-variables-glos'>Variables Glossary</link>" + "<link linkend='ref-bb-variables-glos'>Variables Glossary</link>" chapter presents a full list of variables. </para> @@ -204,7 +204,7 @@ <para> The <filename>base.bbclass</filename> file is always included. Other classes that are specified in the configuration using the - <link linkend='var-INHERIT'><filename>INHERIT</filename></link> + <link linkend='var-bb-INHERIT'><filename>INHERIT</filename></link> variable are also included. BitBake searches for class files in a <filename>classes</filename> subdirectory under @@ -270,7 +270,7 @@ <para> During the configuration phase, BitBake will have set - <link linkend='var-BBFILES'><filename>BBFILES</filename></link>. + <link linkend='var-bb-BBFILES'><filename>BBFILES</filename></link>. BitBake now uses it to construct a list of recipes to parse, along with any append files (<filename>.bbappend</filename>) to apply. @@ -292,7 +292,7 @@ Any inherit statements cause BitBake to find and then parse class files (<filename>.bbclass</filename>) using - <link linkend='var-BBPATH'><filename>BBPATH</filename></link> + <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link> as the search path. Finally, BitBake parses in order any append files found in <filename>BBFILES</filename>. @@ -303,8 +303,8 @@ pieces of metadata. For example, in <filename>bitbake.conf</filename> the recipe name and version are used to set the variables - <link linkend='var-PN'><filename>PN</filename></link> and - <link linkend='var-PV'><filename>PV</filename></link>: + <link linkend='var-bb-PN'><filename>PN</filename></link> and + <link linkend='var-bb-PV'><filename>PV</filename></link>: <literallayout class='monospaced'> PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" @@ -336,10 +336,10 @@ recipe information. The validity of this cache is determined by first computing a checksum of the base configuration data (see - <link linkend='var-BB_HASHCONFIG_WHITELIST'><filename>BB_HASHCONFIG_WHITELIST</filename></link>) + <link linkend='var-bb-BB_HASHCONFIG_WHITELIST'><filename>BB_HASHCONFIG_WHITELIST</filename></link>) and then checking if the checksum matches. If that checksum matches what is in the cache and the recipe - and class files have not changed, Bitbake is able to use + and class files have not changed, BitBake is able to use the cache. BitBake then reloads the cached information about the recipe instead of reparsing it from scratch. @@ -384,9 +384,9 @@ the recipe can be known. Each recipe's <filename>PROVIDES</filename> list is created implicitly through the recipe's - <link linkend='var-PN'><filename>PN</filename></link> variable + <link linkend='var-bb-PN'><filename>PN</filename></link> variable and explicitly through the recipe's - <link linkend='var-PROVIDES'><filename>PROVIDES</filename></link> + <link linkend='var-bb-PROVIDES'><filename>PROVIDES</filename></link> variable, which is optional. </para> @@ -427,9 +427,9 @@ PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" </literallayout> The default - <link linkend='var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link> + <link linkend='var-bb-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link> is the provider with the same name as the target. - Bitbake iterates through each target it needs to build and + BitBake iterates through each target it needs to build and resolves them and their dependencies using this process. </para> @@ -439,10 +439,10 @@ BitBake defaults to the highest version of a provider. Version comparisons are made using the same method as Debian. You can use the - <link linkend='var-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></link> + <link linkend='var-bb-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></link> variable to specify a particular version. You can influence the order by using the - <link linkend='var-DEFAULT_PREFERENCE'><filename>DEFAULT_PREFERENCE</filename></link> + <link linkend='var-bb-DEFAULT_PREFERENCE'><filename>DEFAULT_PREFERENCE</filename></link> variable. </para> @@ -464,7 +464,7 @@ BitBake defaults to selecting the most recent version, unless otherwise specified. If the recipe in question has a - <link linkend='var-DEFAULT_PREFERENCE'><filename>DEFAULT_PREFERENCE</filename></link> + <link linkend='var-bb-DEFAULT_PREFERENCE'><filename>DEFAULT_PREFERENCE</filename></link> set lower than the other recipes (default is 0), then it will not be selected. This allows the person or persons maintaining @@ -475,9 +475,9 @@ <para> If the first recipe is named <filename>a_1.1.bb</filename>, then the - <link linkend='var-PN'><filename>PN</filename></link> variable + <link linkend='var-bb-PN'><filename>PN</filename></link> variable will be set to “a”, and the - <link linkend='var-PV'><filename>PV</filename></link> + <link linkend='var-bb-PV'><filename>PV</filename></link> variable will be set to 1.1. </para> @@ -532,11 +532,11 @@ <para> Dependencies are defined through several variables. You can find information about variables BitBake uses in - the <link linkend='ref-variables-glos'>Variables Glossary</link> + the <link linkend='ref-bb-variables-glos'>Variables Glossary</link> near the end of this manual. At a basic level, it is sufficient to know that BitBake uses the - <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> and - <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> variables when + <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> and + <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> variables when calculating dependencies. </para> @@ -560,7 +560,7 @@ <para> The build now starts with BitBake forking off threads up to the limit set in the - <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> + <link linkend='var-bb-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> variable. BitBake continues to fork threads as long as there are tasks ready to run, those tasks have all their dependencies met, and the thread threshold has not been @@ -574,7 +574,7 @@ <para> As each task completes, a timestamp is written to the directory specified by the - <link linkend='var-STAMP'><filename>STAMP</filename></link> variable. + <link linkend='var-bb-STAMP'><filename>STAMP</filename></link> variable. On subsequent runs, BitBake looks in the build directory within <filename>tmp/stamps</filename> and does not rerun tasks that are already completed unless a timestamp is found to be invalid. @@ -618,12 +618,12 @@ <para> Tasks can be either a shell task or a Python task. For shell tasks, BitBake writes a shell script to - <filename>${</filename><link linkend='var-T'><filename>T</filename></link><filename>}/run.do_taskname.pid</filename> + <filename>${</filename><link linkend='var-bb-T'><filename>T</filename></link><filename>}/run.do_taskname.<replaceable>pid</replaceable></filename> and then executes the script. The generated shell script contains all the exported variables, and the shell functions with all variables expanded. Output from the shell script goes to the file - <filename>${T}/log.do_taskname.pid</filename>. + <filename>${T}/log.do_taskname.<replaceable>pid</replaceable></filename>. Looking at the expanded shell functions in the run file and the output in the log files is a useful debugging technique. </para> @@ -645,10 +645,10 @@ behavior: <itemizedlist> <listitem><para> - <link linkend='var-BB_SCHEDULER'><filename>BB_SCHEDULER</filename></link> + <link linkend='var-bb-BB_SCHEDULER'><filename>BB_SCHEDULER</filename></link> </para></listitem> <listitem><para> - <link linkend='var-BB_SCHEDULERS'><filename>BB_SCHEDULERS</filename></link> + <link linkend='var-bb-BB_SCHEDULERS'><filename>BB_SCHEDULERS</filename></link> </para></listitem> </itemizedlist> It is possible to have functions run before and after a task's main @@ -684,7 +684,7 @@ The simplistic approach for excluding the working directory is to set it to some fixed value and create the checksum for the "run" script. BitBake goes one step better and uses the - <link linkend='var-BB_HASHBASE_WHITELIST'><filename>BB_HASHBASE_WHITELIST</filename></link> + <link linkend='var-bb-BB_HASHBASE_WHITELIST'><filename>BB_HASHBASE_WHITELIST</filename></link> variable to define a list of variables that should never be included when generating the signatures. </para> @@ -795,7 +795,7 @@ This results in any metadata change that changes the task hash, automatically causing the task to be run again. This removes the need to bump - <link linkend='var-PR'><filename>PR</filename></link> + <link linkend='var-bb-PR'><filename>PR</filename></link> values, and changes to metadata automatically ripple across the build. </para> @@ -821,7 +821,7 @@ <para> It is worth noting that BitBake's "-S" option lets you - debug Bitbake's processing of signatures. + debug BitBake's processing of signatures. The options passed to -S allow different debugging modes to be used, either using BitBake's own debug functions or possibly those defined in the metadata/signature handler @@ -884,7 +884,7 @@ <para> BitBake first calls the function defined by the - <link linkend='var-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></link> + <link linkend='var-bb-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></link> variable with a list of tasks and corresponding hashes it wants to build. This function is designed to be fast and returns a list @@ -908,7 +908,7 @@ For example, it is pointless to obtain a compiler if you already have the compiled binary. To handle this, BitBake calls the - <link linkend='var-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></link> + <link linkend='var-bb-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></link> function for each successful setscene task to know whether or not it needs to obtain the dependencies of that task. </para> @@ -916,7 +916,7 @@ <para> Finally, after all the setscene tasks have executed, BitBake calls the function listed in - <link linkend='var-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></link> + <link linkend='var-bb-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></link> with the list of tasks BitBake thinks has been "covered". The metadata can then ensure that this list is correct and can inform BitBake that it wants specific tasks to be run regardless @@ -929,4 +929,101 @@ section. </para> </section> + + <section id="logging"> + <title>Logging</title> + <para> + In addition to the standard command line option to control how + verbose builds are when execute, bitbake also supports user defined + configuration of the + <ulink url='https://docs.python.org/3/library/logging.html'>Python logging</ulink> + facilities through the + <link linkend="var-bb-BB_LOGCONFIG"><filename>BB_LOGCONFIG</filename></link> + variable. This variable defines a json or yaml + <ulink url='https://docs.python.org/3/library/logging.config.html'>logging configuration</ulink> + that will be intelligently merged into the default configuration. + The logging configuration is merged using the following rules: + <itemizedlist> + <listitem><para> + The user defined configuration will completely replace the default + configuration if top level key + <filename>bitbake_merge</filename> is set to the value + <filename>False</filename>. In this case, all other rules + are ignored. + </para></listitem> + <listitem><para> + The user configuration must have a top level + <filename>version</filename> which must match the value of + the default configuration. + </para></listitem> + <listitem><para> + Any keys defined in the <filename>handlers</filename>, + <filename>formatters</filename>, or <filename>filters</filename>, + will be merged into the same section in the default + configuration, with the user specified keys taking + replacing a default one if there is a conflict. In + practice, this means that if both the default configuration + and user configuration specify a handler named + <filename>myhandler</filename>, the user defined one will + replace the default. To prevent the user from inadvertently + replacing a default handler, formatter, or filter, all of + the default ones are named with a prefix of + "<filename>BitBake.</filename>" + </para></listitem> + <listitem><para> + If a logger is defined by the user with the key + <filename>bitbake_merge</filename> set to + <filename>False</filename>, that logger will be completely + replaced by user configuration. In this case, no other + rules will apply to that logger. + </para></listitem> + <listitem><para> + All user defined <filename>filter</filename> and + <filename>handlers</filename> properties for a given logger + will be merged with corresponding properties from the + default logger. For example, if the user configuration adds + a filter called <filename>myFilter</filename> to the + <filename>BitBake.SigGen</filename>, and the default + configuration adds a filter called + <filename>BitBake.defaultFilter</filename>, both filters + will be applied to the logger + </para></listitem> + </itemizedlist> + </para> + + <para> + As an example, consider the following user logging configuration + file which logs all Hash Equivalence related messages of VERBOSE or + higher to a file called <filename>hashequiv.log</filename> + <literallayout class='monospaced'> + { + "version": 1, + "handlers": { + "autobuilderlog": { + "class": "logging.FileHandler", + "formatter": "logfileFormatter", + "level": "DEBUG", + "filename": "hashequiv.log", + "mode": "w" + } + }, + "formatters": { + "logfileFormatter": { + "format": "%(name)s: %(levelname)s: %(message)s" + } + }, + "loggers": { + "BitBake.SigGen.HashEquiv": { + "level": "VERBOSE", + "handlers": ["autobuilderlog"] + }, + "BitBake.RunQueue.HashEquiv": { + "level": "VERBOSE", + "handlers": ["autobuilderlog"] + } + } + } + </literallayout> + </para> + </section> </chapter> diff --git a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml index 92b2c3d1..d1bfc233 100644 --- a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml +++ b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml @@ -44,7 +44,7 @@ </literallayout> This code sets up an instance of the fetch class. The instance uses a space-separated list of URLs from the - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link> variable and then calls the <filename>download</filename> method to download the files. </para> @@ -78,7 +78,7 @@ <listitem><para><emphasis>Pre-mirror Sites:</emphasis> BitBake first uses pre-mirrors to try and find source files. These locations are defined using the - <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link> + <link linkend='var-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link> variable. </para></listitem> <listitem><para><emphasis>Source URI:</emphasis> @@ -88,7 +88,7 @@ <listitem><para><emphasis>Mirror Sites:</emphasis> If fetch failures occur, BitBake next uses mirror locations as defined by the - <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link> + <link linkend='var-bb-MIRRORS'><filename>MIRRORS</filename></link> variable. </para></listitem> </itemizedlist> @@ -139,12 +139,12 @@ </para> <para> - Since network accesses are slow, Bitbake maintains a + Since network accesses are slow, BitBake maintains a cache of files downloaded from the network. Any source files that are not local (i.e. downloaded from the Internet) are placed into the download directory, which is specified by the - <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link> + <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> variable. </para> @@ -184,11 +184,11 @@ <para> If - <link linkend='var-BB_STRICT_CHECKSUM'><filename>BB_STRICT_CHECKSUM</filename></link> + <link linkend='var-bb-BB_STRICT_CHECKSUM'><filename>BB_STRICT_CHECKSUM</filename></link> is set, any download without a checksum triggers an error message. The - <link linkend='var-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></link> + <link linkend='var-bb-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></link> variable can be used to make any attempted network access a fatal error, which is useful for checking that mirrors are complete as well as other things. @@ -265,11 +265,11 @@ The filename you specify within the URL can be either an absolute or relative path to a file. If the filename is relative, the contents of the - <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> + <link linkend='var-bb-FILESPATH'><filename>FILESPATH</filename></link> variable is used in the same way <filename>PATH</filename> is used to find executables. If the file cannot be found, it is assumed that it is available in - <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link> + <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> by the time the <filename>download()</filename> method is called. </para> @@ -304,7 +304,7 @@ allows the name of the downloaded file to be specified. Specifying the name of the downloaded file is useful for avoiding collisions in - <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link> + <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> when dealing with multiple files that have the same name. </para> @@ -355,7 +355,7 @@ A special value of "now" causes the checkout to be updated on every build. </para></listitem> - <listitem><para><emphasis><link linkend='var-CVSDIR'><filename>CVSDIR</filename></link>:</emphasis> + <listitem><para><emphasis><link linkend='var-bb-CVSDIR'><filename>CVSDIR</filename></link>:</emphasis> Specifies where a temporary checkout is saved. The location is often <filename>DL_DIR/cvs</filename>. </para></listitem> @@ -395,7 +395,7 @@ <listitem><para><emphasis>"date":</emphasis> Specifies a date. If no "date" is specified, the - <link linkend='var-SRCDATE'><filename>SRCDATE</filename></link> + <link linkend='var-bb-SRCDATE'><filename>SRCDATE</filename></link> of the configuration is used to checkout a specific date. The special value of "now" causes the checkout to be updated on every build. @@ -406,7 +406,7 @@ to which the module is unpacked. You are forcing the module into a special directory relative to - <link linkend='var-CVSDIR'><filename>CVSDIR</filename></link>. + <link linkend='var-bb-CVSDIR'><filename>CVSDIR</filename></link>. </para></listitem> <listitem><para><emphasis>"rsh"</emphasis> Used in conjunction with the "method" parameter. @@ -448,7 +448,7 @@ <filename>FETCHCMD_svn</filename>, which defaults to "svn". The fetcher's temporary working directory is set by - <link linkend='var-SVNDIR'><filename>SVNDIR</filename></link>, + <link linkend='var-bb-SVNDIR'><filename>SVNDIR</filename></link>, which is usually <filename>DL_DIR/svn</filename>. </para> @@ -509,7 +509,7 @@ source control system. The fetcher works by creating a bare clone of the remote into - <link linkend='var-GITDIR'><filename>GITDIR</filename></link>, + <link linkend='var-bb-GITDIR'><filename>GITDIR</filename></link>, which is usually <filename>DL_DIR/git2</filename>. This bare clone is then cloned into the work directory during the unpack stage when a specific tree is checked out. @@ -612,7 +612,7 @@ This fetcher submodule inherits from the <link linkend='git-fetcher'>Git fetcher</link> and extends that fetcher's behavior by fetching a repository's submodules. - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link> is passed to the Git fetcher as described in the "<link linkend='git-fetcher'>Git Fetcher (<filename>git://</filename>)</link>" section. @@ -647,9 +647,9 @@ <para> To use this fetcher, make sure your recipe has proper - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>, - <link linkend='var-SRCREV'><filename>SRCREV</filename></link>, and - <link linkend='var-PV'><filename>PV</filename></link> settings. + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>, + <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link>, and + <link linkend='var-bb-PV'><filename>PV</filename></link> settings. Here is an example: <literallayout class='monospaced'> SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module" @@ -734,15 +734,15 @@ <filename>FETCHCMD_p4</filename>, which defaults to "p4". The fetcher's temporary working directory is set by - <link linkend='var-P4DIR'><filename>P4DIR</filename></link>, + <link linkend='var-bb-P4DIR'><filename>P4DIR</filename></link>, which defaults to "DL_DIR/p4". </para> <para> To use this fetcher, make sure your recipe has proper - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>, - <link linkend='var-SRCREV'><filename>SRCREV</filename></link>, and - <link linkend='var-PV'><filename>PV</filename></link> values. + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>, + <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link>, and + <link linkend='var-bb-PV'><filename>PV</filename></link> values. The p4 executable is able to use the config file defined by your system's <filename>P4CONFIG</filename> environment variable in order to define the Perforce server URL and port, username, and @@ -793,9 +793,9 @@ <filename>google-repo</filename> source control system. The fetcher works by initiating and syncing sources of the repository into - <link linkend='var-REPODIR'><filename>REPODIR</filename></link>, + <link linkend='var-bb-REPODIR'><filename>REPODIR</filename></link>, which is usually - <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link><filename>/repo</filename>. + <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link><filename>/repo</filename>. </para> <para> @@ -832,19 +832,22 @@ Bazaar (<filename>bzr://</filename>) </para></listitem> <listitem><para> - Trees using Git Annex (<filename>gitannex://</filename>) + Mercurial (<filename>hg://</filename>) </para></listitem> <listitem><para> - Secure FTP (<filename>sftp://</filename>) + npm (<filename>npm://</filename>) </para></listitem> <listitem><para> - Secure Shell (<filename>ssh://</filename>) + OSC (<filename>osc://</filename>) </para></listitem> <listitem><para> - OSC (<filename>osc://</filename>) + Secure FTP (<filename>sftp://</filename>) </para></listitem> <listitem><para> - Mercurial (<filename>hg://</filename>) + Secure Shell (<filename>ssh://</filename>) + </para></listitem> + <listitem><para> + Trees using Git Annex (<filename>gitannex://</filename>) </para></listitem> </itemizedlist> No documentation currently exists for these lesser used diff --git a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml index 9076f0fc..11eb36aa 100644 --- a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml +++ b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml @@ -166,7 +166,7 @@ Having a project directory is a good way to isolate your project. </para></listitem> - <listitem><para><emphasis>Run Bitbake:</emphasis> + <listitem><para><emphasis>Run BitBake:</emphasis> At this point, you have nothing but a project directory. Run the <filename>bitbake</filename> command and see what it does: @@ -194,10 +194,10 @@ <para> When you run BitBake, it begins looking for metadata files. The - <link linkend='var-BBPATH'><filename>BBPATH</filename></link> + <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link> variable is what tells BitBake where to look for those files. <filename>BBPATH</filename> is not set and you need to set it. - Without <filename>BBPATH</filename>, Bitbake cannot + Without <filename>BBPATH</filename>, BitBake cannot find any configuration files (<filename>.conf</filename>) or recipe files (<filename>.bb</filename>) at all. BitBake also cannot find the <filename>bitbake.conf</filename> @@ -225,7 +225,7 @@ as the shell would. </note> </para></listitem> - <listitem><para><emphasis>Run Bitbake:</emphasis> + <listitem><para><emphasis>Run BitBake:</emphasis> Now that you have <filename>BBPATH</filename> defined, run the <filename>bitbake</filename> command again: <literallayout class='monospaced'> @@ -273,14 +273,14 @@ some editor to create the <filename>bitbake.conf</filename> so that it contains the following: <literallayout class='monospaced'> - <link linkend='var-PN'>PN</link> = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" + <link linkend='var-bb-PN'>PN</link> = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" </literallayout> <literallayout class='monospaced'> - TMPDIR = "${<link linkend='var-TOPDIR'>TOPDIR</link>}/tmp" - <link linkend='var-CACHE'>CACHE</link> = "${TMPDIR}/cache" - <link linkend='var-STAMP'>STAMP</link> = "${TMPDIR}/${PN}/stamps" - <link linkend='var-T'>T</link> = "${TMPDIR}/${PN}/work" - <link linkend='var-B'>B</link> = "${TMPDIR}/${PN}" + TMPDIR = "${<link linkend='var-bb-TOPDIR'>TOPDIR</link>}/tmp" + <link linkend='var-bb-CACHE'>CACHE</link> = "${TMPDIR}/cache" + <link linkend='var-bb-STAMP'>STAMP</link> = "${TMPDIR}/${PN}/stamps" + <link linkend='var-bb-T'>T</link> = "${TMPDIR}/${PN}/work" + <link linkend='var-bb-B'>B</link> = "${TMPDIR}/${PN}" </literallayout> <note> Without a value for <filename>PN</filename>, the @@ -313,7 +313,7 @@ example, click on the links to take you to the definitions in the glossary. </para></listitem> - <listitem><para><emphasis>Run Bitbake:</emphasis> + <listitem><para><emphasis>Run BitBake:</emphasis> After making sure that the <filename>conf/bitbake.conf</filename> file exists, you can run the <filename>bitbake</filename> command again: @@ -364,7 +364,7 @@ more depending on which build environments BitBake is supporting. </para></listitem> - <listitem><para><emphasis>Run Bitbake:</emphasis> + <listitem><para><emphasis>Run BitBake:</emphasis> After making sure that the <filename>classes/base.bbclass</filename> file exists, you can run the <filename>bitbake</filename> command again: @@ -402,12 +402,12 @@ Move to the <filename>conf</filename> directory and create a <filename>layer.conf</filename> file that has the following: <literallayout class='monospaced'> - BBPATH .= ":${<link linkend='var-LAYERDIR'>LAYERDIR</link>}" + BBPATH .= ":${<link linkend='var-bb-LAYERDIR'>LAYERDIR</link>}" - <link linkend='var-BBFILES'>BBFILES</link> += "${LAYERDIR}/*.bb" + <link linkend='var-bb-BBFILES'>BBFILES</link> += "${LAYERDIR}/*.bb" - <link linkend='var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</link> += "mylayer" - <link linkend='var-BBFILE_PATTERN'>BBFILE_PATTERN_mylayer</link> := "^${LAYERDIR_RE}/" + <link linkend='var-bb-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</link> += "mylayer" + <link linkend='var-bb-BBFILE_PATTERN'>BBFILE_PATTERN_mylayer</link> := "^${LAYERDIR_RE}/" </literallayout> For information on these variables, click the links to go to the definitions in the glossary.</para> @@ -416,9 +416,9 @@ a recipe file named <filename>printhello.bb</filename> that has the following: <literallayout class='monospaced'> - <link linkend='var-DESCRIPTION'>DESCRIPTION</link> = "Prints Hello World" - <link linkend='var-PN'>PN</link> = 'printhello' - <link linkend='var-PV'>PV</link> = '1' + <link linkend='var-bb-DESCRIPTION'>DESCRIPTION</link> = "Prints Hello World" + <link linkend='var-bb-PN'>PN</link> = 'printhello' + <link linkend='var-bb-PV'>PV</link> = '1' python do_build() { bb.plain("********************"); @@ -434,7 +434,7 @@ For more information on these variables, follow the links to the glossary. </para></listitem> - <listitem><para><emphasis>Run Bitbake With a Target:</emphasis> + <listitem><para><emphasis>Run BitBake With a Target:</emphasis> Now that a BitBake target exists, run the command and provide that target: <literallayout class='monospaced'> @@ -468,7 +468,7 @@ You need to provide your own information for <filename>you</filename> in the file. </para></listitem> - <listitem><para><emphasis>Run Bitbake With a Target:</emphasis> + <listitem><para><emphasis>Run BitBake With a Target:</emphasis> Now that you have supplied the <filename>bblayers.conf</filename> file, run the <filename>bitbake</filename> command and provide the target: diff --git a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml index f7d312a3..995c2fa7 100644 --- a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml +++ b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml @@ -127,7 +127,7 @@ (e.g. Cygwin, the BSDs, and so forth). </para></listitem> <listitem><para> - Be self contained, rather than tightly + Be self-contained, rather than tightly integrated into the build machine's root filesystem. </para></listitem> @@ -221,6 +221,8 @@ them</para></listitem> <listitem><para>How to configure and compile the source code</para></listitem> + <listitem><para>How to assemble the generated artifacts into + one or more installable packages</para></listitem> <listitem><para>Where on the target machine to install the package or packages created</para></listitem> </itemizedlist> @@ -229,7 +231,7 @@ <para> Within the context of BitBake, or any project utilizing BitBake as its build system, files with the <filename>.bb</filename> - extension are referred to as recipes. + extension are referred to as <firstterm>recipes</firstterm>. <note> The term "package" is also commonly used to describe recipes. However, since the same word is used to describe packaged @@ -252,9 +254,9 @@ various configuration variables that govern the project's build process. These files fall into several areas that define - machine configuration options, distribution configuration - options, compiler tuning options, general common - configuration options, and user configuration options. + machine configuration, distribution configuration, + possible compiler tuning, general common + configuration, and user configuration. The main configuration file is the sample <filename>bitbake.conf</filename> file, which is located within the BitBake source tree @@ -292,7 +294,7 @@ Layers allow you to isolate different types of customizations from each other. While you might find it tempting to keep everything in one layer - when working on a single project, the more modular you organize + when working on a single project, the more modular your metadata, the easier it is to cope with future changes. </para> @@ -300,8 +302,8 @@ To illustrate how you can use layers to keep things modular, consider customizations you might make to support a specific target machine. These types of customizations typically reside in a special layer, - rather than a general layer, called a Board Support Package (BSP) - Layer. + rather than a general layer, called a <firstterm>Board Support Package</firstterm> (BSP) + layer. Furthermore, the machine customizations should be isolated from recipes and metadata that support a new GUI environment, for example. @@ -448,7 +450,7 @@ <listitem><para><emphasis>Using the BitBake that Comes With Your Build Checkout:</emphasis> A final possibility for getting a copy of BitBake is that it - already comes with your checkout of a larger Bitbake-based build + already comes with your checkout of a larger BitBake-based build system, such as Poky. Rather than manually checking out individual layers and gluing them together yourself, you can check @@ -692,15 +694,10 @@ </para> <para> - When you generate a dependency graph, BitBake writes three files + When you generate a dependency graph, BitBake writes two files to the current working directory: <itemizedlist> <listitem><para> - <emphasis><filename>recipe-depends.dot</filename>:</emphasis> - Shows dependencies between recipes (i.e. a collapsed version of - <filename>task-depends.dot</filename>). - </para></listitem> - <listitem><para> <emphasis><filename>task-depends.dot</filename>:</emphasis> Shows dependencies between tasks. These dependencies match BitBake's internal task execution list. @@ -781,7 +778,7 @@ target, you must also enable BitBake to perform multiple configuration builds. Enabling is accomplished by setting the - <link linkend='var-BBMULTICONFIG'><filename>BBMULTICONFIG</filename></link> + <link linkend='var-bb-BBMULTICONFIG'><filename>BBMULTICONFIG</filename></link> variable in the <filename>local.conf</filename> configuration file. As an example, suppose you had configuration files @@ -791,7 +788,7 @@ The following statement in the <filename>local.conf</filename> file both enables BitBake to perform multiple configuration builds and - specifies the two multiconfigs: + specifies the two extra multiconfigs: <literallayout class='monospaced'> BBMULTICONFIG = "target1 target2" </literallayout> @@ -803,13 +800,13 @@ builds, use the following command form to start the builds: <literallayout class='monospaced'> - $ bitbake [multiconfig:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable> [[[multiconfig:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable>] ... ] + $ bitbake [mc:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable> [[[mc:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable>] ... ] </literallayout> - Here is an example for two multiconfigs: + Here is an example for two extra multiconfigs: <filename>target1</filename> and <filename>target2</filename>: <literallayout class='monospaced'> - $ bitbake multiconfig:target1:<replaceable>target</replaceable> multiconfig:target2:<replaceable>target</replaceable> + $ bitbake mc::<replaceable>target</replaceable> mc:target1:<replaceable>target</replaceable> mc:target2:<replaceable>target</replaceable> </literallayout> </para> </section> @@ -837,13 +834,13 @@ build, you must declare the dependencies in the recipe using the following statement form: <literallayout class='monospaced'> - <replaceable>task_or_package</replaceable>[mcdepends] = "multiconfig:<replaceable>from_multiconfig</replaceable>:<replaceable>to_multiconfig</replaceable>:<replaceable>recipe_name</replaceable>:<replaceable>task_on_which_to_depend</replaceable>" + <replaceable>task_or_package</replaceable>[mcdepends] = "mc:<replaceable>from_multiconfig</replaceable>:<replaceable>to_multiconfig</replaceable>:<replaceable>recipe_name</replaceable>:<replaceable>task_on_which_to_depend</replaceable>" </literallayout> To better show how to use this statement, consider an example with two multiconfigs: <filename>target1</filename> and <filename>target2</filename>: <literallayout class='monospaced'> - <replaceable>image_task</replaceable>[mcdepends] = "multiconfig:target1:target2:<replaceable>image2</replaceable>:<replaceable>rootfs_task</replaceable>" + <replaceable>image_task</replaceable>[mcdepends] = "mc:target1:target2:<replaceable>image2</replaceable>:<replaceable>rootfs_task</replaceable>" </literallayout> In this example, the <replaceable>from_multiconfig</replaceable> is "target1" and @@ -859,7 +856,7 @@ Once you set up this dependency, you can build the "target1" multiconfig using a BitBake command as follows: <literallayout class='monospaced'> - $ bitbake multiconfig:target1:<replaceable>image1</replaceable> + $ bitbake mc:target1:<replaceable>image1</replaceable> </literallayout> This command executes all the tasks needed to create <replaceable>image1</replaceable> for the "target1" @@ -875,7 +872,7 @@ Consider this change to the statement in the <replaceable>image1</replaceable> recipe: <literallayout class='monospaced'> - <replaceable>image_task</replaceable>[mcdepends] = "multiconfig:target1:target2:<replaceable>image2</replaceable>:<replaceable>image_task</replaceable>" + <replaceable>image_task</replaceable>[mcdepends] = "mc:target1:target2:<replaceable>image2</replaceable>:<replaceable>image_task</replaceable>" </literallayout> In this case, BitBake must create <replaceable>image2</replaceable> for the "target2" diff --git a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml index d91f437d..0ca53216 100644 --- a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml +++ b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml @@ -5,7 +5,7 @@ <title>Syntax and Operators</title> <para> - Bitbake files have their own syntax. + BitBake files have their own syntax. The syntax has similarities to several other languages but also has some unique features. This section describes the available syntax and operators @@ -61,6 +61,78 @@ </para> </section> + <section id='modifying-existing-variables'> + <title>Modifying Existing Variables</title> + + <para> + Sometimes you need to modify existing variables. + Following are some cases where you might find you want to + modify an existing variable: + <itemizedlist> + <listitem><para> + Customize a recipe that uses the variable. + </para></listitem> + <listitem><para> + Change a variable's default value used in a + <filename>*.bbclass</filename> file. + </para></listitem> + <listitem><para> + Change the variable in a <filename>*.bbappend</filename> + file to override the variable in the original recipe. + </para></listitem> + <listitem><para> + Change the variable in a configuration file so that the + value overrides an existing configuration. + </para></listitem> + </itemizedlist> + </para> + + <para> + Changing a variable value can sometimes depend on how the + value was originally assigned and also on the desired + intent of the change. + In particular, when you append a value to a variable that + has a default value, the resulting value might not be what + you expect. + In this case, the value you provide might replace the value + rather than append to the default value. + </para> + + <para> + If after you have changed a variable's value and something + unexplained occurs, you can use BitBake to check the actual + value of the suspect variable. + You can make these checks for both configuration and recipe + level changes: + <itemizedlist> + <listitem><para> + For configuration changes, use the following: + <literallayout class='monospaced'> + $ bitbake -e + </literallayout> + This command displays variable values after the + configuration files (i.e. <filename>local.conf</filename>, + <filename>bblayers.conf</filename>, + <filename>bitbake.conf</filename> and so forth) have + been parsed. + <note> + Variables that are exported to the environment are + preceded by the string "export" in the command's + output. + </note> + </para></listitem> + <listitem><para> + For recipe changes, use the following: + <literallayout class='monospaced'> + $ bitbake <replaceable>recipe</replaceable> -e | grep VARIABLE=" + </literallayout> + This command checks to see if the variable actually + makes it into a specific recipe. + </para></listitem> + </itemizedlist> + </para> + </section> + <section id='line-joining'> <title>Line Joining</title> @@ -222,17 +294,20 @@ rather than when the variable is actually used: <literallayout class='monospaced'> T = "123" - A := "${B} ${A} test ${T}" + A := "test ${T}" T = "456" - B = "${T} bval" + B := "${T} ${C}" C = "cval" C := "${C}append" </literallayout> In this example, <filename>A</filename> contains - "test 123" because <filename>${B}</filename> and - <filename>${A}</filename> at the time of parsing are undefined, - which leaves "test 123". - And, the variable <filename>C</filename> + "test 123", even though the final value of <filename>T</filename> + is "456". + The variable <filename>B</filename> will end up containing "456 cvalappend". + This is because references to undefined variables are preserved as is + during (immediate)expansion. This is in contrast to GNU Make, where undefined + variables expand to nothing. + The variable <filename>C</filename> contains "cvalappend" since <filename>${C}</filename> immediately expands to "cval". </para> @@ -297,9 +372,8 @@ <para> These operators differ from the ":=", ".=", "=.", "+=", and "=+" - operators in that their effects are deferred - until after parsing completes rather than being immediately - applied. + operators in that their effects are applied at variable + expansion time rather than being immediately applied. Here are some examples: <literallayout class='monospaced'> B = "bval" @@ -348,18 +422,22 @@ FOO = "123 456 789 123456 123 456 123 456" FOO_remove = "123" FOO_remove = "456" - FOO2 = "abc def ghi abcdef abc def abc def" - FOO2_remove = "abc def" + FOO2 = " abc def ghi abcdef abc def abc def def" + FOO2_remove = " \ + def \ + abc \ + ghi \ + " </literallayout> The variable <filename>FOO</filename> becomes - " 789 123456 " + " 789 123456 " and <filename>FOO2</filename> becomes - " ghi abcdef ". + " abcdef ". </para> <para> Like "_append" and "_prepend", "_remove" - is deferred until after parsing completes. + is applied at variable expansion time. </para> </section> @@ -595,7 +673,7 @@ <para> BitBake uses - <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link> + <link linkend='var-bb-OVERRIDES'><filename>OVERRIDES</filename></link> to control what variables are overridden after BitBake parses recipes and configuration files. This section describes how you can use @@ -705,7 +783,7 @@ <para>Internally, this is implemented by prepending the task (e.g. "task-compile:") to the value of - <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link> + <link linkend='var-bb-OVERRIDES'><filename>OVERRIDES</filename></link> for the local datastore of the <filename>do_compile</filename> task.</para> @@ -724,17 +802,15 @@ <title>Key Expansion</title> <para> - Key expansion happens when the BitBake datastore is finalized - just before BitBake expands overrides. + Key expansion happens when the BitBake datastore is finalized. To better understand this, consider the following example: <literallayout class='monospaced'> A${B} = "X" B = "2" A2 = "Y" </literallayout> - In this case, after all the parsing is complete, and - before any overrides are handled, BitBake expands - <filename>${B}</filename> into "2". + In this case, after all the parsing is complete, + BitBake expands <filename>${B}</filename> into "2". This expansion causes <filename>A2</filename>, which was set to "Y" before the expansion, to become "X". </para> @@ -868,7 +944,7 @@ <para> BitBake uses the - <link linkend='var-BBPATH'><filename>BBPATH</filename></link> + <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link> variable to locate needed include and class files. Additionally, BitBake searches the current directory for <filename>include</filename> and <filename>require</filename> @@ -1086,7 +1162,7 @@ <para> When creating a configuration file (<filename>.conf</filename>), you can use the - <link linkend='var-INHERIT'><filename>INHERIT</filename></link> + <link linkend='var-bb-INHERIT'><filename>INHERIT</filename></link> configuration directive to inherit a class. BitBake only supports this directive when used within a configuration file. @@ -1341,7 +1417,7 @@ </section> <section id='bitbake-style-python-functions-versus-python-functions'> - <title>Bitbake-Style Python Functions Versus Python Functions</title> + <title>BitBake-Style Python Functions Versus Python Functions</title> <para> Following are some important differences between @@ -1370,7 +1446,7 @@ </para></listitem> <listitem><para> BitBake-style Python functions generate a separate - <filename>${</filename><link linkend='var-T'><filename>T</filename></link><filename>}/run.</filename><replaceable>function-name</replaceable><filename>.</filename><replaceable>pid</replaceable> + <filename>${</filename><link linkend='var-bb-T'><filename>T</filename></link><filename>}/run.</filename><replaceable>function-name</replaceable><filename>.</filename><replaceable>pid</replaceable> script that is executed to run the function, and also generate a log file in <filename>${T}/log.</filename><replaceable>function-name</replaceable><filename>.</filename><replaceable>pid</replaceable> @@ -1773,7 +1849,7 @@ things exported or listed in its whitelist to ensure that the build environment is reproducible and consistent. You can prevent this "cleaning" by setting the - <link linkend='var-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link> + <link linkend='var-bb-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link> variable. </note> Consequently, if you do want something to get passed into the @@ -1783,15 +1859,15 @@ Tell BitBake to load what you want from the environment into the datastore. You can do so through the - <link linkend='var-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link> + <link linkend='var-bb-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link> and - <link linkend='var-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link> + <link linkend='var-bb-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link> variables. For example, assume you want to prevent the build system from accessing your <filename>$HOME/.ccache</filename> directory. The following command "whitelists" the environment variable - <filename>CCACHE_DIR</filename> causing BitBack to allow that + <filename>CCACHE_DIR</filename> causing BitBake to allow that variable into the datastore: <literallayout class='monospaced'> export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR" @@ -1822,9 +1898,9 @@ <para> Sometimes, it is useful to be able to obtain information from the original execution environment. - Bitbake saves a copy of the original environment into + BitBake saves a copy of the original environment into a special variable named - <link linkend='var-BB_ORIGENV'><filename>BB_ORIGENV</filename></link>. + <link linkend='var-bb-BB_ORIGENV'><filename>BB_ORIGENV</filename></link>. </para> <para> @@ -1883,7 +1959,7 @@ <listitem><para><emphasis><filename>[depends]</filename>:</emphasis> Controls inter-task dependencies. See the - <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> + <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> variable and the "<link linkend='inter-task-dependencies'>Inter-Task Dependencies</link>" section for more information. @@ -1891,7 +1967,7 @@ <listitem><para><emphasis><filename>[deptask]</filename>:</emphasis> Controls task build-time dependencies. See the - <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> + <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> variable and the "<link linkend='build-dependencies'>Build Dependencies</link>" section for more information. @@ -1937,7 +2013,7 @@ of cores but certain tasks need to be rate-limited due to various kinds of resource constraints (e.g. to avoid network throttling). <filename>number_threads</filename> works similarly to the - <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> + <link linkend='var-bb-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> variable but is task-specific.</para> <para>Set the value globally. @@ -1971,9 +2047,9 @@ <listitem><para><emphasis><filename>[rdepends]</filename>:</emphasis> Controls inter-task runtime dependencies. See the - <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> + <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> variable, the - <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> + <link linkend='var-bb-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> variable, and the "<link linkend='inter-task-dependencies'>Inter-Task Dependencies</link>" section for more information. @@ -1981,9 +2057,9 @@ <listitem><para><emphasis><filename>[rdeptask]</filename>:</emphasis> Controls task runtime dependencies. See the - <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> + <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> variable, the - <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> + <link linkend='var-bb-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> variable, and the "<link linkend='runtime-dependencies'>Runtime Dependencies</link>" section for more information. @@ -1996,9 +2072,9 @@ <listitem><para><emphasis><filename>[recrdeptask]</filename>:</emphasis> Controls task recursive runtime dependencies. See the - <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> + <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> variable, the - <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> + <link linkend='var-bb-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> variable, and the "<link linkend='recursive-dependencies'>Recursive Dependencies</link>" section for more information. @@ -2127,7 +2203,7 @@ Any given datastore only has one such event executed against it, however. If - <link linkende='var-BB_INVALIDCONF'><filename>BB_INVALIDCONF</filename></link> + <link linkende='var-bb-BB_INVALIDCONF'><filename>BB_INVALIDCONF</filename></link> is set in the datastore by the event handler, the configuration is reparsed and a new event triggered, allowing the metadata to update configuration. @@ -2256,17 +2332,17 @@ from a single recipe file multiple incarnations of that recipe file where all incarnations are buildable. These features are enabled through the - <link linkend='var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link> + <link linkend='var-bb-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link> and - <link linkend='var-BBVERSIONS'><filename>BBVERSIONS</filename></link> + <link linkend='var-bb-BBVERSIONS'><filename>BBVERSIONS</filename></link> variables. <note> The mechanism for this class extension is extremely specific to the implementation. Usually, the recipe's - <link linkend='var-PROVIDES'><filename>PROVIDES</filename></link>, - <link linkend='var-PN'><filename>PN</filename></link>, and - <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> + <link linkend='var-bb-PROVIDES'><filename>PROVIDES</filename></link>, + <link linkend='var-bb-PN'><filename>PN</filename></link>, and + <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> variables would need to be modified by the extension class. For specific examples, see the OE-Core <filename>native</filename>, <filename>nativesdk</filename>, @@ -2287,7 +2363,7 @@ project from a single recipe file. You can also specify conditional metadata (using the - <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link> + <link linkend='var-bb-OVERRIDES'><filename>OVERRIDES</filename></link> mechanism) for a single version, or an optionally named range of versions. Here is an example: <literallayout class='monospaced'> @@ -2306,7 +2382,7 @@ into overrides, but it is also made available for the metadata to use in the variable that defines the base recipe versions for use in <filename>file://</filename> search paths - (<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>). + (<link linkend='var-bb-FILESPATH'><filename>FILESPATH</filename></link>). </para></listitem> </itemizedlist> </para> @@ -2408,7 +2484,7 @@ <para> BitBake uses the - <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> + <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> variable to manage build time dependencies. The <filename>[deptask]</filename> varflag for tasks signifies the task of each @@ -2429,9 +2505,9 @@ <para> BitBake uses the - <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>, - <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>, and - <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> + <link linkend='var-bb-PACKAGES'><filename>PACKAGES</filename></link>, + <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link>, and + <link linkend='var-bb-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> variables to manage runtime dependencies. </para> @@ -2450,6 +2526,9 @@ In the previous example, the <filename>do_packagedata</filename> task of each item in <filename>RDEPENDS</filename> must have completed before <filename>do_package_qa</filename> can execute. + Although <filename>RDEPENDS</filename> contains entries from the + runtime dependency namespace, BitBake knows how to map them back + to the build-time dependency namespace, in which the tasks are defined. </para> </section> @@ -2486,15 +2565,17 @@ </para> <para> - You might want to not only have BitBake look for - dependencies of those tasks, but also have BitBake look - for build-time and runtime dependencies of the dependent - tasks as well. - If that is the case, you need to reference the task name - itself in the task list: + BitBake allows a task to recursively depend on itself by + referencing itself in the task list: <literallayout class='monospaced'> do_a[recrdeptask] = "do_a do_b" </literallayout> + In the same way as before, this means that the <filename>do_a</filename> + and <filename>do_b</filename> tasks of the current recipe and all + recipes reachable (by way of dependencies) from the recipe + must run before the <filename>do_a</filename> task can run. In this + case BitBake will ignore the current recipe's <filename>do_a</filename> + task circular dependency on itself. </para> </section> @@ -2543,7 +2624,7 @@ <para> It is often necessary to access variables in the BitBake datastore using Python functions. - The Bitbake datastore has an API that allows you this + The BitBake datastore has an API that allows you this access. Here is a list of available operations: </para> @@ -2686,7 +2767,7 @@ <para> These checksums are stored in - <link linkend='var-STAMP'><filename>STAMP</filename></link>. + <link linkend='var-bb-STAMP'><filename>STAMP</filename></link>. You can examine the checksums using the following BitBake command: <literallayout class='monospaced'> $ bitbake-dumpsigs @@ -2708,44 +2789,44 @@ The following list describes related variables: <itemizedlist> <listitem><para> - <link linkend='var-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></link>: + <link linkend='var-bb-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></link>: 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. </para></listitem> <listitem><para> - <link linkend='var-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></link>: + <link linkend='var-bb-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></link>: Specifies a function BitBake calls that determines whether BitBake requires a setscene dependency to be met. </para></listitem> <listitem><para> - <link linkend='var-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></link>: + <link linkend='var-bb-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></link>: Specifies a function to call that verifies the list of planned task execution before the main task execution happens. </para></listitem> <listitem><para> - <link linkend='var-BB_STAMP_POLICY'><filename>BB_STAMP_POLICY</filename></link>: + <link linkend='var-bb-BB_STAMP_POLICY'><filename>BB_STAMP_POLICY</filename></link>: Defines the mode for comparing timestamps of stamp files. </para></listitem> <listitem><para> - <link linkend='var-BB_STAMP_WHITELIST'><filename>BB_STAMP_WHITELIST</filename></link>: + <link linkend='var-bb-BB_STAMP_WHITELIST'><filename>BB_STAMP_WHITELIST</filename></link>: Lists stamp files that are looked at when the stamp policy is "whitelist". </para></listitem> <listitem><para> - <link linkend='var-BB_TASKHASH'><filename>BB_TASKHASH</filename></link>: + <link linkend='var-bb-BB_TASKHASH'><filename>BB_TASKHASH</filename></link>: Within an executing task, this variable holds the hash of the task as returned by the currently enabled signature generator. </para></listitem> <listitem><para> - <link linkend='var-STAMP'><filename>STAMP</filename></link>: + <link linkend='var-bb-STAMP'><filename>STAMP</filename></link>: The base path to create stamp files. </para></listitem> <listitem><para> - <link linkend='var-STAMPCLEAN'><filename>STAMPCLEAN</filename></link>: + <link linkend='var-bb-STAMPCLEAN'><filename>STAMPCLEAN</filename></link>: Again, the base path to create stamp files but can use wildcards for matching a range of files for clean operations. </para></listitem> diff --git a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml index a84b2bc9..c4bd1f25 100644 --- a/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml +++ b/external/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml @@ -3,7 +3,7 @@ [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > <!-- Dummy chapter --> -<chapter id='ref-variables-glos'> +<chapter id='ref-bb-variables-glos'> <title>Variables Glossary</title> @@ -34,29 +34,29 @@ </itemizedlist> </note> -<glossary id='ref-variables-glossary'> +<glossary id='ref-bb-variables-glossary'> <para> - <link linkend='var-ASSUME_PROVIDED'>A</link> - <link linkend='var-B'>B</link> - <link linkend='var-CACHE'>C</link> - <link linkend='var-DEFAULT_PREFERENCE'>D</link> - <link linkend='var-EXCLUDE_FROM_WORLD'>E</link> - <link linkend='var-FAKEROOT'>F</link> - <link linkend='var-GITDIR'>G</link> - <link linkend='var-HGDIR'>H</link> -<!-- <link linkend='var-ICECC_DISABLED'>I</link> --> + <link linkend='var-bb-ASSUME_PROVIDED'>A</link> + <link linkend='var-bb-B'>B</link> + <link linkend='var-bb-CACHE'>C</link> + <link linkend='var-bb-DEFAULT_PREFERENCE'>D</link> + <link linkend='var-bb-EXCLUDE_FROM_WORLD'>E</link> + <link linkend='var-bb-FAKEROOT'>F</link> + <link linkend='var-bb-GITDIR'>G</link> + <link linkend='var-bb-HGDIR'>H</link> + <link linkend='var-bb-INHERIT'>I</link> <!-- <link linkend='var-glossary-j'>J</link> --> <!-- <link linkend='var-KARCH'>K</link> --> - <link linkend='var-LAYERDEPENDS'>L</link> - <link linkend='var-MIRRORS'>M</link> + <link linkend='var-bb-LAYERDEPENDS'>L</link> + <link linkend='var-bb-MIRRORS'>M</link> <!-- <link linkend='var-glossary-n'>N</link> --> - <link linkend='var-OVERRIDES'>O</link> - <link linkend='var-P4DIR'>P</link> + <link linkend='var-bb-OVERRIDES'>O</link> + <link linkend='var-bb-P4DIR'>P</link> <!-- <link linkend='var-QMAKE_PROFILES'>Q</link> --> - <link linkend='var-RDEPENDS'>R</link> - <link linkend='var-SECTION'>S</link> - <link linkend='var-T'>T</link> + <link linkend='var-bb-RDEPENDS'>R</link> + <link linkend='var-bb-SECTION'>S</link> + <link linkend='var-bb-T'>T</link> <!-- <link linkend='var-UBOOT_CONFIG'>U</link> --> <!-- <link linkend='var-glossary-v'>V</link> --> <!-- <link linkend='var-WARN_QA'>W</link> --> @@ -65,13 +65,13 @@ <!-- <link linkend='var-glossary-z'>Z</link>--> </para> - <glossdiv id='var-glossary-a'><title>A</title> + <glossdiv id='var-bb-glossary-a'><title>A</title> - <glossentry id='var-ASSUME_PROVIDED'><glossterm>ASSUME_PROVIDED</glossterm> + <glossentry id='var-bb-ASSUME_PROVIDED'><glossterm>ASSUME_PROVIDED</glossterm> <glossdef> <para> Lists recipe names - (<link linkend='var-PN'><filename>PN</filename></link> + (<link linkend='var-bb-PN'><filename>PN</filename></link> values) BitBake does not attempt to build. Instead, BitBake assumes these recipes have already been built. @@ -91,9 +91,9 @@ </glossdiv> - <glossdiv id='var-glossary-b'><title>B</title> + <glossdiv id='var-bb-glossary-b'><title>B</title> - <glossentry id='var-B'><glossterm>B</glossterm> + <glossentry id='var-bb-B'><glossterm>B</glossterm> <glossdef> <para> The directory in which BitBake executes functions @@ -102,7 +102,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_ALLOWED_NETWORKS'><glossterm>BB_ALLOWED_NETWORKS</glossterm> + <glossentry id='var-bb-BB_ALLOWED_NETWORKS'><glossterm>BB_ALLOWED_NETWORKS</glossterm> <glossdef> <para> Specifies a space-delimited list of hosts that the fetcher @@ -111,7 +111,7 @@ <itemizedlist> <listitem><para> This host list is only used if - <link linkend='var-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></link> + <link linkend='var-bb-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></link> is either not set or set to "0". </para></listitem> <listitem><para> @@ -151,13 +151,13 @@ </itemizedlist> Using <filename>BB_ALLOWED_NETWORKS</filename> in conjunction with - <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link> + <link linkend='var-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link> is very useful. Adding the host you want to use to <filename>PREMIRRORS</filename> results in the source code being fetched from an allowed location and avoids raising an error when a host that is not allowed is in a - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link> statement. This is because the fetcher does not attempt to use the host listed in <filename>SRC_URI</filename> after a @@ -167,7 +167,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_CONSOLELOG'><glossterm>BB_CONSOLELOG</glossterm> + <glossentry id='var-bb-BB_CONSOLELOG'><glossterm>BB_CONSOLELOG</glossterm> <glossdef> <para> Specifies the path to a log file into which BitBake's user @@ -176,7 +176,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_CURRENTTASK'><glossterm>BB_CURRENTTASK</glossterm> + <glossentry id='var-bb-BB_CURRENTTASK'><glossterm>BB_CURRENTTASK</glossterm> <glossdef> <para> Contains the name of the currently running task. @@ -186,7 +186,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_DANGLINGAPPENDS_WARNONLY'><glossterm>BB_DANGLINGAPPENDS_WARNONLY</glossterm> + <glossentry id='var-bb-BB_DANGLINGAPPENDS_WARNONLY'><glossterm>BB_DANGLINGAPPENDS_WARNONLY</glossterm> <glossdef> <para> Defines how BitBake handles situations where an append @@ -208,7 +208,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_DEFAULT_TASK'><glossterm>BB_DEFAULT_TASK</glossterm> + <glossentry id='var-bb-BB_DEFAULT_TASK'><glossterm>BB_DEFAULT_TASK</glossterm> <glossdef> <para> The default task to use when none is specified (e.g. @@ -219,7 +219,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_DISKMON_DIRS'><glossterm>BB_DISKMON_DIRS</glossterm> + <glossentry id='var-bb-BB_DISKMON_DIRS'><glossterm>BB_DISKMON_DIRS</glossterm> <glossdef> <para> Monitors disk space and available inodes during the build @@ -245,7 +245,7 @@ build when a threshold is broken. Subsequent warnings are issued as defined by the - <link linkend='var-BB_DISKMON_WARNINTERVAL'>BB_DISKMON_WARNINTERVAL</link> variable, + <link linkend='var-bb-BB_DISKMON_WARNINTERVAL'>BB_DISKMON_WARNINTERVAL</link> variable, which must be defined. <dir> is: @@ -275,7 +275,7 @@ BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K" </literallayout> The first example works only if you also set - the <link linkend='var-BB_DISKMON_WARNINTERVAL'><filename>BB_DISKMON_WARNINTERVAL</filename></link> variable. + the <link linkend='var-bb-BB_DISKMON_WARNINTERVAL'><filename>BB_DISKMON_WARNINTERVAL</filename></link> variable. This example causes the build system to immediately abort when either the disk space in <filename>${TMPDIR}</filename> drops below 1 Gbyte or the available free inodes drops below @@ -309,7 +309,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_DISKMON_WARNINTERVAL'><glossterm>BB_DISKMON_WARNINTERVAL</glossterm> + <glossentry id='var-bb-BB_DISKMON_WARNINTERVAL'><glossterm>BB_DISKMON_WARNINTERVAL</glossterm> <glossdef> <para> Defines the disk space and free inode warning intervals. @@ -319,7 +319,7 @@ If you are going to use the <filename>BB_DISKMON_WARNINTERVAL</filename> variable, you must also use the - <link linkend='var-BB_DISKMON_DIRS'><filename>BB_DISKMON_DIRS</filename></link> variable + <link linkend='var-bb-BB_DISKMON_DIRS'><filename>BB_DISKMON_DIRS</filename></link> variable and define its action as "WARN". During the build, subsequent warnings are issued each time disk space or number of free inodes further reduces by @@ -374,7 +374,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_ENV_WHITELIST'><glossterm>BB_ENV_WHITELIST</glossterm> + <glossentry id='var-bb-BB_ENV_WHITELIST'><glossterm>BB_ENV_WHITELIST</glossterm> <glossdef> <para> Specifies the internal whitelist of variables to allow @@ -382,11 +382,11 @@ datastore. If the value of this variable is not specified (which is the default), the following list is used: - <link linkend='var-BBPATH'><filename>BBPATH</filename></link>, - <link linkend='var-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link>, - <link linkend='var-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link>, + <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link>, + <link linkend='var-bb-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link>, + <link linkend='var-bb-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link>, and - <link linkend='var-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link>. + <link linkend='var-bb-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link>. <note> You must set this variable in the external environment in order for it to work. @@ -395,7 +395,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_ENV_EXTRAWHITE'><glossterm>BB_ENV_EXTRAWHITE</glossterm> + <glossentry id='var-bb-BB_ENV_EXTRAWHITE'><glossterm>BB_ENV_EXTRAWHITE</glossterm> <glossdef> <para> Specifies an additional set of variables to allow through @@ -403,7 +403,7 @@ datastore. This list of variables are on top of the internal list set in - <link linkend='var-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link>. + <link linkend='var-bb-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link>. <note> You must set this variable in the external environment in order for it to work. @@ -412,22 +412,22 @@ </glossdef> </glossentry> - <glossentry id='var-BB_FETCH_PREMIRRORONLY'><glossterm>BB_FETCH_PREMIRRORONLY</glossterm> + <glossentry id='var-bb-BB_FETCH_PREMIRRORONLY'><glossterm>BB_FETCH_PREMIRRORONLY</glossterm> <glossdef> <para> When set to "1", causes BitBake's fetcher module to only search - <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link> + <link linkend='var-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link> for files. BitBake will not search the main - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link> + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link> or - <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>. + <link linkend='var-bb-MIRRORS'><filename>MIRRORS</filename></link>. </para> </glossdef> </glossentry> - <glossentry id='var-BB_FILENAME'><glossterm>BB_FILENAME</glossterm> + <glossentry id='var-bb-BB_FILENAME'><glossterm>BB_FILENAME</glossterm> <glossdef> <para> Contains the filename of the recipe that owns the currently @@ -440,12 +440,12 @@ </glossdef> </glossentry> - <glossentry id='var-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm> + <glossentry id='var-bb-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm> <glossdef> <para> Causes tarballs of the Git repositories, including the Git metadata, to be placed in the - <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link> + <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> directory. Anyone wishing to create a source mirror would want to enable this variable. @@ -461,7 +461,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_HASHCONFIG_WHITELIST'><glossterm>BB_HASHCONFIG_WHITELIST</glossterm> + <glossentry id='var-bb-BB_HASHCONFIG_WHITELIST'><glossterm>BB_HASHCONFIG_WHITELIST</glossterm> <glossdef> <para> Lists variables that are excluded from base configuration @@ -485,7 +485,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_HASHBASE_WHITELIST'><glossterm>BB_HASHBASE_WHITELIST</glossterm> + <glossentry id='var-bb-BB_HASHBASE_WHITELIST'><glossterm>BB_HASHBASE_WHITELIST</glossterm> <glossdef> <para> Lists variables that are excluded from checksum and @@ -500,7 +500,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_HASHCHECK_FUNCTION'><glossterm>BB_HASHCHECK_FUNCTION</glossterm> + <glossentry id='var-bb-BB_HASHCHECK_FUNCTION'><glossterm>BB_HASHCHECK_FUNCTION</glossterm> <glossdef> <para> Specifies the name of the function to call during the @@ -524,7 +524,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_INVALIDCONF'><glossterm>BB_INVALIDCONF</glossterm> + <glossentry id='var-bb-BB_INVALIDCONF'><glossterm>BB_INVALIDCONF</glossterm> <glossdef> <para> Used in combination with the @@ -539,11 +539,22 @@ </glossdef> </glossentry> - <glossentry id='var-BB_LOGFMT'><glossterm>BB_LOGFMT</glossterm> + <glossentry id='var-bb-BB_LOGCONFIG'><glossterm>BB_LOGCONFIG</glossterm> + <glossdef> + <para> + Specifies the name of a config file that contains the user + logging configuration. See + <link linkend="logging">Logging</link> for additional + information + </para> + </glossdef> + </glossentry> + + <glossentry id='var-bb-BB_LOGFMT'><glossterm>BB_LOGFMT</glossterm> <glossdef> <para> Specifies the name of the log files saved into - <filename>${</filename><link linkend='var-T'><filename>T</filename></link><filename>}</filename>. + <filename>${</filename><link linkend='var-bb-T'><filename>T</filename></link><filename>}</filename>. By default, the <filename>BB_LOGFMT</filename> variable is undefined and the log file names get created using the following form: @@ -556,7 +567,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_NICE_LEVEL'><glossterm>BB_NICE_LEVEL</glossterm> + <glossentry id='var-bb-BB_NICE_LEVEL'><glossterm>BB_NICE_LEVEL</glossterm> <glossdef> <para> Allows BitBake to run at a specific priority @@ -564,13 +575,13 @@ System permissions usually mean that BitBake can reduce its priority but not raise it again. See - <link linkend='var-BB_TASK_NICE_LEVEL'><filename>BB_TASK_NICE_LEVEL</filename></link> + <link linkend='var-bb-BB_TASK_NICE_LEVEL'><filename>BB_TASK_NICE_LEVEL</filename></link> for additional information. </para> </glossdef> </glossentry> - <glossentry id='var-BB_NO_NETWORK'><glossterm>BB_NO_NETWORK</glossterm> + <glossentry id='var-bb-BB_NO_NETWORK'><glossterm>BB_NO_NETWORK</glossterm> <glossdef> <para> Disables network access in the BitBake fetcher modules. @@ -587,7 +598,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm> + <glossentry id='var-bb-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm> <glossdef> <para> The maximum number of tasks BitBake should run in parallel @@ -599,7 +610,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_NUMBER_PARSE_THREADS'><glossterm>BB_NUMBER_PARSE_THREADS</glossterm> + <glossentry id='var-bb-BB_NUMBER_PARSE_THREADS'><glossterm>BB_NUMBER_PARSE_THREADS</glossterm> <glossdef> <para> Sets the number of threads BitBake uses when parsing. @@ -609,7 +620,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_ORIGENV'><glossterm>BB_ORIGENV</glossterm> + <glossentry id='var-bb-BB_ORIGENV'><glossterm>BB_ORIGENV</glossterm> <glossdef> <para> Contains a copy of the original external environment in @@ -625,7 +636,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_PRESERVE_ENV'><glossterm>BB_PRESERVE_ENV</glossterm> + <glossentry id='var-bb-BB_PRESERVE_ENV'><glossterm>BB_PRESERVE_ENV</glossterm> <glossdef> <para> Disables whitelisting and instead allows all variables @@ -639,12 +650,12 @@ </glossdef> </glossentry> - <glossentry id='var-BB_RUNFMT'><glossterm>BB_RUNFMT</glossterm> + <glossentry id='var-bb-BB_RUNFMT'><glossterm>BB_RUNFMT</glossterm> <glossdef> <para> Specifies the name of the executable script files (i.e. run files) saved into - <filename>${</filename><link linkend='var-T'><filename>T</filename></link><filename>}</filename>. + <filename>${</filename><link linkend='var-bb-T'><filename>T</filename></link><filename>}</filename>. By default, the <filename>BB_RUNFMT</filename> variable is undefined and the run file names get created using the following form: @@ -657,7 +668,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_RUNTASK'><glossterm>BB_RUNTASK</glossterm> + <glossentry id='var-bb-BB_RUNTASK'><glossterm>BB_RUNTASK</glossterm> <glossdef> <para> Contains the name of the currently executing task. @@ -669,7 +680,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_SCHEDULER'><glossterm>BB_SCHEDULER</glossterm> + <glossentry id='var-bb-BB_SCHEDULER'><glossterm>BB_SCHEDULER</glossterm> <glossdef> <para> Selects the name of the scheduler to use for the @@ -695,7 +706,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_SCHEDULERS'><glossterm>BB_SCHEDULERS</glossterm> + <glossentry id='var-bb-BB_SCHEDULERS'><glossterm>BB_SCHEDULERS</glossterm> <glossdef> <para> Defines custom schedulers to import. @@ -705,13 +716,13 @@ <para> For information how to select a scheduler, see the - <link linkend='var-BB_SCHEDULER'><filename>BB_SCHEDULER</filename></link> + <link linkend='var-bb-BB_SCHEDULER'><filename>BB_SCHEDULER</filename></link> variable. </para> </glossdef> </glossentry> - <glossentry id='var-BB_SETSCENE_DEPVALID'><glossterm>BB_SETSCENE_DEPVALID</glossterm> + <glossentry id='var-bb-BB_SETSCENE_DEPVALID'><glossterm>BB_SETSCENE_DEPVALID</glossterm> <glossdef> <para> Specifies a function BitBake calls that determines @@ -731,7 +742,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_SETSCENE_VERIFY_FUNCTION2'><glossterm>BB_SETSCENE_VERIFY_FUNCTION2</glossterm> + <glossentry id='var-bb-BB_SETSCENE_VERIFY_FUNCTION2'><glossterm>BB_SETSCENE_VERIFY_FUNCTION2</glossterm> <glossdef> <para> Specifies a function to call that verifies the list of @@ -752,7 +763,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_SIGNATURE_EXCLUDE_FLAGS'><glossterm>BB_SIGNATURE_EXCLUDE_FLAGS</glossterm> + <glossentry id='var-bb-BB_SIGNATURE_EXCLUDE_FLAGS'><glossterm>BB_SIGNATURE_EXCLUDE_FLAGS</glossterm> <glossdef> <para> Lists variable flags (varflags) @@ -771,7 +782,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_SIGNATURE_HANDLER'><glossterm>BB_SIGNATURE_HANDLER</glossterm> + <glossentry id='var-bb-BB_SIGNATURE_HANDLER'><glossterm>BB_SIGNATURE_HANDLER</glossterm> <glossdef> <para> Defines the name of the signature handler BitBake uses. @@ -790,7 +801,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_SRCREV_POLICY'><glossterm>BB_SRCREV_POLICY</glossterm> + <glossentry id='var-bb-BB_SRCREV_POLICY'><glossterm>BB_SRCREV_POLICY</glossterm> <glossdef> <para> Defines the behavior of the fetcher when it interacts with @@ -817,7 +828,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_STAMP_POLICY'><glossterm>BB_STAMP_POLICY</glossterm> + <glossentry id='var-bb-BB_STAMP_POLICY'><glossterm>BB_STAMP_POLICY</glossterm> <glossdef> <para> Defines the mode used for how timestamps of stamp files @@ -836,7 +847,7 @@ <listitem><para><emphasis>whitelist</emphasis> - Identical to "full" mode except timestamp comparisons are made for recipes listed in the - <link linkend='var-BB_STAMP_WHITELIST'><filename>BB_STAMP_WHITELIST</filename></link> + <link linkend='var-bb-BB_STAMP_WHITELIST'><filename>BB_STAMP_WHITELIST</filename></link> variable. </para></listitem> </itemizedlist> @@ -848,19 +859,19 @@ </glossdef> </glossentry> - <glossentry id='var-BB_STAMP_WHITELIST'><glossterm>BB_STAMP_WHITELIST</glossterm> + <glossentry id='var-bb-BB_STAMP_WHITELIST'><glossterm>BB_STAMP_WHITELIST</glossterm> <glossdef> <para> Lists files whose stamp file timestamps are compared when the stamp policy mode is set to "whitelist". For information on stamp policies, see the - <link linkend='var-BB_STAMP_POLICY'><filename>BB_STAMP_POLICY</filename></link> + <link linkend='var-bb-BB_STAMP_POLICY'><filename>BB_STAMP_POLICY</filename></link> variable. </para> </glossdef> </glossentry> - <glossentry id='var-BB_STRICT_CHECKSUM'><glossterm>BB_STRICT_CHECKSUM</glossterm> + <glossentry id='var-bb-BB_STRICT_CHECKSUM'><glossterm>BB_STRICT_CHECKSUM</glossterm> <glossdef> <para> Sets a more strict checksum mechanism for non-local URLs. @@ -871,7 +882,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_TASK_IONICE_LEVEL'><glossterm>BB_TASK_IONICE_LEVEL</glossterm> + <glossentry id='var-bb-BB_TASK_IONICE_LEVEL'><glossterm>BB_TASK_IONICE_LEVEL</glossterm> <glossdef> <para> Allows adjustment of a task's Input/Output priority. @@ -882,7 +893,7 @@ variable to adjust the I/O priority of these tasks. <note> This variable works similarly to the - <link linkend='var-BB_TASK_NICE_LEVEL'><filename>BB_TASK_NICE_LEVEL</filename></link> + <link linkend='var-bb-BB_TASK_NICE_LEVEL'><filename>BB_TASK_NICE_LEVEL</filename></link> variable except with a task's I/O priorities. </note> </para> @@ -921,7 +932,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_TASK_NICE_LEVEL'><glossterm>BB_TASK_NICE_LEVEL</glossterm> + <glossentry id='var-bb-BB_TASK_NICE_LEVEL'><glossterm>BB_TASK_NICE_LEVEL</glossterm> <glossdef> <para> Allows specific tasks to change their priority @@ -940,7 +951,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_TASKHASH'><glossterm>BB_TASKHASH</glossterm> + <glossentry id='var-bb-BB_TASKHASH'><glossterm>BB_TASKHASH</glossterm> <glossdef> <para> Within an executing task, this variable holds the hash @@ -950,7 +961,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_VERBOSE_LOGS'><glossterm>BB_VERBOSE_LOGS</glossterm> + <glossentry id='var-bb-BB_VERBOSE_LOGS'><glossterm>BB_VERBOSE_LOGS</glossterm> <glossdef> <para> Controls how verbose BitBake is during builds. @@ -960,7 +971,7 @@ </glossdef> </glossentry> - <glossentry id='var-BB_WORKERCONTEXT'><glossterm>BB_WORKERCONTEXT</glossterm> + <glossentry id='var-bb-BB_WORKERCONTEXT'><glossterm>BB_WORKERCONTEXT</glossterm> <glossdef> <para> Specifies if the current context is executing a task. @@ -973,7 +984,7 @@ </glossentry> - <glossentry id='var-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm> + <glossentry id='var-bb-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm> <glossdef> <para> Allows you to extend a recipe so that it builds variants @@ -1009,7 +1020,7 @@ <filename>_class-native</filename>. For example, to generate a native version of a recipe, a - <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> + <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> on "foo" is rewritten to a <filename>DEPENDS</filename> on "foo-native". </para> @@ -1028,7 +1039,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBDEBUG'><glossterm>BBDEBUG</glossterm> + <glossentry id='var-bb-BBDEBUG'><glossterm>BBDEBUG</glossterm> <glossdef> <para> Sets the BitBake debug output level to a specific value @@ -1042,7 +1053,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm> + <glossentry id='var-bb-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm> <glossdef> <para>Lists the names of configured layers. These names are used to find the other <filename>BBFILE_*</filename> @@ -1053,10 +1064,10 @@ </glossdef> </glossentry> - <glossentry id='var-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm> + <glossentry id='var-bb-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm> <glossdef> <para>Variable that expands to match files from - <link linkend='var-BBFILES'><filename>BBFILES</filename></link> + <link linkend='var-bb-BBFILES'><filename>BBFILES</filename></link> in a particular layer. This variable is used in the <filename>conf/layer.conf</filename> file and must be suffixed with the name of the specific layer (e.g. @@ -1064,7 +1075,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm> + <glossentry id='var-bb-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm> <glossdef> <para>Assigns the priority for recipe files in each layer.</para> <para>This variable is useful in situations where the same recipe appears in @@ -1074,7 +1085,7 @@ letting you control the precedence for the multiple layers. The precedence established through this variable stands regardless of a recipe's version - (<link linkend='var-PV'><filename>PV</filename></link> variable). + (<link linkend='var-bb-PV'><filename>PV</filename></link> variable). For example, a layer that has a recipe with a higher <filename>PV</filename> value but for which the <filename>BBFILE_PRIORITY</filename> is set to have a lower precedence still has a lower precedence.</para> @@ -1083,7 +1094,7 @@ For example, the value 6 has a higher precedence than the value 5. If not specified, the <filename>BBFILE_PRIORITY</filename> variable is set based on layer dependencies (see the - <filename><link linkend='var-LAYERDEPENDS'>LAYERDEPENDS</link></filename> variable for + <filename><link linkend='var-bb-LAYERDEPENDS'>LAYERDEPENDS</link></filename> variable for more information. The default priority, if unspecified for a layer with no dependencies, is the lowest defined priority + 1 @@ -1095,7 +1106,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm> + <glossentry id='var-bb-BBFILES'><glossterm>BBFILES</glossterm> <glossdef> <para> A space-separated list of recipe files BitBake uses to @@ -1113,7 +1124,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBINCLUDED'><glossterm>BBINCLUDED</glossterm> + <glossentry id='var-bb-BBINCLUDED'><glossterm>BBINCLUDED</glossterm> <glossdef> <para> Contains a space-separated list of all of all files that @@ -1123,7 +1134,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm> + <glossentry id='var-bb-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm> <glossdef> <para> If set to a value, enables printing the task log when @@ -1132,11 +1143,11 @@ </glossdef> </glossentry> - <glossentry id='var-BBINCLUDELOGS_LINES'><glossterm>BBINCLUDELOGS_LINES</glossterm> + <glossentry id='var-bb-BBINCLUDELOGS_LINES'><glossterm>BBINCLUDELOGS_LINES</glossterm> <glossdef> <para> If - <link linkend='var-BBINCLUDELOGS'><filename>BBINCLUDELOGS</filename></link> + <link linkend='var-bb-BBINCLUDELOGS'><filename>BBINCLUDELOGS</filename></link> is set, specifies the maximum number of lines from the task log file to print when reporting a failed task. If you do not set <filename>BBINCLUDELOGS_LINES</filename>, @@ -1145,7 +1156,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm> + <glossentry id='var-bb-BBLAYERS'><glossterm>BBLAYERS</glossterm> <glossdef> <para>Lists the layers to enable during the build. This variable is defined in the <filename>bblayers.conf</filename> configuration @@ -1166,7 +1177,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBLAYERS_FETCH_DIR'><glossterm>BBLAYERS_FETCH_DIR</glossterm> + <glossentry id='var-bb-BBLAYERS_FETCH_DIR'><glossterm>BBLAYERS_FETCH_DIR</glossterm> <glossdef> <para> Sets the base location where layers are stored. @@ -1178,7 +1189,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBMASK'><glossterm>BBMASK</glossterm> + <glossentry id='var-bb-BBMASK'><glossterm>BBMASK</glossterm> <glossdef> <para> Prevents BitBake from processing recipes and recipe @@ -1236,7 +1247,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBMULTICONFIG'><glossterm>BBMULTICONFIG</glossterm> + <glossentry id='var-bb-BBMULTICONFIG'><glossterm>BBMULTICONFIG</glossterm> <info> BBMULTICONFIG[doc] = "Enables BitBake to perform multiple configuration builds and lists each separate configuration (multiconfig)." </info> @@ -1275,7 +1286,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm> + <glossentry id='var-bb-BBPATH'><glossterm>BBPATH</glossterm> <glossdef> <para> Used by BitBake to locate class @@ -1302,7 +1313,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBSERVER'><glossterm>BBSERVER</glossterm> + <glossentry id='var-bb-BBSERVER'><glossterm>BBSERVER</glossterm> <glossdef> <para> Points to the server that runs memory-resident BitBake. @@ -1312,7 +1323,7 @@ </glossdef> </glossentry> - <glossentry id='var-BBTARGETS'><glossterm>BBTARGETS</glossterm> + <glossentry id='var-bb-BBTARGETS'><glossterm>BBTARGETS</glossterm> <glossdef> <para> Allows you to use a configuration file to add to the list @@ -1321,14 +1332,14 @@ </glossdef> </glossentry> - <glossentry id='var-BBVERSIONS'><glossterm>BBVERSIONS</glossterm> + <glossentry id='var-bb-BBVERSIONS'><glossterm>BBVERSIONS</glossterm> <glossdef> <para> Allows a single recipe to build multiple versions of a project from a single recipe file. You also able to specify conditional metadata using the - <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link> + <link linkend='var-bb-OVERRIDES'><filename>OVERRIDES</filename></link> mechanism for a single version or for an optionally named range of versions. </para> @@ -1342,7 +1353,7 @@ </glossdef> </glossentry> - <glossentry id='var-BITBAKE_UI'><glossterm>BITBAKE_UI</glossterm> + <glossentry id='var-bb-BITBAKE_UI'><glossterm>BITBAKE_UI</glossterm> <glossdef> <para> Used to specify the UI module to use when running BitBake. @@ -1356,7 +1367,7 @@ </glossdef> </glossentry> - <glossentry id='var-BUILDNAME'><glossterm>BUILDNAME</glossterm> + <glossentry id='var-bb-BUILDNAME'><glossterm>BUILDNAME</glossterm> <glossdef> <para> A name assigned to the build. @@ -1366,7 +1377,7 @@ </glossdef> </glossentry> - <glossentry id='var-BZRDIR'><glossterm>BZRDIR</glossterm> + <glossentry id='var-bb-BZRDIR'><glossterm>BZRDIR</glossterm> <glossdef> <para> The directory in which files checked out of a Bazaar @@ -1377,9 +1388,9 @@ </glossdiv> - <glossdiv id='var-glossary-c'><title>C</title> + <glossdiv id='var-bb-glossary-c'><title>C</title> - <glossentry id='var-CACHE'><glossterm>CACHE</glossterm> + <glossentry id='var-bb-CACHE'><glossterm>CACHE</glossterm> <glossdef> <para> Specifies the directory BitBake uses to store a cache @@ -1389,7 +1400,7 @@ </glossdef> </glossentry> - <glossentry id='var-CVSDIR'><glossterm>CVSDIR</glossterm> + <glossentry id='var-bb-CVSDIR'><glossterm>CVSDIR</glossterm> <glossdef> <para> The directory in which files checked out under the @@ -1400,9 +1411,9 @@ </glossdiv> - <glossdiv id='var-glossary-d'><title>D</title> + <glossdiv id='var-bb-glossary-d'><title>D</title> - <glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm> + <glossentry id='var-bb-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm> <glossdef> <para> Specifies a weak bias for recipe selection priority. @@ -1413,20 +1424,20 @@ piece of software. Using the variable in this way causes the stable version of the recipe to build by default in the absence of - <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename> + <filename><link linkend='var-bb-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename> being used to build the development version. </para> <note> The bias provided by <filename>DEFAULT_PREFERENCE</filename> is weak and is overridden by - <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename> + <filename><link linkend='var-bb-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename> if that variable is different between two layers that contain different versions of the same recipe. </note> </glossdef> </glossentry> - <glossentry id='var-DEPENDS'><glossterm>DEPENDS</glossterm> + <glossentry id='var-bb-DEPENDS'><glossterm>DEPENDS</glossterm> <glossdef> <para> Lists a recipe's build-time dependencies @@ -1451,13 +1462,13 @@ <para> For information on runtime dependencies, see the - <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> + <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> variable. </para> </glossdef> </glossentry> - <glossentry id='var-DESCRIPTION'><glossterm>DESCRIPTION</glossterm> + <glossentry id='var-bb-DESCRIPTION'><glossterm>DESCRIPTION</glossterm> <glossdef> <para> A long description for the recipe. @@ -1465,7 +1476,7 @@ </glossdef> </glossentry> - <glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm> + <glossentry id='var-bb-DL_DIR'><glossterm>DL_DIR</glossterm> <glossdef> <para> The central download directory used by the build process to @@ -1474,7 +1485,7 @@ suitable for mirroring for everything except Git repositories. If you want tarballs of Git repositories, use the - <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link> + <link linkend='var-bb-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link> variable. </para> </glossdef> @@ -1482,9 +1493,9 @@ </glossentry> </glossdiv> - <glossdiv id='var-glossary-e'><title>E</title> + <glossdiv id='var-bb-glossary-e'><title>E</title> - <glossentry id='var-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm> + <glossentry id='var-bb-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm> <glossdef> <para> Directs BitBake to exclude a recipe from world builds (i.e. @@ -1512,9 +1523,9 @@ </glossdiv> - <glossdiv id='var-glossary-f'><title>F</title> + <glossdiv id='var-bb-glossary-f'><title>F</title> - <glossentry id='var-FAKEROOT'><glossterm>FAKEROOT</glossterm> + <glossentry id='var-bb-FAKEROOT'><glossterm>FAKEROOT</glossterm> <glossdef> <para> Contains the command to use when running a shell script @@ -1527,19 +1538,19 @@ </glossdef> </glossentry> - <glossentry id='var-FAKEROOTBASEENV'><glossterm>FAKEROOTBASEENV</glossterm> + <glossentry id='var-bb-FAKEROOTBASEENV'><glossterm>FAKEROOTBASEENV</glossterm> <glossdef> <para> Lists environment variables to set when executing the command defined by - <link linkend='var-FAKEROOTCMD'><filename>FAKEROOTCMD</filename></link> + <link linkend='var-bb-FAKEROOTCMD'><filename>FAKEROOTCMD</filename></link> that starts the bitbake-worker process in the fakeroot environment. </para> </glossdef> </glossentry> - <glossentry id='var-FAKEROOTCMD'><glossterm>FAKEROOTCMD</glossterm> + <glossentry id='var-bb-FAKEROOTCMD'><glossterm>FAKEROOTCMD</glossterm> <glossdef> <para> Contains the command that starts the bitbake-worker @@ -1548,7 +1559,7 @@ </glossdef> </glossentry> - <glossentry id='var-FAKEROOTDIRS'><glossterm>FAKEROOTDIRS</glossterm> + <glossentry id='var-bb-FAKEROOTDIRS'><glossterm>FAKEROOTDIRS</glossterm> <glossdef> <para> Lists directories to create before running a task in @@ -1557,33 +1568,33 @@ </glossdef> </glossentry> - <glossentry id='var-FAKEROOTENV'><glossterm>FAKEROOTENV</glossterm> + <glossentry id='var-bb-FAKEROOTENV'><glossterm>FAKEROOTENV</glossterm> <glossdef> <para> Lists environment variables to set when running a task in the fakeroot environment. For additional information on environment variables and the fakeroot environment, see the - <link linkend='var-FAKEROOTBASEENV'><filename>FAKEROOTBASEENV</filename></link> + <link linkend='var-bb-FAKEROOTBASEENV'><filename>FAKEROOTBASEENV</filename></link> variable. </para> </glossdef> </glossentry> - <glossentry id='var-FAKEROOTNOENV'><glossterm>FAKEROOTNOENV</glossterm> + <glossentry id='var-bb-FAKEROOTNOENV'><glossterm>FAKEROOTNOENV</glossterm> <glossdef> <para> Lists environment variables to set when running a task that is not in the fakeroot environment. For additional information on environment variables and the fakeroot environment, see the - <link linkend='var-FAKEROOTENV'><filename>FAKEROOTENV</filename></link> + <link linkend='var-bb-FAKEROOTENV'><filename>FAKEROOTENV</filename></link> variable. </para> </glossdef> </glossentry> - <glossentry id='var-FETCHCMD'><glossterm>FETCHCMD</glossterm> + <glossentry id='var-bb-FETCHCMD'><glossterm>FETCHCMD</glossterm> <glossdef> <para> Defines the command the BitBake fetcher module @@ -1595,7 +1606,7 @@ </glossdef> </glossentry> - <glossentry id='var-FILE'><glossterm>FILE</glossterm> + <glossentry id='var-bb-FILE'><glossterm>FILE</glossterm> <glossdef> <para> Points at the current file. @@ -1607,7 +1618,7 @@ </glossdef> </glossentry> - <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm> + <glossentry id='var-bb-FILESPATH'><glossterm>FILESPATH</glossterm> <glossdef> <para> Specifies directories BitBake uses when searching for @@ -1625,9 +1636,9 @@ </glossdiv> - <glossdiv id='var-glossary-g'><title>G</title> + <glossdiv id='var-bb-glossary-g'><title>G</title> - <glossentry id='var-GITDIR'><glossterm>GITDIR</glossterm> + <glossentry id='var-bb-GITDIR'><glossterm>GITDIR</glossterm> <glossdef> <para> The directory in which a local copy of a Git repository @@ -1639,9 +1650,9 @@ </glossdiv> - <glossdiv id='var-glossary-h'><title>H</title> + <glossdiv id='var-bb-glossary-h'><title>H</title> - <glossentry id='var-HGDIR'><glossterm>HGDIR</glossterm> + <glossentry id='var-bb-HGDIR'><glossterm>HGDIR</glossterm> <glossdef> <para> The directory in which files checked out of a Mercurial @@ -1650,7 +1661,7 @@ </glossdef> </glossentry> - <glossentry id='var-HOMEPAGE'><glossterm>HOMEPAGE</glossterm> + <glossentry id='var-bb-HOMEPAGE'><glossterm>HOMEPAGE</glossterm> <glossdef> <para>Website where more information about the software the recipe is building can be found.</para> @@ -1659,9 +1670,9 @@ </glossdiv> - <glossdiv id='var-glossary-i'><title>I</title> + <glossdiv id='var-bb-glossary-i'><title>I</title> - <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm> + <glossentry id='var-bb-INHERIT'><glossterm>INHERIT</glossterm> <glossdef> <para> Causes the named class or classes to be inherited globally. @@ -1691,15 +1702,15 @@ </glossdiv> --> - <glossdiv id='var-glossary-l'><title>L</title> + <glossdiv id='var-bb-glossary-l'><title>L</title> - <glossentry id='var-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm> + <glossentry id='var-bb-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm> <glossdef> <para>Lists the layers, separated by spaces, upon which this recipe depends. Optionally, you can specify a specific layer version for a dependency by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3" to be compared against - <link linkend='var-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename> + <link linkend='var-bb-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename> in this case). BitBake produces an error if any dependency is missing or the version numbers do not match exactly (if specified).</para> @@ -1710,7 +1721,7 @@ </glossdef> </glossentry> - <glossentry id='var-LAYERDIR'><glossterm>LAYERDIR</glossterm> + <glossentry id='var-bb-LAYERDIR'><glossterm>LAYERDIR</glossterm> <glossdef> <para>When used inside the <filename>layer.conf</filename> configuration file, this variable provides the path of the current layer. @@ -1719,22 +1730,22 @@ </glossdef> </glossentry> - <glossentry id='var-LAYERDIR_RE'><glossterm>LAYERDIR_RE</glossterm> + <glossentry id='var-bb-LAYERDIR_RE'><glossterm>LAYERDIR_RE</glossterm> <glossdef> <para>When used inside the <filename>layer.conf</filename> configuration file, this variable provides the path of the current layer, escaped for use in a regular expression - (<link linkend='var-BBFILE_PATTERN'><filename>BBFILE_PATTERN</filename></link>). + (<link linkend='var-bb-BBFILE_PATTERN'><filename>BBFILE_PATTERN</filename></link>). This variable is not available outside of <filename>layer.conf</filename> and references are expanded immediately when parsing of the file completes.</para> </glossdef> </glossentry> - <glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm> + <glossentry id='var-bb-LAYERVERSION'><glossterm>LAYERVERSION</glossterm> <glossdef> <para>Optionally specifies the version of a layer as a single number. You can use this variable within - <link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link> + <link linkend='var-bb-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link> for another layer in order to depend on a specific version of the layer.</para> <para> @@ -1744,7 +1755,7 @@ </glossdef> </glossentry> - <glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm> + <glossentry id='var-bb-LICENSE'><glossterm>LICENSE</glossterm> <glossdef> <para> The list of source licenses for the recipe. @@ -1754,9 +1765,9 @@ </glossdiv> - <glossdiv id='var-glossary-m'><title>M</title> + <glossdiv id='var-bb-glossary-m'><title>M</title> - <glossentry id='var-MIRRORS'><glossterm>MIRRORS</glossterm> + <glossentry id='var-bb-MIRRORS'><glossterm>MIRRORS</glossterm> <glossdef> <para> Specifies additional paths from which BitBake gets source code. @@ -1764,14 +1775,14 @@ tries the local download directory. If that location fails, the build system tries locations defined by - <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>, + <link linkend='var-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link>, the upstream source, and then locations specified by <filename>MIRRORS</filename> in that order. </para> </glossdef> </glossentry> - <glossentry id='var-MULTI_PROVIDER_WHITELIST'><glossterm>MULTI_PROVIDER_WHITELIST</glossterm> + <glossentry id='var-bb-MULTI_PROVIDER_WHITELIST'><glossterm>MULTI_PROVIDER_WHITELIST</glossterm> <glossdef> <para> Allows you to suppress BitBake warnings caused when @@ -1780,7 +1791,7 @@ </para> <para> - Bitbake normally issues a warning when building two + BitBake normally issues a warning when building two different recipes where each provides the same output. This scenario is usually something the user does not want. @@ -1804,9 +1815,9 @@ </glossdiv> --> - <glossdiv id='var-glossary-o'><title>O</title> + <glossdiv id='var-bb-glossary-o'><title>O</title> - <glossentry id='var-OVERRIDES'><glossterm>OVERRIDES</glossterm> + <glossentry id='var-bb-OVERRIDES'><glossterm>OVERRIDES</glossterm> <glossdef> <para> BitBake uses <filename>OVERRIDES</filename> to control @@ -1829,9 +1840,9 @@ </glossentry> </glossdiv> - <glossdiv id='var-glossary-p'><title>P</title> + <glossdiv id='var-bb-glossary-p'><title>P</title> - <glossentry id='var-P4DIR'><glossterm>P4DIR</glossterm> + <glossentry id='var-bb-P4DIR'><glossterm>P4DIR</glossterm> <glossdef> <para> The directory in which a local copy of a Perforce depot @@ -1840,14 +1851,14 @@ </glossdef> </glossentry> - <glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm> + <glossentry id='var-bb-PACKAGES'><glossterm>PACKAGES</glossterm> <glossdef> <para>The list of packages the recipe creates. </para> </glossdef> </glossentry> - <glossentry id='var-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm> + <glossentry id='var-bb-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm> <glossdef> <para> A promise that your recipe satisfies runtime dependencies @@ -1856,7 +1867,7 @@ does not actually satisfy the dependencies, it only states that they should be satisfied. For example, if a hard, runtime dependency - (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>) + (<link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link>) of another package is satisfied during the build through the <filename>PACKAGES_DYNAMIC</filename> variable, but a package with the module name is never actually @@ -1865,7 +1876,7 @@ </glossdef> </glossentry> - <glossentry id='var-PE'><glossterm>PE</glossterm> + <glossentry id='var-bb-PE'><glossterm>PE</glossterm> <glossdef> <para> The epoch of the recipe. @@ -1877,7 +1888,7 @@ </glossdef> </glossentry> - <glossentry id='var-PERSISTENT_DIR'><glossterm>PERSISTENT_DIR</glossterm> + <glossentry id='var-bb-PERSISTENT_DIR'><glossterm>PERSISTENT_DIR</glossterm> <glossdef> <para> Specifies the directory BitBake uses to store data that @@ -1889,7 +1900,7 @@ </glossdef> </glossentry> - <glossentry id='var-PF'><glossterm>PF</glossterm> + <glossentry id='var-bb-PF'><glossterm>PF</glossterm> <glossdef> <para> Specifies the recipe or package name and includes all version and revision @@ -1899,27 +1910,27 @@ </glossdef> </glossentry> - <glossentry id='var-PN'><glossterm>PN</glossterm> + <glossentry id='var-bb-PN'><glossterm>PN</glossterm> <glossdef> <para>The recipe name.</para> </glossdef> </glossentry> - <glossentry id='var-PR'><glossterm>PR</glossterm> + <glossentry id='var-bb-PR'><glossterm>PR</glossterm> <glossdef> <para>The revision of the recipe. </para> </glossdef> </glossentry> - <glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm> + <glossentry id='var-bb-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm> <glossdef> <para> Determines which recipe should be given preference when multiple recipes provide the same item. You should always suffix the variable with the name of the provided item, and you should set it to the - <link linkend='var-PN'><filename>PN</filename></link> + <link linkend='var-bb-PN'><filename>PN</filename></link> of the recipe to which you want to give precedence. Some examples: <literallayout class='monospaced'> @@ -1931,14 +1942,14 @@ </glossdef> </glossentry> - <glossentry id='var-PREFERRED_PROVIDERS'><glossterm>PREFERRED_PROVIDERS</glossterm> + <glossentry id='var-bb-PREFERRED_PROVIDERS'><glossterm>PREFERRED_PROVIDERS</glossterm> <glossdef> <para> Determines which recipe should be given preference for cases where multiple recipes provide the same item. Functionally, <filename>PREFERRED_PROVIDERS</filename> is identical to - <link linkend='var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link>. + <link linkend='var-bb-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link>. However, the <filename>PREFERRED_PROVIDERS</filename> variable lets you define preferences for multiple situations using the following form: @@ -1954,15 +1965,15 @@ </glossdef> </glossentry> - <glossentry id='var-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm> + <glossentry id='var-bb-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm> <glossdef> <para> If there are multiple versions of recipes available, this variable determines which recipe should be given preference. You must always suffix the variable with the - <link linkend='var-PN'><filename>PN</filename></link> + <link linkend='var-bb-PN'><filename>PN</filename></link> you want to select, and you should set - <link linkend='var-PV'><filename>PV</filename></link> + <link linkend='var-bb-PV'><filename>PV</filename></link> accordingly for precedence. </para> @@ -1989,7 +2000,7 @@ </glossdef> </glossentry> - <glossentry id='var-PREMIRRORS'><glossterm>PREMIRRORS</glossterm> + <glossentry id='var-bb-PREMIRRORS'><glossterm>PREMIRRORS</glossterm> <glossdef> <para> Specifies additional paths from which BitBake gets source code. @@ -1998,7 +2009,7 @@ If that location fails, the build system tries locations defined by <filename>PREMIRRORS</filename>, the upstream source, and then locations specified by - <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link> + <link linkend='var-bb-MIRRORS'><filename>MIRRORS</filename></link> in that order. </para> @@ -2022,20 +2033,20 @@ </glossdef> </glossentry> - <glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm> + <glossentry id='var-bb-PROVIDES'><glossterm>PROVIDES</glossterm> <glossdef> <para> A list of aliases by which a particular recipe can be known. By default, a recipe's own - <filename><link linkend='var-PN'>PN</link></filename> + <filename><link linkend='var-bb-PN'>PN</link></filename> is implicitly already in its <filename>PROVIDES</filename> list. If a recipe uses <filename>PROVIDES</filename>, the additional aliases are synonyms for the recipe and can be useful satisfying dependencies of other recipes during the build as specified by - <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>. + <filename><link linkend='var-bb-DEPENDS'>DEPENDS</link></filename>. </para> <para> @@ -2059,7 +2070,7 @@ virtual target in <filename>PROVIDES</filename>. Recipes that depend on the functionality in question can include the virtual target in - <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> + <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> to leave the choice of provider open. </para> @@ -2072,11 +2083,11 @@ </glossdef> </glossentry> - <glossentry id='var-PRSERV_HOST'><glossterm>PRSERV_HOST</glossterm> + <glossentry id='var-bb-PRSERV_HOST'><glossterm>PRSERV_HOST</glossterm> <glossdef> <para> The network based - <link linkend='var-PR'><filename>PR</filename></link> + <link linkend='var-bb-PR'><filename>PR</filename></link> service host and port. </para> @@ -2094,7 +2105,7 @@ </glossdef> </glossentry> - <glossentry id='var-PV'><glossterm>PV</glossterm> + <glossentry id='var-bb-PV'><glossterm>PV</glossterm> <glossdef> <para>The version of the recipe. </para> @@ -2108,9 +2119,9 @@ </glossdiv> --> - <glossdiv id='var-glossary-r'><title>R</title> + <glossdiv id='var-bb-glossary-r'><title>R</title> - <glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm> + <glossentry id='var-bb-RDEPENDS'><glossterm>RDEPENDS</glossterm> <glossdef> <para> Lists a package's runtime dependencies (i.e. other packages) @@ -2165,13 +2176,13 @@ <para> For information on build-time dependencies, see the - <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> + <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> variable. </para> </glossdef> </glossentry> - <glossentry id='var-REPODIR'><glossterm>REPODIR</glossterm> + <glossentry id='var-bb-REPODIR'><glossterm>REPODIR</glossterm> <glossdef> <para> The directory in which a local copy of a @@ -2181,14 +2192,14 @@ </glossdef> </glossentry> - <glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm> + <glossentry id='var-bb-RPROVIDES'><glossterm>RPROVIDES</glossterm> <glossdef> <para> A list of package name aliases that a package also provides. These aliases are useful for satisfying runtime dependencies of other packages both during the build and on the target (as specified by - <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>). + <filename><link linkend='var-bb-RDEPENDS'>RDEPENDS</link></filename>). </para> <para> As with all package-controlling variables, you must always @@ -2201,7 +2212,7 @@ </glossdef> </glossentry> - <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm> + <glossentry id='var-bb-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm> <glossdef> <para> A list of packages that extends the usability of a package @@ -2210,7 +2221,7 @@ packages in order to successfully build, but needs them for the extended usability. To specify runtime dependencies for packages, see the - <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> + <filename><link linkend='var-bb-RDEPENDS'>RDEPENDS</link></filename> variable. </para> @@ -2243,15 +2254,15 @@ </glossdiv> - <glossdiv id='var-glossary-s'><title>S</title> + <glossdiv id='var-bb-glossary-s'><title>S</title> - <glossentry id='var-SECTION'><glossterm>SECTION</glossterm> + <glossentry id='var-bb-SECTION'><glossterm>SECTION</glossterm> <glossdef> <para>The section in which packages should be categorized.</para> </glossdef> </glossentry> - <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm> + <glossentry id='var-bb-SRC_URI'><glossterm>SRC_URI</glossterm> <glossdef> <para> The list of source files - local or remote. @@ -2272,7 +2283,7 @@ the metadata, from the local machine. The path is relative to the - <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> + <link linkend='var-bb-FILESPATH'><filename>FILESPATH</filename></link> variable.</para></listitem> <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a Bazaar revision control repository.</para></listitem> @@ -2322,7 +2333,7 @@ </glossdef> </glossentry> - <glossentry id='var-SRCDATE'><glossterm>SRCDATE</glossterm> + <glossentry id='var-bb-SRCDATE'><glossterm>SRCDATE</glossterm> <glossdef> <para> The date of the source code used to build the package. @@ -2331,7 +2342,7 @@ </glossdef> </glossentry> - <glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm> + <glossentry id='var-bb-SRCREV'><glossterm>SRCREV</glossterm> <glossdef> <para> The revision of the source code used to build the package. @@ -2344,13 +2355,13 @@ </glossdef> </glossentry> - <glossentry id='var-SRCREV_FORMAT'><glossterm>SRCREV_FORMAT</glossterm> + <glossentry id='var-bb-SRCREV_FORMAT'><glossterm>SRCREV_FORMAT</glossterm> <glossdef> <para> Helps construct valid - <link linkend='var-SRCREV'><filename>SRCREV</filename></link> + <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link> values when multiple source controlled URLs are used in - <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>. + <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>. </para> <para> @@ -2371,7 +2382,7 @@ </glossdef> </glossentry> - <glossentry id='var-STAMP'><glossterm>STAMP</glossterm> + <glossentry id='var-bb-STAMP'><glossterm>STAMP</glossterm> <glossdef> <para> Specifies the base path used to create recipe stamp files. @@ -2381,12 +2392,12 @@ </glossdef> </glossentry> - <glossentry id='var-STAMPCLEAN'><glossterm>STAMPCLEAN</glossterm> + <glossentry id='var-bb-STAMPCLEAN'><glossterm>STAMPCLEAN</glossterm> <glossdef> <para> Specifies the base path used to create recipe stamp files. Unlike the - <link linkend='var-STAMP'><filename>STAMP</filename></link> + <link linkend='var-bb-STAMP'><filename>STAMP</filename></link> variable, <filename>STAMPCLEAN</filename> can contain wildcards to match the range of files a clean operation should remove. @@ -2396,7 +2407,7 @@ </glossdef> </glossentry> - <glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm> + <glossentry id='var-bb-SUMMARY'><glossterm>SUMMARY</glossterm> <glossdef> <para> A short summary for the recipe, which is 72 characters or less. @@ -2404,7 +2415,7 @@ </glossdef> </glossentry> - <glossentry id='var-SVNDIR'><glossterm>SVNDIR</glossterm> + <glossentry id='var-bb-SVNDIR'><glossterm>SVNDIR</glossterm> <glossdef> <para> The directory in which files checked out of a Subversion @@ -2415,9 +2426,9 @@ </glossdiv> - <glossdiv id='var-glossary-t'><title>T</title> + <glossdiv id='var-bb-glossary-t'><title>T</title> - <glossentry id='var-T'><glossterm>T</glossterm> + <glossentry id='var-bb-T'><glossterm>T</glossterm> <glossdef> <para>Points to a directory were BitBake places temporary files, which consist mostly of task logs and @@ -2426,7 +2437,7 @@ </glossdef> </glossentry> - <glossentry id='var-TOPDIR'><glossterm>TOPDIR</glossterm> + <glossentry id='var-bb-TOPDIR'><glossterm>TOPDIR</glossterm> <glossdef> <para> Points to the build directory. |