summaryrefslogtreecommitdiffstats
path: root/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
diff options
context:
space:
mode:
Diffstat (limited to 'bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml')
-rw-r--r--bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml2537
1 files changed, 0 insertions, 2537 deletions
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
deleted file mode 100644
index 4c29b2464f..0000000000
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
+++ /dev/null
@@ -1,2537 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<!-- Dummy chapter -->
-<chapter id='ref-bb-variables-glos'>
-
-<title>Variables Glossary</title>
-
-<para>
- This chapter lists common variables used by BitBake and gives an overview
- of their function and contents.
-</para>
-
-<note>
- Following are some points regarding the variables listed in this glossary:
- <itemizedlist>
- <listitem><para>The variables listed in this glossary
- are specific to BitBake.
- Consequently, the descriptions are limited to that context.
- </para></listitem>
- <listitem><para>Also, variables exist in other systems that use BitBake
- (e.g. The Yocto Project and OpenEmbedded) that have names identical
- to those found in this glossary.
- For such cases, the variables in those systems extend the
- functionality of the variable as it is described here in
- this glossary.
- </para></listitem>
- <listitem><para>Finally, there are variables mentioned in this
- glossary that do not appear in the BitBake glossary.
- These other variables are variables used in systems that use
- BitBake.
- </para></listitem>
- </itemizedlist>
-</note>
-
-<glossary id='ref-bb-variables-glossary'>
-
- <para>
- <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-bb-LAYERDEPENDS'>L</link>
- <link linkend='var-bb-MIRRORS'>M</link>
-<!-- <link linkend='var-glossary-n'>N</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-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> -->
-<!-- <link linkend='var-glossary-x'>X</link> -->
-<!-- <link linkend='var-glossary-y'>Y</link> -->
-<!-- <link linkend='var-glossary-z'>Z</link>-->
- </para>
-
- <glossdiv id='var-bb-glossary-a'><title>A</title>
-
- <glossentry id='var-bb-ASSUME_PROVIDED'><glossterm>ASSUME_PROVIDED</glossterm>
- <glossdef>
- <para>
- Lists recipe names
- (<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.
- </para>
-
- <para>
- In OpenEmbedded-Core, <filename>ASSUME_PROVIDED</filename>
- mostly specifies native tools that should not be built.
- An example is <filename>git-native</filename>, which
- when specified allows for the Git binary from the host to
- be used rather than building
- <filename>git-native</filename>.
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
-
- <glossdiv id='var-bb-glossary-b'><title>B</title>
-
- <glossentry id='var-bb-B'><glossterm>B</glossterm>
- <glossdef>
- <para>
- The directory in which BitBake executes functions
- during a recipe's build process.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_ALLOWED_NETWORKS'><glossterm>BB_ALLOWED_NETWORKS</glossterm>
- <glossdef>
- <para>
- Specifies a space-delimited list of hosts that the fetcher
- is allowed to use to obtain the required source code.
- Following are considerations surrounding this variable:
- <itemizedlist>
- <listitem><para>
- This host list is only used if
- <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>
- Limited support for the "<filename>*</filename>"
- wildcard character for matching against the
- beginning of host names exists.
- For example, the following setting matches
- <filename>git.gnu.org</filename>,
- <filename>ftp.gnu.org</filename>, and
- <filename>foo.git.gnu.org</filename>.
- <literallayout class='monospaced'>
- BB_ALLOWED_NETWORKS = "*.gnu.org"
- </literallayout>
- <note><title>Important</title>
- <para>The use of the "<filename>*</filename>"
- character only works at the beginning of
- a host name and it must be isolated from
- the remainder of the host name.
- You cannot use the wildcard character in any
- other location of the name or combined with
- the front part of the name.</para>
-
- <para>For example,
- <filename>*.foo.bar</filename> is supported,
- while <filename>*aa.foo.bar</filename> is not.
- </para>
- </note>
- </para></listitem>
- <listitem><para>
- Mirrors not in the host list are skipped and
- logged in debug.
- </para></listitem>
- <listitem><para>
- Attempts to access networks not in the host list
- cause a failure.
- </para></listitem>
- </itemizedlist>
- Using <filename>BB_ALLOWED_NETWORKS</filename> in
- conjunction with
- <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-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
- successful fetch from the
- <filename>PREMIRRORS</filename> occurs.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_CONSOLELOG'><glossterm>BB_CONSOLELOG</glossterm>
- <glossdef>
- <para>
- Specifies the path to a log file into which BitBake's user
- interface writes output during the build.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_CURRENTTASK'><glossterm>BB_CURRENTTASK</glossterm>
- <glossdef>
- <para>
- Contains the name of the currently running task.
- The name does not include the
- <filename>do_</filename> prefix.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_DANGLINGAPPENDS_WARNONLY'><glossterm>BB_DANGLINGAPPENDS_WARNONLY</glossterm>
- <glossdef>
- <para>
- Defines how BitBake handles situations where an append
- file (<filename>.bbappend</filename>) has no
- corresponding recipe file (<filename>.bb</filename>).
- This condition often occurs when layers get out of sync
- (e.g. <filename>oe-core</filename> bumps a
- recipe version and the old recipe no longer exists and the
- other layer has not been updated to the new version
- of the recipe yet).
- </para>
-
- <para>
- The default fatal behavior is safest because it is
- the sane reaction given something is out of sync.
- It is important to realize when your changes are no longer
- being applied.
- </para>
- </glossdef>
- </glossentry>
-
- <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.
- with the <filename>-c</filename> command line option).
- The task name specified should not include the
- <filename>do_</filename> prefix.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_DISKMON_DIRS'><glossterm>BB_DISKMON_DIRS</glossterm>
- <glossdef>
- <para>
- Monitors disk space and available inodes during the build
- and allows you to control the build based on these
- parameters.
- </para>
-
- <para>
- Disk space monitoring is disabled by default.
- When setting this variable, use the following form:
- <literallayout class='monospaced'>
- BB_DISKMON_DIRS = "&lt;action&gt;,&lt;dir&gt;,&lt;threshold&gt; [...]"
-
- where:
-
- &lt;action&gt; is:
- ABORT: Immediately abort the build when
- a threshold is broken.
- STOPTASKS: Stop the build after the currently
- executing tasks have finished when
- a threshold is broken.
- WARN: Issue a warning but continue the
- build when a threshold is broken.
- Subsequent warnings are issued as
- defined by the
- <link linkend='var-bb-BB_DISKMON_WARNINTERVAL'>BB_DISKMON_WARNINTERVAL</link> variable,
- which must be defined.
-
- &lt;dir&gt; is:
- Any directory you choose. You can specify one or
- more directories to monitor by separating the
- groupings with a space. If two directories are
- on the same device, only the first directory
- is monitored.
-
- &lt;threshold&gt; is:
- Either the minimum available disk space,
- the minimum number of free inodes, or
- both. You must specify at least one. To
- omit one or the other, simply omit the value.
- Specify the threshold using G, M, K for Gbytes,
- Mbytes, and Kbytes, respectively. If you do
- not specify G, M, or K, Kbytes is assumed by
- default. Do not use GB, MB, or KB.
- </literallayout>
- </para>
-
- <para>
- Here are some examples:
- <literallayout class='monospaced'>
- BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
- BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
- BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
- </literallayout>
- The first example works only if you also set
- 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
- 100 Kbytes.
- Because two directories are provided with the variable, the
- build system also issues a
- warning when the disk space in the
- <filename>${SSTATE_DIR}</filename> directory drops
- below 1 Gbyte or the number of free inodes drops
- below 100 Kbytes.
- Subsequent warnings are issued during intervals as
- defined by the <filename>BB_DISKMON_WARNINTERVAL</filename>
- variable.
- </para>
-
- <para>
- The second example stops the build after all currently
- executing tasks complete when the minimum disk space
- in the <filename>${TMPDIR}</filename>
- directory drops below 1 Gbyte.
- No disk monitoring occurs for the free inodes in this case.
- </para>
-
- <para>
- The final example immediately aborts the build when the
- number of free inodes in the <filename>${TMPDIR}</filename> directory
- drops below 100 Kbytes.
- No disk space monitoring for the directory itself occurs
- in this case.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_DISKMON_WARNINTERVAL'><glossterm>BB_DISKMON_WARNINTERVAL</glossterm>
- <glossdef>
- <para>
- Defines the disk space and free inode warning intervals.
- </para>
-
- <para>
- If you are going to use the
- <filename>BB_DISKMON_WARNINTERVAL</filename> variable, you must
- also use the
- <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
- the respective interval.
- </para>
-
- <para>
- If you do not provide a <filename>BB_DISKMON_WARNINTERVAL</filename>
- variable and you do use <filename>BB_DISKMON_DIRS</filename> with
- the "WARN" action, the disk monitoring interval defaults to
- the following:
- <literallayout class='monospaced'>
- BB_DISKMON_WARNINTERVAL = "50M,5K"
- </literallayout>
- </para>
-
- <para>
- When specifying the variable in your configuration file,
- use the following form:
- <literallayout class='monospaced'>
- BB_DISKMON_WARNINTERVAL = "&lt;disk_space_interval&gt;,&lt;disk_inode_interval&gt;"
-
- where:
-
- &lt;disk_space_interval&gt; is:
- An interval of memory expressed in either
- G, M, or K for Gbytes, Mbytes, or Kbytes,
- respectively. You cannot use GB, MB, or KB.
-
- &lt;disk_inode_interval&gt; is:
- An interval of free inodes expressed in either
- G, M, or K for Gbytes, Mbytes, or Kbytes,
- respectively. You cannot use GB, MB, or KB.
- </literallayout>
- </para>
-
- <para>
- Here is an example:
- <literallayout class='monospaced'>
- BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
- BB_DISKMON_WARNINTERVAL = "50M,5K"
- </literallayout>
- These variables cause BitBake to
- issue subsequent warnings each time the available
- disk space further reduces by 50 Mbytes or the number
- of free inodes further reduces by 5 Kbytes in the
- <filename>${SSTATE_DIR}</filename> directory.
- Subsequent warnings based on the interval occur each time
- a respective interval is reached beyond the initial warning
- (i.e. 1 Gbytes and 100 Kbytes).
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_ENV_WHITELIST'><glossterm>BB_ENV_WHITELIST</glossterm>
- <glossdef>
- <para>
- Specifies the internal whitelist of variables to allow
- through from the external environment into BitBake's
- datastore.
- If the value of this variable is not specified
- (which is the default), the following list is used:
- <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-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.
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_ENV_EXTRAWHITE'><glossterm>BB_ENV_EXTRAWHITE</glossterm>
- <glossdef>
- <para>
- Specifies an additional set of variables to allow through
- (whitelist) from the external environment into BitBake's
- datastore.
- This list of variables are on top of the internal list
- set in
- <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.
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <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-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link>
- for files.
- BitBake will not search the main
- <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>
- or
- <link linkend='var-bb-MIRRORS'><filename>MIRRORS</filename></link>.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_FILENAME'><glossterm>BB_FILENAME</glossterm>
- <glossdef>
- <para>
- Contains the filename of the recipe that owns the currently
- running task.
- For example, if the <filename>do_fetch</filename> task that
- resides in the <filename>my-recipe.bb</filename> is
- executing, the <filename>BB_FILENAME</filename> variable
- contains "/foo/path/my-recipe.bb".
- </para>
- </glossdef>
- </glossentry>
-
- <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-bb-DL_DIR'><filename>DL_DIR</filename></link>
- directory.
- Anyone wishing to create a source mirror would want to
- enable this variable.
- </para>
-
- <para>
- For performance reasons, creating and placing tarballs of
- the Git repositories is not the default action by BitBake.
- <literallayout class='monospaced'>
- BB_GENERATE_MIRROR_TARBALLS = "1"
- </literallayout>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_HASHCONFIG_WHITELIST'><glossterm>BB_HASHCONFIG_WHITELIST</glossterm>
- <glossdef>
- <para>
- Lists variables that are excluded from base configuration
- checksum, which is used to determine if the cache can
- be reused.
- </para>
-
- <para>
- One of the ways BitBake determines whether to re-parse the
- main metadata is through checksums of the variables in the
- datastore of the base configuration data.
- There are variables that you typically want to exclude when
- checking whether or not to re-parse and thus rebuild the
- cache.
- As an example, you would usually exclude
- <filename>TIME</filename> and <filename>DATE</filename>
- because these variables are always changing.
- If you did not exclude them, BitBake would never reuse the
- cache.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_HASHBASE_WHITELIST'><glossterm>BB_HASHBASE_WHITELIST</glossterm>
- <glossdef>
- <para>
- Lists variables that are excluded from checksum and
- dependency data.
- Variables that are excluded can therefore change without
- affecting the checksum mechanism.
- A common example would be the variable for the path of
- the build.
- BitBake's output should not (and usually does not) depend
- on the directory in which it was built.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_HASHCHECK_FUNCTION'><glossterm>BB_HASHCHECK_FUNCTION</glossterm>
- <glossdef>
- <para>
- 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.
- The function returns the list of setscene tasks that should
- be executed.
- </para>
-
- <para>
- At this point in the execution of the code, the objective
- is to quickly verify if a given setscene function is likely
- to work or not.
- It's easier to check the list of setscene functions in
- one pass than to call many individual tasks.
- The returned list need not be completely accurate.
- A given setscene task can still later fail.
- However, the more accurate the data returned, the more
- efficient the build will be.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_INVALIDCONF'><glossterm>BB_INVALIDCONF</glossterm>
- <glossdef>
- <para>
- Used in combination with the
- <filename>ConfigParsed</filename> event to trigger
- re-parsing the base metadata (i.e. all the
- recipes).
- The <filename>ConfigParsed</filename> event can set the
- variable to trigger the re-parse.
- You must be careful to avoid recursive loops with this
- functionality.
- </para>
- </glossdef>
- </glossentry>
-
- <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-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:
- <literallayout class='monospaced'>
- log.{task}.{pid}
- </literallayout>
- If you want to force log files to take a specific name,
- you can set this variable in a configuration file.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_NICE_LEVEL'><glossterm>BB_NICE_LEVEL</glossterm>
- <glossdef>
- <para>
- Allows BitBake to run at a specific priority
- (i.e. nice level).
- System permissions usually mean that BitBake can reduce its
- priority but not raise it again.
- See
- <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-BB_NO_NETWORK'><glossterm>BB_NO_NETWORK</glossterm>
- <glossdef>
- <para>
- Disables network access in the BitBake fetcher modules.
- With this access disabled, any command that attempts to
- access the network becomes an error.
- </para>
-
- <para>
- Disabling network access is useful for testing source
- mirrors, running builds when not connected to the Internet,
- and when operating in certain kinds of firewall
- environments.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
- <glossdef>
- <para>
- The maximum number of tasks BitBake should run in parallel
- at any one time.
- If your host development system supports multiple cores,
- a good rule of thumb is to set this variable to twice the
- number of cores.
- </para>
- </glossdef>
- </glossentry>
-
- <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.
- By default, the number of threads is equal to the number
- of cores on the system.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_ORIGENV'><glossterm>BB_ORIGENV</glossterm>
- <glossdef>
- <para>
- Contains a copy of the original external environment in
- which BitBake was run.
- The copy is taken before any whitelisted variable values
- are filtered into BitBake's datastore.
- <note>
- The contents of this variable is a datastore object
- that can be queried using the normal datastore
- operations.
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_PRESERVE_ENV'><glossterm>BB_PRESERVE_ENV</glossterm>
- <glossdef>
- <para>
- Disables whitelisting and instead allows all variables
- through from the external environment into BitBake's
- datastore.
- <note>
- You must set this variable in the external
- environment in order for it to work.
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <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-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:
- <literallayout class='monospaced'>
- run.{task}.{pid}
- </literallayout>
- If you want to force run files to take a specific name,
- you can set this variable in a configuration file.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_RUNTASK'><glossterm>BB_RUNTASK</glossterm>
- <glossdef>
- <para>
- Contains the name of the currently executing task.
- The value includes the "do_" prefix.
- For example, if the currently executing task is
- <filename>do_config</filename>, the value is
- "do_config".
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_SCHEDULER'><glossterm>BB_SCHEDULER</glossterm>
- <glossdef>
- <para>
- Selects the name of the scheduler to use for the
- scheduling of BitBake tasks.
- Three options exist:
- <itemizedlist>
- <listitem><para><emphasis>basic</emphasis> -
- The basic framework from which everything derives.
- Using this option causes tasks to be ordered
- numerically as they are parsed.
- </para></listitem>
- <listitem><para><emphasis>speed</emphasis> -
- Executes tasks first that have more tasks
- depending on them.
- The "speed" option is the default.
- </para></listitem>
- <listitem><para><emphasis>completion</emphasis> -
- Causes the scheduler to try to complete a given
- recipe once its build has started.
- </para></listitem>
- </itemizedlist>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_SCHEDULERS'><glossterm>BB_SCHEDULERS</glossterm>
- <glossdef>
- <para>
- Defines custom schedulers to import.
- Custom schedulers need to be derived from the
- <filename>RunQueueScheduler</filename> class.
- </para>
-
- <para>
- For information how to select a scheduler, see the
- <link linkend='var-bb-BB_SCHEDULER'><filename>BB_SCHEDULER</filename></link>
- variable.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_SETSCENE_DEPVALID'><glossterm>BB_SETSCENE_DEPVALID</glossterm>
- <glossdef>
- <para>
- Specifies a function BitBake calls that determines
- whether BitBake requires a setscene dependency to be met.
- </para>
-
- <para>
- When running a setscene task, BitBake needs to
- know which dependencies of that setscene task also need
- to be run.
- Whether dependencies also need to be run is highly
- dependent on the metadata.
- The function specified by this variable returns a
- "True" or "False" depending on whether the dependency needs
- to be met.
- </para>
- </glossdef>
- </glossentry>
-
- <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
- planned task execution before the main task execution
- happens.
- The function is called once BitBake has a list of setscene
- tasks that have run and either succeeded or failed.
- </para>
-
- <para>
- The function allows for a task list check to see if they
- make sense.
- Even if BitBake was planning to skip a task, the
- returned value of the function can force BitBake to run
- the task, which is necessary under certain metadata
- defined circumstances.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_SIGNATURE_EXCLUDE_FLAGS'><glossterm>BB_SIGNATURE_EXCLUDE_FLAGS</glossterm>
- <glossdef>
- <para>
- Lists variable flags (varflags)
- that can be safely excluded from checksum
- and dependency data for keys in the datastore.
- When generating checksum or dependency data for keys in the
- datastore, the flags set against that key are normally
- included in the checksum.
- </para>
-
- <para>
- For more information on varflags, see the
- "<link linkend='variable-flags'>Variable Flags</link>"
- section.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_SIGNATURE_HANDLER'><glossterm>BB_SIGNATURE_HANDLER</glossterm>
- <glossdef>
- <para>
- Defines the name of the signature handler BitBake uses.
- The signature handler defines the way stamp files are
- created and handled, if and how the signature is
- incorporated into the stamps, and how the signature
- itself is generated.
- </para>
-
- <para>
- A new signature handler can be added by injecting a class
- derived from the
- <filename>SignatureGenerator</filename> class into the
- global namespace.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_SRCREV_POLICY'><glossterm>BB_SRCREV_POLICY</glossterm>
- <glossdef>
- <para>
- Defines the behavior of the fetcher when it interacts with
- source control systems and dynamic source revisions.
- The <filename>BB_SRCREV_POLICY</filename> variable is
- useful when working without a network.
- </para>
-
- <para>
- The variable can be set using one of two policies:
- <itemizedlist>
- <listitem><para><emphasis>cache</emphasis> -
- Retains the value the system obtained previously
- rather than querying the source control system
- each time.
- </para></listitem>
- <listitem><para><emphasis>clear</emphasis> -
- Queries the source controls system every time.
- With this policy, there is no cache.
- The "clear" policy is the default.
- </para></listitem>
- </itemizedlist>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_STAMP_POLICY'><glossterm>BB_STAMP_POLICY</glossterm>
- <glossdef>
- <para>
- Defines the mode used for how timestamps of stamp files
- are compared.
- You can set the variable to one of the following modes:
- <itemizedlist>
- <listitem><para><emphasis>perfile</emphasis> -
- Timestamp comparisons are only made
- between timestamps of a specific recipe.
- This is the default mode.
- </para></listitem>
- <listitem><para><emphasis>full</emphasis> -
- Timestamp comparisons are made for all
- dependencies.
- </para></listitem>
- <listitem><para><emphasis>whitelist</emphasis> -
- Identical to "full" mode except timestamp
- comparisons are made for recipes listed in the
- <link linkend='var-bb-BB_STAMP_WHITELIST'><filename>BB_STAMP_WHITELIST</filename></link>
- variable.
- </para></listitem>
- </itemizedlist>
- <note>
- Stamp policies are largely obsolete with the
- introduction of setscene tasks.
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <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-BB_STAMP_POLICY'><filename>BB_STAMP_POLICY</filename></link>
- variable.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_STRICT_CHECKSUM'><glossterm>BB_STRICT_CHECKSUM</glossterm>
- <glossdef>
- <para>
- Sets a more strict checksum mechanism for non-local URLs.
- Setting this variable to a value causes BitBake
- to report an error if it encounters a non-local URL
- that does not have at least one checksum specified.
- </para>
- </glossdef>
- </glossentry>
-
- <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.
- During Autobuilder testing, random failures can occur
- for tasks due to I/O starvation.
- These failures occur during various QEMU runtime timeouts.
- You can use the <filename>BB_TASK_IONICE_LEVEL</filename>
- variable to adjust the I/O priority of these tasks.
- <note>
- This variable works similarly to the
- <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>
-
- <para>
- Set the variable as follows:
- <literallayout class='monospaced'>
- BB_TASK_IONICE_LEVEL = "<replaceable>class</replaceable>.<replaceable>prio</replaceable>"
- </literallayout>
- For <replaceable>class</replaceable>, the default value is
- "2", which is a best effort.
- You can use "1" for realtime and "3" for idle.
- If you want to use realtime, you must have superuser
- privileges.
- </para>
-
- <para>
- For <replaceable>prio</replaceable>, you can use any
- value from "0", which is the highest priority, to "7",
- which is the lowest.
- The default value is "4".
- You do not need any special privileges to use this range
- of priority values.
- <note>
- In order for your I/O priority settings to take effect,
- you need the Completely Fair Queuing (CFQ) Scheduler
- selected for the backing block device.
- To select the scheduler, use the following command form
- where <replaceable>device</replaceable> is the device
- (e.g. sda, sdb, and so forth):
- <literallayout class='monospaced'>
- $ sudo sh -c “echo cfq > /sys/block/<replaceable>device</replaceable>/queu/scheduler
- </literallayout>
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_TASK_NICE_LEVEL'><glossterm>BB_TASK_NICE_LEVEL</glossterm>
- <glossdef>
- <para>
- Allows specific tasks to change their priority
- (i.e. nice level).
- </para>
-
- <para>
- You can use this variable in combination with task
- overrides to raise or lower priorities of specific tasks.
- For example, on the
- <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink>
- autobuilder, QEMU emulation in images is given a higher
- priority as compared to build tasks to ensure that images
- do not suffer timeouts on loaded systems.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_TASKHASH'><glossterm>BB_TASKHASH</glossterm>
- <glossdef>
- <para>
- Within an executing task, this variable holds the hash
- of the task as returned by the currently enabled
- signature generator.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_VERBOSE_LOGS'><glossterm>BB_VERBOSE_LOGS</glossterm>
- <glossdef>
- <para>
- Controls how verbose BitBake is during builds.
- If set, shell scripts echo commands and shell script output
- appears on standard out (stdout).
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BB_WORKERCONTEXT'><glossterm>BB_WORKERCONTEXT</glossterm>
- <glossdef>
- <para>
- Specifies if the current context is executing a task.
- BitBake sets this variable to "1" when a task is
- being executed.
- The value is not set when the task is in server context
- during parsing or event handling.
- </para>
- </glossdef>
- </glossentry>
-
-
- <glossentry id='var-bb-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm>
- <glossdef>
- <para>
- Allows you to extend a recipe so that it builds variants
- of the software.
- Some examples of these variants for recipes from the
- OpenEmbedded-Core metadata are "natives" such as
- <filename>quilt-native</filename>, which is a copy of
- Quilt built to run on the build system; "crosses" such
- as <filename>gcc-cross</filename>, which is a compiler
- built to run on the build machine but produces binaries
- that run on the target <filename>MACHINE</filename>;
- "nativesdk", which targets the SDK machine instead of
- <filename>MACHINE</filename>; and "mulitlibs" in the form
- "<filename>multilib:</filename><replaceable>multilib_name</replaceable>".
- </para>
-
- <para>
- To build a different variant of the recipe with a minimal
- amount of code, it usually is as simple as adding the
- variable to your recipe.
- Here are two examples.
- The "native" variants are from the OpenEmbedded-Core
- metadata:
- <literallayout class='monospaced'>
- BBCLASSEXTEND =+ "native nativesdk"
- BBCLASSEXTEND =+ "multilib:<replaceable>multilib_name</replaceable>"
- </literallayout>
- <note>
- <para>
- Internally, the <filename>BBCLASSEXTEND</filename>
- mechanism generates recipe variants by rewriting
- variable values and applying overrides such as
- <filename>_class-native</filename>.
- For example, to generate a native version of a recipe,
- a
- <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link>
- on "foo" is rewritten to a <filename>DEPENDS</filename>
- on "foo-native".
- </para>
-
- <para>
- Even when using <filename>BBCLASSEXTEND</filename>, the
- recipe is only parsed once.
- Parsing once adds some limitations.
- For example, it is not possible to
- include a different file depending on the variant,
- since <filename>include</filename> statements are
- processed when the recipe is parsed.
- </para>
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBDEBUG'><glossterm>BBDEBUG</glossterm>
- <glossdef>
- <para>
- Sets the BitBake debug output level to a specific value
- as incremented by the <filename>-D</filename> command line
- option.
- <note>
- You must set this variable in the external environment
- in order for it to work.
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <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>
- variables.
- Typically, each layer appends its name to this variable in its
- <filename>conf/layer.conf</filename> file.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm>
- <glossdef>
- <para>Variable that expands to match files from
- <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.
- <filename>BBFILE_PATTERN_emenlow</filename>).</para>
- </glossdef>
- </glossentry>
-
- <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
- more than one layer.
- Setting this variable allows you to prioritize a
- layer against other layers that contain the same recipe - effectively
- 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-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>
- <para>A larger value for the <filename>BBFILE_PRIORITY</filename> variable results in a higher
- precedence.
- 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-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
- (or 1 if no priorities are defined).</para>
- <tip>
- You can use the command <filename>bitbake-layers show-layers</filename> to list
- all configured layers along with their priorities.
- </tip>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBFILES'><glossterm>BBFILES</glossterm>
- <glossdef>
- <para>
- A space-separated list of recipe files BitBake uses to
- build software.
- </para>
-
- <para>
- When specifying recipe files, you can pattern match using
- Python's
- <ulink url='https://docs.python.org/3/library/glob.html'><filename>glob</filename></ulink>
- syntax.
- For details on the syntax, see the documentation by
- following the previous link.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-BBFILES_DYNAMIC'><glossterm>BBFILES_DYNAMIC</glossterm>
- <info>
- BBFILES_DYNAMIC[doc] = "Activates content depending on presence of identified layers."
- </info>
- <glossdef>
- <para role="glossdeffirst">
- Activates content depending on presence of identified layers.
- You identify the layers by the collections that the layers
- define.
- </para>
-
- <para>
- Use the <filename>BBFILES_DYNAMIC</filename> variable to
- avoid <filename>.bbappend</filename> files whose
- corresponding <filename>.bb</filename> file is in a layer
- that attempts to modify other layers through
- <filename>.bbappend</filename> but does not want to
- introduce a hard dependency on those other layers.
- </para>
-
- <para>
- Additionally you can prefix the rule with "!" to add
- <filename>.bbappend</filename> and <filename>.bb</filename> files
- in case a layer is not present.
- Use this avoid hard dependency on those other layers.
- </para>
-
- <para>
- Use the following form for
- <filename>BBFILES_DYNAMIC</filename>:
- <literallayout class='monospaced'>
- <replaceable>collection_name</replaceable>:<replaceable>filename_pattern</replaceable>
- </literallayout>
- The following example identifies two collection names and
- two filename patterns:
- <literallayout class='monospaced'>
- BBFILES_DYNAMIC += "\
- clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
- core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
- "
- </literallayout>
- When the collection name is prefixed with "!" it will add the file pattern in case
- the layer is absent:
- <literallayout class='monospaced'>
- BBFILES_DYNAMIC += "\
- !clang-layer:${LAYERDIR}/backfill/meta-clang/*/*/*.bb \
- "
- </literallayout>
-
- This next example shows an error message that occurs
- because invalid entries are found, which cause parsing to
- abort:
- <literallayout class='monospaced'>
- ERROR: BBFILES_DYNAMIC entries must be of the form {!}&lt;collection name&gt;:&lt;filename pattern&gt;, not:
- /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
- /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
- </literallayout>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBINCLUDED'><glossterm>BBINCLUDED</glossterm>
- <glossdef>
- <para>
- Contains a space-separated list of all of all files that
- BitBake's parser included during parsing of the current
- file.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm>
- <glossdef>
- <para>
- If set to a value, enables printing the task log when
- reporting a failed task.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBINCLUDELOGS_LINES'><glossterm>BBINCLUDELOGS_LINES</glossterm>
- <glossdef>
- <para>
- If
- <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>,
- the entire log is printed.
- </para>
- </glossdef>
- </glossentry>
-
- <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
- file in the build directory.
- Here is an example:
- <literallayout class='monospaced'>
- BBLAYERS = " \
- /home/scottrif/poky/meta \
- /home/scottrif/poky/meta-yocto \
- /home/scottrif/poky/meta-yocto-bsp \
- /home/scottrif/poky/meta-mykernel \
- "
-
- </literallayout>
- This example enables four layers, one of which is a custom, user-defined layer
- named <filename>meta-mykernel</filename>.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBLAYERS_FETCH_DIR'><glossterm>BBLAYERS_FETCH_DIR</glossterm>
- <glossdef>
- <para>
- Sets the base location where layers are stored.
- This setting is used in conjunction with
- <filename>bitbake-layers layerindex-fetch</filename> and
- tells <filename>bitbake-layers</filename> where to place
- the fetched layers.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBMASK'><glossterm>BBMASK</glossterm>
- <glossdef>
- <para>
- Prevents BitBake from processing recipes and recipe
- append files.
- </para>
-
- <para>
- You can use the <filename>BBMASK</filename> variable
- to "hide" these <filename>.bb</filename> and
- <filename>.bbappend</filename> files.
- BitBake ignores any recipe or recipe append files that
- match any of the expressions.
- It is as if BitBake does not see them at all.
- Consequently, matching files are not parsed or otherwise
- used by BitBake.
- </para>
-
- <para>
- The values you provide are passed to Python's regular
- expression compiler.
- Consequently, the syntax follows Python's Regular
- Expression (re) syntax.
- The expressions are compared against the full paths to
- the files.
- For complete syntax information, see Python's
- documentation at
- <ulink url='http://docs.python.org/3/library/re.html#re'></ulink>.
- </para>
-
- <para>
- The following example uses a complete regular expression
- to tell BitBake to ignore all recipe and recipe append
- files in the <filename>meta-ti/recipes-misc/</filename>
- directory:
- <literallayout class='monospaced'>
- BBMASK = "meta-ti/recipes-misc/"
- </literallayout>
- If you want to mask out multiple directories or recipes,
- you can specify multiple regular expression fragments.
- This next example masks out multiple directories and
- individual recipes:
- <literallayout class='monospaced'>
- BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
- BBMASK += "/meta-oe/recipes-support/"
- BBMASK += "/meta-foo/.*/openldap"
- BBMASK += "opencv.*\.bbappend"
- BBMASK += "lzma"
- </literallayout>
- <note>
- When specifying a directory name, use the trailing
- slash character to ensure you match just that directory
- name.
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <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>
- <glossdef>
- <para role="glossdeffirst">
-<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Enables BitBake to perform multiple configuration builds
- and lists each separate configuration (multiconfig).
- You can use this variable to cause BitBake to build
- multiple targets where each target has a separate
- configuration.
- Define <filename>BBMULTICONFIG</filename> in your
- <filename>conf/local.conf</filename> configuration file.
- </para>
-
- <para>
- As an example, the following line specifies three
- multiconfigs, each having a separate configuration file:
- <literallayout class='monospaced'>
- BBMULTIFONFIG = "configA configB configC"
- </literallayout>
- Each configuration file you use must reside in the
- build directory within a directory named
- <filename>conf/multiconfig</filename> (e.g.
- <replaceable>build_directory</replaceable><filename>/conf/multiconfig/configA.conf</filename>).
- </para>
-
- <para>
- For information on how to use
- <filename>BBMULTICONFIG</filename> in an environment that
- supports building targets with multiple configurations,
- see the
- "<link linkend='executing-a-multiple-configuration-build'>Executing a Multiple Configuration Build</link>"
- section.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBPATH'><glossterm>BBPATH</glossterm>
- <glossdef>
- <para>
- Used by BitBake to locate class
- (<filename>.bbclass</filename>) and configuration
- (<filename>.conf</filename>) files.
- This variable is analogous to the
- <filename>PATH</filename> variable.
- </para>
-
- <para>
- If you run BitBake from a directory outside of the
- build directory,
- you must be sure to set
- <filename>BBPATH</filename> to point to the
- build directory.
- Set the variable as you would any environment variable
- and then run BitBake:
- <literallayout class='monospaced'>
- $ BBPATH="<replaceable>build_directory</replaceable>"
- $ export BBPATH
- $ bitbake <replaceable>target</replaceable>
- </literallayout>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBSERVER'><glossterm>BBSERVER</glossterm>
- <glossdef>
- <para>
- Points to the server that runs memory-resident BitBake.
- The variable is only used when you employ memory-resident
- BitBake.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BBTARGETS'><glossterm>BBTARGETS</glossterm>
- <glossdef>
- <para>
- Allows you to use a configuration file to add to the list
- of command-line target recipes you want to build.
- </para>
- </glossdef>
- </glossentry>
-
- <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-bb-OVERRIDES'><filename>OVERRIDES</filename></link>
- mechanism for a single version or for an optionally named
- range of versions.
- </para>
-
- <para>
- For more information on <filename>BBVERSIONS</filename>,
- see the
- "<link linkend='variants-class-extension-mechanism'>Variants - Class Extension Mechanism</link>"
- section.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BITBAKE_UI'><glossterm>BITBAKE_UI</glossterm>
- <glossdef>
- <para>
- Used to specify the UI module to use when running BitBake.
- Using this variable is equivalent to using the
- <filename>-u</filename> command-line option.
- <note>
- You must set this variable in the external environment
- in order for it to work.
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BUILDNAME'><glossterm>BUILDNAME</glossterm>
- <glossdef>
- <para>
- A name assigned to the build.
- The name defaults to a datetime stamp of when the build was
- started but can be defined by the metadata.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-BZRDIR'><glossterm>BZRDIR</glossterm>
- <glossdef>
- <para>
- The directory in which files checked out of a Bazaar
- system are stored.
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
- <glossdiv id='var-bb-glossary-c'><title>C</title>
-
- <glossentry id='var-bb-CACHE'><glossterm>CACHE</glossterm>
- <glossdef>
- <para>
- Specifies the directory BitBake uses to store a cache
- of the metadata so it does not need to be parsed every
- time BitBake is started.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-CVSDIR'><glossterm>CVSDIR</glossterm>
- <glossdef>
- <para>
- The directory in which files checked out under the
- CVS system are stored.
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
- <glossdiv id='var-bb-glossary-d'><title>D</title>
-
- <glossentry id='var-bb-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
- <glossdef>
- <para>
- Specifies a weak bias for recipe selection priority.
- </para>
- <para>
- The most common usage of this is variable is to set
- it to "-1" within a recipe for a development version of a
- 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-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-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-bb-DEPENDS'><glossterm>DEPENDS</glossterm>
- <glossdef>
- <para>
- Lists a recipe's build-time dependencies
- (i.e. other recipe files).
- </para>
-
- <para>
- Consider this simple example for two recipes named "a" and
- "b" that produce similarly named packages.
- In this example, the <filename>DEPENDS</filename>
- statement appears in the "a" recipe:
- <literallayout class='monospaced'>
- DEPENDS = "b"
- </literallayout>
- Here, the dependency is such that the
- <filename>do_configure</filename> task for recipe "a"
- depends on the <filename>do_populate_sysroot</filename>
- task of recipe "b".
- This means anything that recipe "b" puts into sysroot
- is available when recipe "a" is configuring itself.
- </para>
-
- <para>
- For information on runtime dependencies, see the
- <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link>
- variable.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-DESCRIPTION'><glossterm>DESCRIPTION</glossterm>
- <glossdef>
- <para>
- A long description for the recipe.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-DL_DIR'><glossterm>DL_DIR</glossterm>
- <glossdef>
- <para>
- The central download directory used by the build process to
- store downloads.
- By default, <filename>DL_DIR</filename> gets files
- suitable for mirroring for everything except Git
- repositories.
- If you want tarballs of Git repositories, use the
- <link linkend='var-bb-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
- variable.
- </para>
- </glossdef>
-
- </glossentry>
- </glossdiv>
-
- <glossdiv id='var-bb-glossary-e'><title>E</title>
-
- <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.
- <filename>bitbake world</filename>).
- During world builds, BitBake locates, parses and builds all
- recipes found in every layer exposed in the
- <filename>bblayers.conf</filename> configuration file.
- </para>
-
- <para>
- To exclude a recipe from a world build using this variable,
- set the variable to "1" in the recipe.
- </para>
-
- <note>
- Recipes added to <filename>EXCLUDE_FROM_WORLD</filename>
- may still be built during a world build in order to satisfy
- dependencies of other recipes.
- Adding a recipe to <filename>EXCLUDE_FROM_WORLD</filename>
- only ensures that the recipe is not explicitly added
- to the list of build targets in a world build.
- </note>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
- <glossdiv id='var-bb-glossary-f'><title>F</title>
-
- <glossentry id='var-bb-FAKEROOT'><glossterm>FAKEROOT</glossterm>
- <glossdef>
- <para>
- Contains the command to use when running a shell script
- in a fakeroot environment.
- The <filename>FAKEROOT</filename> variable is obsolete
- and has been replaced by the other
- <filename>FAKEROOT*</filename> variables.
- See these entries in the glossary for more information.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-FAKEROOTBASEENV'><glossterm>FAKEROOTBASEENV</glossterm>
- <glossdef>
- <para>
- Lists environment variables to set when executing
- the command defined by
- <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-bb-FAKEROOTCMD'><glossterm>FAKEROOTCMD</glossterm>
- <glossdef>
- <para>
- Contains the command that starts the bitbake-worker
- process in the fakeroot environment.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-FAKEROOTDIRS'><glossterm>FAKEROOTDIRS</glossterm>
- <glossdef>
- <para>
- Lists directories to create before running a task in
- the fakeroot environment.
- </para>
- </glossdef>
- </glossentry>
-
- <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-bb-FAKEROOTBASEENV'><filename>FAKEROOTBASEENV</filename></link>
- variable.
- </para>
- </glossdef>
- </glossentry>
-
- <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-bb-FAKEROOTENV'><filename>FAKEROOTENV</filename></link>
- variable.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-FETCHCMD'><glossterm>FETCHCMD</glossterm>
- <glossdef>
- <para>
- Defines the command the BitBake fetcher module
- executes when running fetch operations.
- You need to use an override suffix when you use the
- variable (e.g. <filename>FETCHCMD_git</filename>
- or <filename>FETCHCMD_svn</filename>).
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-FILE'><glossterm>FILE</glossterm>
- <glossdef>
- <para>
- Points at the current file.
- BitBake sets this variable during the parsing process
- to identify the file being parsed.
- BitBake also sets this variable when a recipe is being
- executed to identify the recipe file.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-FILESPATH'><glossterm>FILESPATH</glossterm>
- <glossdef>
- <para>
- Specifies directories BitBake uses when searching for
- patches and files.
- The "local" fetcher module uses these directories when
- handling <filename>file://</filename> URLs.
- The variable behaves like a shell <filename>PATH</filename>
- environment variable.
- The value is a colon-separated list of directories that
- are searched left-to-right in order.
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
-
- <glossdiv id='var-bb-glossary-g'><title>G</title>
-
- <glossentry id='var-bb-GITDIR'><glossterm>GITDIR</glossterm>
- <glossdef>
- <para>
- The directory in which a local copy of a Git repository
- is stored when it is cloned.
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
-
- <glossdiv id='var-bb-glossary-h'><title>H</title>
-
- <glossentry id='var-bb-HGDIR'><glossterm>HGDIR</glossterm>
- <glossdef>
- <para>
- The directory in which files checked out of a Mercurial
- system are stored.
- </para>
- </glossdef>
- </glossentry>
-
- <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>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
- <glossdiv id='var-bb-glossary-i'><title>I</title>
-
- <glossentry id='var-bb-INHERIT'><glossterm>INHERIT</glossterm>
- <glossdef>
- <para>
- Causes the named class or classes to be inherited globally.
- Anonymous functions in the class or classes
- are not executed for the
- base configuration and in each individual recipe.
- The OpenEmbedded build system ignores changes to
- <filename>INHERIT</filename> in individual recipes.
- </para>
-
- <para>
- For more information on <filename>INHERIT</filename>, see
- the
- "<link linkend="inherit-configuration-directive"><filename>INHERIT</filename> Configuration Directive</link>"
- section.
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
-<!--
- <glossdiv id='var-glossary-j'><title>J</title>
- </glossdiv>
-
- <glossdiv id='var-glossary-k'><title>K</title>
- </glossdiv>
--->
-
- <glossdiv id='var-bb-glossary-l'><title>L</title>
-
- <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-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>
- <para>
- You use this variable in the <filename>conf/layer.conf</filename> file.
- You must also use the specific layer name as a suffix
- to the variable (e.g. <filename>LAYERDEPENDS_mylayer</filename>).</para>
- </glossdef>
- </glossentry>
-
- <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.
- 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-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-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-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-bb-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link>
- for another layer in order to depend on a specific version
- of the layer.</para>
- <para>
- You use this variable in the <filename>conf/layer.conf</filename> file.
- You must also use the specific layer name as a suffix
- to the variable (e.g. <filename>LAYERDEPENDS_mylayer</filename>).</para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-LICENSE'><glossterm>LICENSE</glossterm>
- <glossdef>
- <para>
- The list of source licenses for the recipe.
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
- <glossdiv id='var-bb-glossary-m'><title>M</title>
-
- <glossentry id='var-bb-MIRRORS'><glossterm>MIRRORS</glossterm>
- <glossdef>
- <para>
- Specifies additional paths from which BitBake gets source code.
- When the build system searches for source code, it first
- tries the local download directory.
- If that location fails, the build system tries locations
- defined by
- <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-bb-MULTI_PROVIDER_WHITELIST'><glossterm>MULTI_PROVIDER_WHITELIST</glossterm>
- <glossdef>
- <para>
- Allows you to suppress BitBake warnings caused when
- building two separate recipes that provide the same
- output.
- </para>
-
- <para>
- 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.
- However, cases do exist where it makes sense, particularly
- in the <filename>virtual/*</filename> namespace.
- You can use this variable to suppress BitBake's warnings.
- </para>
-
- <para>
- To use the variable, list provider names (e.g.
- recipe names, <filename>virtual/kernel</filename>,
- and so forth).
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
-<!--
- <glossdiv id='var-glossary-n'><title>N</title>
- </glossdiv>
--->
-
- <glossdiv id='var-bb-glossary-o'><title>O</title>
-
- <glossentry id='var-bb-OVERRIDES'><glossterm>OVERRIDES</glossterm>
- <glossdef>
- <para>
- BitBake uses <filename>OVERRIDES</filename> to control
- what variables are overridden after BitBake parses
- recipes and configuration files.
- </para>
-
- <para>
- Following is a simple example that uses an overrides
- list based on machine architectures:
- <literallayout class='monospaced'>
- OVERRIDES = "arm:x86:mips:powerpc"
- </literallayout>
- You can find information on how to use
- <filename>OVERRIDES</filename> in the
- "<link linkend='conditional-syntax-overrides'>Conditional Syntax (Overrides)</link>"
- section.
- </para>
- </glossdef>
- </glossentry>
- </glossdiv>
-
- <glossdiv id='var-bb-glossary-p'><title>P</title>
-
- <glossentry id='var-bb-P4DIR'><glossterm>P4DIR</glossterm>
- <glossdef>
- <para>
- The directory in which a local copy of a Perforce depot
- is stored when it is fetched.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-PACKAGES'><glossterm>PACKAGES</glossterm>
- <glossdef>
- <para>The list of packages the recipe creates.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm>
- <glossdef>
- <para>
- A promise that your recipe satisfies runtime dependencies
- for optional modules that are found in other recipes.
- <filename>PACKAGES_DYNAMIC</filename>
- does not actually satisfy the dependencies, it only states that
- they should be satisfied.
- For example, if a hard, runtime dependency
- (<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
- produced, then the other package will be broken.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-PE'><glossterm>PE</glossterm>
- <glossdef>
- <para>
- The epoch of the recipe.
- By default, this variable is unset.
- The variable is used to make upgrades possible when the
- versioning scheme changes in some backwards incompatible
- way.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-PERSISTENT_DIR'><glossterm>PERSISTENT_DIR</glossterm>
- <glossdef>
- <para>
- Specifies the directory BitBake uses to store data that
- should be preserved between builds.
- In particular, the data stored is the data that uses
- BitBake's persistent data API and the data used by the
- PR Server and PR Service.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-PF'><glossterm>PF</glossterm>
- <glossdef>
- <para>
- Specifies the recipe or package name and includes all version and revision
- numbers (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
- <filename>bash-4.2-r1/</filename>).
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-PN'><glossterm>PN</glossterm>
- <glossdef>
- <para>The recipe name.</para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-PR'><glossterm>PR</glossterm>
- <glossdef>
- <para>The revision of the recipe.
- </para>
- </glossdef>
- </glossentry>
-
- <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-bb-PN'><filename>PN</filename></link>
- of the recipe to which you want to give precedence.
- Some examples:
- <literallayout class='monospaced'>
- PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
- PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
- PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
- </literallayout>
- </para>
- </glossdef>
- </glossentry>
-
- <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-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:
- <literallayout class='monospaced'>
- PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..."
- </literallayout>
- This form is a convenient replacement for the following:
- <literallayout class='monospaced'>
- PREFERRED_PROVIDER_xxx = "yyy"
- PREFERRED_PROVIDER_aaa = "bbb"
- </literallayout>
- </para>
- </glossdef>
- </glossentry>
-
- <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-bb-PN'><filename>PN</filename></link>
- you want to select, and you should set
- <link linkend='var-bb-PV'><filename>PV</filename></link>
- accordingly for precedence.
- </para>
-
- <para>
- The <filename>PREFERRED_VERSION</filename> variable
- supports limited wildcard use through the
- "<filename>%</filename>" character.
- You can use the character to match any number of
- characters, which can be useful when specifying versions
- that contain long revision numbers that potentially change.
- Here are two examples:
- <literallayout class='monospaced'>
- PREFERRED_VERSION_python = "2.7.3"
- PREFERRED_VERSION_linux-yocto = "4.12%"
- </literallayout>
- <note><title>Important</title>
- The use of the "<filename>%</filename>" character
- is limited in that it only works at the end of the
- string.
- You cannot use the wildcard character in any other
- location of the string.
- </note>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-PREMIRRORS'><glossterm>PREMIRRORS</glossterm>
- <glossdef>
- <para>
- Specifies additional paths from which BitBake gets source code.
- When the build system searches for source code, it first
- tries the local download directory.
- 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-bb-MIRRORS'><filename>MIRRORS</filename></link>
- in that order.
- </para>
-
- <para>
- Typically, you would add a specific server for the
- build system to attempt before any others by adding
- something like the following to your configuration:
- <literallayout class='monospaced'>
- PREMIRRORS_prepend = "\
- git://.*/.* http://www.yoctoproject.org/sources/ \n \
- ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
- http://.*/.* http://www.yoctoproject.org/sources/ \n \
- https://.*/.* http://www.yoctoproject.org/sources/ \n"
- </literallayout>
- These changes cause the build system to intercept
- Git, FTP, HTTP, and HTTPS requests and direct them to
- the <filename>http://</filename> sources mirror.
- You can use <filename>file://</filename> URLs to point
- to local directories or network shares as well.
- </para>
- </glossdef>
- </glossentry>
-
- <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-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-bb-DEPENDS'>DEPENDS</link></filename>.
- </para>
-
- <para>
- Consider the following example
- <filename>PROVIDES</filename> statement from a recipe
- file <filename>libav_0.8.11.bb</filename>:
- <literallayout class='monospaced'>
- PROVIDES += "libpostproc"
- </literallayout>
- The <filename>PROVIDES</filename> statement results in
- the "libav" recipe also being known as "libpostproc".
- </para>
-
- <para>
- In addition to providing recipes under alternate names,
- the <filename>PROVIDES</filename> mechanism is also used
- to implement virtual targets.
- A virtual target is a name that corresponds to some
- particular functionality (e.g. a Linux kernel).
- Recipes that provide the functionality in question list the
- virtual target in <filename>PROVIDES</filename>.
- Recipes that depend on the functionality in question can
- include the virtual target in
- <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link>
- to leave the choice of provider open.
- </para>
-
- <para>
- Conventionally, virtual targets have names on the form
- "virtual/function" (e.g. "virtual/kernel").
- The slash is simply part of the name and has no
- syntactical significance.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-PRSERV_HOST'><glossterm>PRSERV_HOST</glossterm>
- <glossdef>
- <para>
- The network based
- <link linkend='var-bb-PR'><filename>PR</filename></link>
- service host and port.
- </para>
-
- <para>
- Following is an example of how the <filename>PRSERV_HOST</filename> variable is
- set:
- <literallayout class='monospaced'>
- PRSERV_HOST = "localhost:0"
- </literallayout>
- You must set the variable if you want to automatically
- start a local PR service.
- You can set <filename>PRSERV_HOST</filename> to other
- values to use a remote PR service.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-PV'><glossterm>PV</glossterm>
- <glossdef>
- <para>The version of the recipe.
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
-<!--
- <glossdiv id='var-glossary-q'><title>Q</title>
- </glossdiv>
--->
-
- <glossdiv id='var-bb-glossary-r'><title>R</title>
-
- <glossentry id='var-bb-RDEPENDS'><glossterm>RDEPENDS</glossterm>
- <glossdef>
- <para>
- Lists a package's runtime dependencies (i.e. other packages)
- that must be installed in order for the built package to run
- correctly.
- If a package in this list cannot be found during the build,
- you will get a build error.
- </para>
-
- <para>
- Because the <filename>RDEPENDS</filename> variable applies
- to packages being built, you should always use the variable
- in a form with an attached package name.
- For example, suppose you are building a development package
- that depends on the <filename>perl</filename> package.
- In this case, you would use the following
- <filename>RDEPENDS</filename> statement:
- <literallayout class='monospaced'>
- RDEPENDS_${PN}-dev += "perl"
- </literallayout>
- In the example, the development package depends on
- the <filename>perl</filename> package.
- Thus, the <filename>RDEPENDS</filename> variable has the
- <filename>${PN}-dev</filename> package name as part of the
- variable.
- </para>
-
- <para>
- BitBake supports specifying versioned dependencies.
- Although the syntax varies depending on the packaging
- format, BitBake hides these differences from you.
- Here is the general syntax to specify versions with
- the <filename>RDEPENDS</filename> variable:
- <literallayout class='monospaced'>
- RDEPENDS_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)"
- </literallayout>
- For <filename>operator</filename>, you can specify the
- following:
- <literallayout class='monospaced'>
- =
- &lt;
- &gt;
- &lt;=
- &gt;=
- </literallayout>
- For example, the following sets up a dependency on version
- 1.2 or greater of the package <filename>foo</filename>:
- <literallayout class='monospaced'>
- RDEPENDS_${PN} = "foo (>= 1.2)"
- </literallayout>
- </para>
-
- <para>
- For information on build-time dependencies, see the
- <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link>
- variable.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-REPODIR'><glossterm>REPODIR</glossterm>
- <glossdef>
- <para>
- The directory in which a local copy of a
- <filename>google-repo</filename> directory is stored
- when it is synced.
- </para>
- </glossdef>
- </glossentry>
-
- <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-bb-RDEPENDS'>RDEPENDS</link></filename>).
- </para>
- <para>
- As with all package-controlling variables, you must always
- use the variable in conjunction with a package name override.
- Here is an example:
- <literallayout class='monospaced'>
- RPROVIDES_${PN} = "widget-abi-2"
- </literallayout>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
- <glossdef>
- <para>
- A list of packages that extends the usability of a package
- being built.
- The package being built does not depend on this list of
- 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-bb-RDEPENDS'>RDEPENDS</link></filename>
- variable.
- </para>
-
- <para>
- BitBake supports specifying versioned recommends.
- Although the syntax varies depending on the packaging
- format, BitBake hides these differences from you.
- Here is the general syntax to specify versions with
- the <filename>RRECOMMENDS</filename> variable:
- <literallayout class='monospaced'>
- RRECOMMENDS_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)"
- </literallayout>
- For <filename>operator</filename>, you can specify the
- following:
- <literallayout class='monospaced'>
- =
- &lt;
- &gt;
- &lt;=
- &gt;=
- </literallayout>
- For example, the following sets up a recommend on version
- 1.2 or greater of the package <filename>foo</filename>:
- <literallayout class='monospaced'>
- RRECOMMENDS_${PN} = "foo (>= 1.2)"
- </literallayout>
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
- <glossdiv id='var-bb-glossary-s'><title>S</title>
-
- <glossentry id='var-bb-SECTION'><glossterm>SECTION</glossterm>
- <glossdef>
- <para>The section in which packages should be categorized.</para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-SRC_URI'><glossterm>SRC_URI</glossterm>
- <glossdef>
- <para>
- The list of source files - local or remote.
- This variable tells BitBake which bits
- to pull for the build and how to pull them.
- For example, if the recipe or append file needs to
- fetch a single tarball from the Internet, the recipe or
- append file uses a <filename>SRC_URI</filename>
- entry that specifies that tarball.
- On the other hand, if the recipe or append file needs to
- fetch a tarball and include a custom file, the recipe or
- append file needs an <filename>SRC_URI</filename> variable
- that specifies all those sources.</para>
- <para>The following list explains the available URI protocols:
- <itemizedlist>
- <listitem><para><emphasis><filename>file://</filename> -</emphasis>
- Fetches files, which are usually files shipped with
- the metadata,
- from the local machine.
- The path is relative to the
- <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>
- <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
- Git revision control repository.</para></listitem>
- <listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from
- an OSC (OpenSUSE Build service) revision control repository.</para></listitem>
- <listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from
- a repo (Git) repository.</para></listitem>
- <listitem><para><emphasis><filename>http://</filename> -</emphasis> Fetches files from
- the Internet using HTTP.</para></listitem>
- <listitem><para><emphasis><filename>https://</filename> -</emphasis> Fetches files
- from the Internet using HTTPS.</para></listitem>
- <listitem><para><emphasis><filename>ftp://</filename> -</emphasis> Fetches files
- from the Internet using FTP.</para></listitem>
- <listitem><para><emphasis><filename>cvs://</filename> -</emphasis> Fetches files from
- a CVS revision control repository.</para></listitem>
- <listitem><para><emphasis><filename>hg://</filename> -</emphasis> Fetches files from
- a Mercurial (<filename>hg</filename>) revision control repository.</para></listitem>
- <listitem><para><emphasis><filename>p4://</filename> -</emphasis> Fetches files from
- a Perforce (<filename>p4</filename>) revision control repository.</para></listitem>
- <listitem><para><emphasis><filename>ssh://</filename> -</emphasis> Fetches files from
- a secure shell.</para></listitem>
- <listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from
- a Subversion (<filename>svn</filename>) revision control repository.</para></listitem>
- </itemizedlist>
- </para>
- <para>Here are some additional options worth mentioning:
- <itemizedlist>
- <listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls
- whether or not to unpack the file if it is an archive.
- The default action is to unpack the file.</para></listitem>
- <listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file
- (or extracts its contents) into the specified
- subdirectory.
- This option is useful for unusual tarballs or other archives that
- do not have their files already in a subdirectory within the archive.
- </para></listitem>
- <listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a
- name to be used for association with <filename>SRC_URI</filename> checksums
- when you have more than one file specified in <filename>SRC_URI</filename>.
- </para></listitem>
- <listitem><para><emphasis><filename>downloadfilename</filename> -</emphasis> Specifies
- the filename used when storing the downloaded file.</para></listitem>
- </itemizedlist>
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-SRCDATE'><glossterm>SRCDATE</glossterm>
- <glossdef>
- <para>
- The date of the source code used to build the package.
- This variable applies only if the source was fetched from a Source Code Manager (SCM).
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-SRCREV'><glossterm>SRCREV</glossterm>
- <glossdef>
- <para>
- The revision of the source code used to build the package.
- This variable applies only when using Subversion, Git, Mercurial and Bazaar.
- If you want to build a fixed revision and you want
- to avoid performing a query on the remote repository every time
- BitBake parses your recipe, you should specify a <filename>SRCREV</filename> that is a
- full revision identifier and not just a tag.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-SRCREV_FORMAT'><glossterm>SRCREV_FORMAT</glossterm>
- <glossdef>
- <para>
- Helps construct valid
- <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link>
- values when multiple source controlled URLs are used in
- <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>.
- </para>
-
- <para>
- The system needs help constructing these values under these
- circumstances.
- Each component in the <filename>SRC_URI</filename>
- is assigned a name and these are referenced
- in the <filename>SRCREV_FORMAT</filename> variable.
- Consider an example with URLs named "machine" and "meta".
- In this case, <filename>SRCREV_FORMAT</filename> could look
- like "machine_meta" and those names would have the SCM
- versions substituted into each position.
- Only one <filename>AUTOINC</filename> placeholder is added
- and if needed.
- And, this placeholder is placed at the start of the
- returned string.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-STAMP'><glossterm>STAMP</glossterm>
- <glossdef>
- <para>
- Specifies the base path used to create recipe stamp files.
- The path to an actual stamp file is constructed by evaluating this
- string and then appending additional information.
- </para>
- </glossdef>
- </glossentry>
-
- <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-bb-STAMP'><filename>STAMP</filename></link>
- variable, <filename>STAMPCLEAN</filename> can contain
- wildcards to match the range of files a clean operation
- should remove.
- BitBake uses a clean operation to remove any other stamps
- it should be removing when creating a new stamp.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-SUMMARY'><glossterm>SUMMARY</glossterm>
- <glossdef>
- <para>
- A short summary for the recipe, which is 72 characters or less.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-SVNDIR'><glossterm>SVNDIR</glossterm>
- <glossdef>
- <para>
- The directory in which files checked out of a Subversion
- system are stored.
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
- <glossdiv id='var-bb-glossary-t'><title>T</title>
-
- <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
- scripts, when building a particular recipe.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-bb-TOPDIR'><glossterm>TOPDIR</glossterm>
- <glossdef>
- <para>
- Points to the build directory.
- BitBake automatically sets this variable.
- </para>
- </glossdef>
- </glossentry>
-
- </glossdiv>
-
-<!--
- <glossdiv id='var-glossary-u'><title>U</title>
- </glossdiv>
-
- <glossdiv id='var-glossary-v'><title>V</title>
- </glossdiv>
-
- <glossdiv id='var-glossary-w'><title>W</title>
- </glossdiv>
-
- <glossdiv id='var-glossary-x'><title>X</title>
- </glossdiv>
-
- <glossdiv id='var-glossary-y'><title>Y</title>
- </glossdiv>
-
- <glossdiv id='var-glossary-z'><title>Z</title>
- </glossdiv>
--->
-
-
-</glossary>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->