summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNicolas Dechesne <nicolas.dechesne@linaro.org>2020-10-05 16:38:15 +0200
committerNicolas Dechesne <nicolas.dechesne@linaro.org>2020-10-05 16:38:15 +0200
commit427721d8ff2c8e1db8cb490074f2eed88d03852a (patch)
tree6efede9fbca94f2263acc09d3b55ad0aeedc2115
parentd52190ea426d961f609c657dcb403baf59352969 (diff)
downloadbitbake-427721d8ff2c8e1db8cb490074f2eed88d03852a.tar.gz
sphinx: remove DocBook files
The BitBake documentation was migrated to Sphinx. Let's remove the deprecated DocBook files. Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
-rw-r--r--doc/Makefile91
-rw-r--r--doc/bitbake-user-manual/bitbake-user-manual-customization.xsl29
-rw-r--r--doc/bitbake-user-manual/bitbake-user-manual-execution.xml1029
-rw-r--r--doc/bitbake-user-manual/bitbake-user-manual-fetching.xml928
-rw-r--r--doc/bitbake-user-manual/bitbake-user-manual-hello.xml513
-rw-r--r--doc/bitbake-user-manual/bitbake-user-manual-intro.xml891
-rw-r--r--doc/bitbake-user-manual/bitbake-user-manual-metadata.xml2862
-rw-r--r--doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml2537
-rw-r--r--doc/bitbake-user-manual/bitbake-user-manual-style.css984
-rw-r--r--doc/bitbake-user-manual/bitbake-user-manual.xml88
-rw-r--r--doc/bitbake-user-manual/html.css281
-rw-r--r--doc/poky.ent51
-rw-r--r--doc/template/Vera.xml1
-rw-r--r--doc/template/VeraMoBd.xml1
-rw-r--r--doc/template/VeraMono.xml1
-rw-r--r--doc/template/component.title.xsl39
-rw-r--r--doc/template/db-pdf.xsl64
-rw-r--r--doc/template/division.title.xsl25
-rw-r--r--doc/template/fop-config.xml58
-rw-r--r--doc/template/formal.object.heading.xsl21
-rw-r--r--doc/template/gloss-permalinks.xsl14
-rw-r--r--doc/template/permalinks.xsl25
-rw-r--r--doc/template/section.title.xsl55
-rw-r--r--doc/template/titlepage.templates.xml1259
-rwxr-xr-xdoc/tools/docbook-to-pdf51
25 files changed, 0 insertions, 11898 deletions
diff --git a/doc/Makefile b/doc/Makefile
deleted file mode 100644
index 3c28f4b22..000000000
--- a/doc/Makefile
+++ /dev/null
@@ -1,91 +0,0 @@
-# This is a single Makefile to handle all generated BitBake documents.
-# The Makefile needs to live in the documentation directory and all figures used
-# in any manuals must be .PNG files and live in the individual book's figures
-# directory.
-#
-# The Makefile has these targets:
-#
-# pdf: generates a PDF version of a manual.
-# html: generates an HTML version of a manual.
-# tarball: creates a tarball for the doc files.
-# validate: validates
-# clean: removes files
-#
-# The Makefile generates an HTML version of every document. The
-# variable DOC indicates the folder name for a given manual.
-#
-# To build a manual, you must invoke 'make' with the DOC argument.
-#
-# Examples:
-#
-# make DOC=bitbake-user-manual
-# make pdf DOC=bitbake-user-manual
-#
-# The first example generates the HTML version of the User Manual.
-# The second example generates the PDF version of the User Manual.
-#
-
-ifeq ($(DOC),bitbake-user-manual)
-XSLTOPTS = --stringparam html.stylesheet bitbake-user-manual-style.css \
- --stringparam chapter.autolabel 1 \
- --stringparam section.autolabel 1 \
- --stringparam section.label.includes.component.label 1 \
- --xinclude
-ALLPREQ = html tarball
-TARFILES = bitbake-user-manual-style.css bitbake-user-manual.html figures/bitbake-title.png
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-
-endif
-
-##
-# These URI should be rewritten by your distribution's xml catalog to
-# match your localy installed XSL stylesheets.
-XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current
-XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
-
-all: $(ALLPREQ)
-
-pdf:
-ifeq ($(DOC),bitbake-user-manual)
- @echo " "
- @echo "********** Building."$(DOC)
- @echo " "
- cd $(DOC); ../tools/docbook-to-pdf $(DOC).xml ../template; cd ..
-endif
-
-html:
-ifeq ($(DOC),bitbake-user-manual)
-# See http://www.sagehill.net/docbookxsl/HtmlOutput.html
- @echo " "
- @echo "******** Building "$(DOC)
- @echo " "
- cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd ..
-endif
-
-tarball: html
- @echo " "
- @echo "******** Creating Tarball of document files"
- @echo " "
- cd $(DOC); tar -cvzf $(DOC).tgz $(TARFILES); cd ..
-
-validate:
- cd $(DOC); xmllint --postvalid --xinclude --noout $(DOC).xml; cd ..
-
-publish:
- @if test -f $(DOC)/$(DOC).html; \
- then \
- echo " "; \
- echo "******** Publishing "$(DOC)".html"; \
- echo " "; \
- scp -r $(MANUALS) $(STYLESHEET) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
- cd $(DOC); scp -r $(FIGURES) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
- else \
- echo " "; \
- echo $(DOC)".html missing. Generate the file first then try again."; \
- echo " "; \
- fi
-
-clean:
- rm -rf $(MANUALS); rm $(DOC)/$(DOC).tgz;
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-customization.xsl b/doc/bitbake-user-manual/bitbake-user-manual-customization.xsl
deleted file mode 100644
index 5985ea783..000000000
--- a/doc/bitbake-user-manual/bitbake-user-manual-customization.xsl
+++ /dev/null
@@ -1,29 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
-
- <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-<!--
-
- <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
- <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-
--->
-
- <xsl:include href="../template/permalinks.xsl"/>
- <xsl:include href="../template/section.title.xsl"/>
- <xsl:include href="../template/component.title.xsl"/>
- <xsl:include href="../template/division.title.xsl"/>
- <xsl:include href="../template/formal.object.heading.xsl"/>
- <xsl:include href="../template/gloss-permalinks.xsl"/>
-
- <xsl:param name="html.stylesheet" select="'user-manual-style.css'" />
- <xsl:param name="chapter.autolabel" select="1" />
- <xsl:param name="section.autolabel" select="1" />
- <xsl:param name="section.label.includes.component.label" select="1" />
- <xsl:param name="appendix.autolabel">A</xsl:param>
-
-<!-- <xsl:param name="generate.toc" select="'article nop'"></xsl:param> -->
-
-</xsl:stylesheet>
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-execution.xml b/doc/bitbake-user-manual/bitbake-user-manual-execution.xml
deleted file mode 100644
index 04c5a26b9..000000000
--- a/doc/bitbake-user-manual/bitbake-user-manual-execution.xml
+++ /dev/null
@@ -1,1029 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id="bitbake-user-manual-execution">
- <title>Execution</title>
-
- <para>
- The primary purpose for running BitBake is to produce some kind
- of output such as a single installable package, a kernel, a software
- development kit, or even a full, board-specific bootable Linux image,
- complete with bootloader, kernel, and root filesystem.
- Of course, you can execute the <filename>bitbake</filename>
- command with options that cause it to execute single tasks,
- compile single recipe files, capture or clear data, or simply
- return information about the execution environment.
- </para>
-
- <para>
- This chapter describes BitBake's execution process from start
- to finish when you use it to create an image.
- The execution process is launched using the following command
- form:
- <literallayout class='monospaced'>
- $ bitbake <replaceable>target</replaceable>
- </literallayout>
- For information on the BitBake command and its options,
- see
- "<link linkend='bitbake-user-manual-command'>The BitBake Command</link>"
- section.
- <note>
- <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-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
- variable in your project's <filename>local.conf</filename>
- configuration file.
- </para>
-
- <para>
- A common method to determine this value for your build host is to run
- the following:
- <literallayout class='monospaced'>
- $ grep processor /proc/cpuinfo
- </literallayout>
- This command returns the number of processors, which takes into
- account hyper-threading.
- Thus, a quad-core build host with hyper-threading most likely
- shows eight processors, which is the value you would then assign to
- <filename>BB_NUMBER_THREADS</filename>.
- </para>
-
- <para>
- A possibly simpler solution is that some Linux distributions
- (e.g. Debian and Ubuntu) provide the <filename>ncpus</filename> command.
- </para>
- </note>
- </para>
-
- <section id='parsing-the-base-configuration-metadata'>
- <title>Parsing the Base Configuration Metadata</title>
-
- <para>
- The first thing BitBake does is parse base configuration
- metadata.
- Base configuration metadata consists of your project's
- <filename>bblayers.conf</filename> file to determine what
- layers BitBake needs to recognize, all necessary
- <filename>layer.conf</filename> files (one from each layer),
- and <filename>bitbake.conf</filename>.
- The data itself is of various types:
- <itemizedlist>
- <listitem><para><emphasis>Recipes:</emphasis>
- Details about particular pieces of software.
- </para></listitem>
- <listitem><para><emphasis>Class Data:</emphasis>
- An abstraction of common build information
- (e.g. how to build a Linux kernel).
- </para></listitem>
- <listitem><para><emphasis>Configuration Data:</emphasis>
- Machine-specific settings, policy decisions,
- and so forth.
- Configuration data acts as the glue to bind everything
- together.</para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- The <filename>layer.conf</filename> files are used to
- construct key variables such as
- <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link>
- and
- <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>
- directories, respectively.
- <filename>BBFILES</filename> is used to locate both recipe
- and recipe append files
- (<filename>.bb</filename> and <filename>.bbappend</filename>).
- If there is no <filename>bblayers.conf</filename> file,
- it is assumed the user has set the <filename>BBPATH</filename>
- and <filename>BBFILES</filename> directly in the environment.
- </para>
-
- <para>
- Next, the <filename>bitbake.conf</filename> file is located
- using the <filename>BBPATH</filename> variable that was
- just constructed.
- The <filename>bitbake.conf</filename> file may also include other
- configuration files using the
- <filename>include</filename> or
- <filename>require</filename> directives.
- </para>
-
- <para>
- Prior to parsing configuration files, BitBake looks
- at certain variables, including:
- <itemizedlist>
- <listitem><para>
- <link linkend='var-bb-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link>
- </para></listitem>
- <listitem><para>
- <link linkend='var-bb-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link>
- </para></listitem>
- <listitem><para>
- <link linkend='var-bb-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link>
- </para></listitem>
- <listitem><para>
- <link linkend='var-bb-BB_ORIGENV'><filename>BB_ORIGENV</filename></link>
- </para></listitem>
- <listitem><para>
- <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
- environment variables during task execution.
- By default, BitBake cleans the environment variables and provides tight
- control over the shell execution environment.
- However, through the use of these first four variables, you can
- apply your control regarding the
- environment variables allowed to be used by BitBake in the shell
- during execution of tasks.
- See the
- "<link linkend='passing-information-into-the-build-task-environment'>Passing Information Into the Build Task Environment</link>"
- section and the information about these variables in the
- variable glossary for more information on how they work and
- on how to use them.
- </para>
-
- <para>
- The base configuration metadata is global
- and therefore affects all recipes and tasks that are executed.
- </para>
-
- <para>
- 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-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>
- and <filename>BBFILES</filename> variables directly in the environment.
- </para>
-
- <para>
- For each directory (layer) in this list, a <filename>conf/layer.conf</filename>
- file is located and parsed with the
- <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-bb-BBPATH'><filename>BBPATH</filename></link>
- and other variables correctly for a given build directory.
- </para>
-
- <para>
- BitBake then expects to find the <filename>conf/bitbake.conf</filename>
- file somewhere in the user-specified <filename>BBPATH</filename>.
- That configuration file generally has include directives to pull
- in any other metadata such as files specific to the architecture,
- the machine, the local environment, and so forth.
- </para>
-
- <para>
- Only variable definitions and include directives are allowed
- in BitBake <filename>.conf</filename> files.
- Some variables directly influence BitBake's behavior.
- These variables might have been set from the environment
- depending on the environment variables previously
- mentioned or set in the configuration files.
- The
- "<link linkend='ref-bb-variables-glos'>Variables Glossary</link>"
- chapter presents a full list of variables.
- </para>
-
- <para>
- After parsing configuration files, BitBake uses its rudimentary
- inheritance mechanism, which is through class files, to inherit
- some standard classes.
- BitBake parses a class when the inherit directive responsible
- for getting that class is encountered.
- </para>
-
- <para>
- The <filename>base.bbclass</filename> file is always included.
- Other classes that are specified in the configuration using the
- <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
- the paths in <filename>BBPATH</filename> in the same way as
- configuration files.
- </para>
-
- <para>
- A good way to get an idea of the configuration files and
- the class files used in your execution environment is to
- run the following BitBake command:
- <literallayout class='monospaced'>
- $ bitbake -e > mybb.log
- </literallayout>
- Examining the top of the <filename>mybb.log</filename>
- shows you the many configuration files and class files
- used in your execution environment.
- </para>
-
- <note>
- <para>
- You need to be aware of how BitBake parses curly braces.
- If a recipe uses a closing curly brace within the function and
- the character has no leading spaces, BitBake produces a parsing
- error.
- If you use a pair of curly braces in a shell function, the
- closing curly brace must not be located at the start of the line
- without leading spaces.
- </para>
-
- <para>
- Here is an example that causes BitBake to produce a parsing
- error:
- <literallayout class='monospaced'>
- fakeroot create_shar() {
- cat &lt;&lt; "EOF" &gt; ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
- usage()
- {
- echo "test"
- ###### The following "}" at the start of the line causes a parsing error ######
- }
- EOF
- }
- </literallayout>
- Writing the recipe this way avoids the error:
- <literallayout class='monospaced'>
- fakeroot create_shar() {
- cat &lt;&lt; "EOF" &gt; ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
- usage()
- {
- echo "test"
- ######The following "}" with a leading space at the start of the line avoids the error ######
- }
- EOF
- }
- </literallayout>
- </para>
- </note>
- </section>
-
- <section id='locating-and-parsing-recipes'>
- <title>Locating and Parsing Recipes</title>
-
- <para>
- During the configuration phase, BitBake will have set
- <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.
- <filename>BBFILES</filename> is a space-separated list of
- available files and supports wildcards.
- An example would be:
- <literallayout class='monospaced'>
- BBFILES = "/path/to/bbfiles/*.bb /path/to/appends/*.bbappend"
- </literallayout>
- BitBake parses each recipe and append file located
- with <filename>BBFILES</filename> and stores the values of
- various variables into the datastore.
- <note>
- Append files are applied in the order they are encountered in
- <filename>BBFILES</filename>.
- </note>
- For each file, a fresh copy of the base configuration is
- made, then the recipe is parsed line by line.
- Any inherit statements cause BitBake to find and
- then parse class files (<filename>.bbclass</filename>)
- using
- <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>.
- </para>
-
- <para>
- One common convention is to use the recipe filename to define
- pieces of metadata.
- For example, in <filename>bitbake.conf</filename> the recipe
- name and version are used to set the variables
- <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'}"
- </literallayout>
- In this example, a recipe called "something_1.2.3.bb" would set
- <filename>PN</filename> to "something" and
- <filename>PV</filename> to "1.2.3".
- </para>
-
- <para>
- By the time parsing is complete for a recipe, BitBake
- has a list of tasks that the recipe defines and a set of
- data consisting of keys and values as well as
- dependency information about the tasks.
- </para>
-
- <para>
- BitBake does not need all of this information.
- It only needs a small subset of the information to make
- decisions about the recipe.
- Consequently, BitBake caches the values in which it is
- interested and does not store the rest of the information.
- Experience has shown it is faster to re-parse the metadata than to
- try and write it out to the disk and then reload it.
- </para>
-
- <para>
- Where possible, subsequent BitBake commands reuse this cache of
- recipe information.
- The validity of this cache is determined by first computing a
- checksum of the base configuration data (see
- <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
- the cache.
- BitBake then reloads the cached information about the recipe
- instead of reparsing it from scratch.
- </para>
-
- <para>
- Recipe file collections exist to allow the user to
- have multiple repositories of
- <filename>.bb</filename> files that contain the same
- exact package.
- For example, one could easily use them to make one's
- own local copy of an upstream repository, but with
- custom modifications that one does not want upstream.
- Here is an example:
- <literallayout class='monospaced'>
- BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb"
- BBFILE_COLLECTIONS = "upstream local"
- BBFILE_PATTERN_upstream = "^/stuff/openembedded/"
- BBFILE_PATTERN_local = "^/stuff/openembedded.modified/"
- BBFILE_PRIORITY_upstream = "5"
- BBFILE_PRIORITY_local = "10"
- </literallayout>
- <note>
- The layers mechanism is now the preferred method of collecting
- code.
- While the collections code remains, its main use is to set layer
- priorities and to deal with overlap (conflicts) between layers.
- </note>
- </para>
- </section>
-
- <section id='bb-bitbake-providers'>
- <title>Providers</title>
-
- <para>
- Assuming BitBake has been instructed to execute a target
- and that all the recipe files have been parsed, BitBake
- starts to figure out how to build the target.
- BitBake looks through the <filename>PROVIDES</filename> list
- for each of the recipes.
- A <filename>PROVIDES</filename> list is the list of names by which
- the recipe can be known.
- Each recipe's <filename>PROVIDES</filename> list is created
- implicitly through the recipe's
- <link linkend='var-bb-PN'><filename>PN</filename></link> variable
- and explicitly through the recipe's
- <link linkend='var-bb-PROVIDES'><filename>PROVIDES</filename></link>
- variable, which is optional.
- </para>
-
- <para>
- When a recipe uses <filename>PROVIDES</filename>, that recipe's
- functionality can be found under an alternative name or names other
- than the implicit <filename>PN</filename> name.
- As an example, suppose a recipe named <filename>keyboard_1.0.bb</filename>
- contained the following:
- <literallayout class='monospaced'>
- PROVIDES += "fullkeyboard"
- </literallayout>
- The <filename>PROVIDES</filename> list for this recipe becomes
- "keyboard", which is implicit, and "fullkeyboard", which is explicit.
- Consequently, the functionality found in
- <filename>keyboard_1.0.bb</filename> can be found under two
- different names.
- </para>
- </section>
-
- <section id='bb-bitbake-preferences'>
- <title>Preferences</title>
-
- <para>
- The <filename>PROVIDES</filename> list is only part of the solution
- for figuring out a target's recipes.
- Because targets might have multiple providers, BitBake needs
- to prioritize providers by determining provider preferences.
- </para>
-
- <para>
- A common example in which a target has multiple providers
- is "virtual/kernel", which is on the
- <filename>PROVIDES</filename> list for each kernel recipe.
- Each machine often selects the best kernel provider by using a
- line similar to the following in the machine configuration file:
- <literallayout class='monospaced'>
- PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
- </literallayout>
- The default
- <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
- resolves them and their dependencies using this process.
- </para>
-
- <para>
- Understanding how providers are chosen is made complicated by the fact
- that multiple versions might exist for a given provider.
- 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-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-bb-DEFAULT_PREFERENCE'><filename>DEFAULT_PREFERENCE</filename></link>
- variable.
- </para>
-
- <para>
- By default, files have a preference of "0".
- Setting <filename>DEFAULT_PREFERENCE</filename> to "-1" makes the
- recipe unlikely to be used unless it is explicitly referenced.
- Setting <filename>DEFAULT_PREFERENCE</filename> to "1" makes it
- likely the recipe is used.
- <filename>PREFERRED_VERSION</filename> overrides any
- <filename>DEFAULT_PREFERENCE</filename> setting.
- <filename>DEFAULT_PREFERENCE</filename> is often used to mark newer
- and more experimental recipe versions until they have undergone
- sufficient testing to be considered stable.
- </para>
-
- <para>
- When there are multiple “versions” of a given recipe,
- BitBake defaults to selecting the most recent
- version, unless otherwise specified.
- If the recipe in question has a
- <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
- the repository of recipe files to specify
- their preference for the default selected version.
- Additionally, the user can specify their preferred version.
- </para>
-
- <para>
- If the first recipe is named <filename>a_1.1.bb</filename>, then the
- <link linkend='var-bb-PN'><filename>PN</filename></link> variable
- will be set to “a”, and the
- <link linkend='var-bb-PV'><filename>PV</filename></link>
- variable will be set to 1.1.
- </para>
-
- <para>
- Thus, if a recipe named <filename>a_1.2.bb</filename> exists, BitBake
- will choose 1.2 by default.
- However, if you define the following variable in a
- <filename>.conf</filename> file that BitBake parses, you
- can change that preference:
- <literallayout class='monospaced'>
- PREFERRED_VERSION_a = "1.1"
- </literallayout>
- </para>
-
- <note>
- <para>
- It is common for a recipe to provide two versions -- a stable,
- numbered (and preferred) version, and a version that is
- automatically checked out from a source code repository that
- is considered more "bleeding edge" but can be selected only
- explicitly.
- </para>
-
- <para>
- For example, in the OpenEmbedded codebase, there is a standard,
- versioned recipe file for BusyBox,
- <filename>busybox_1.22.1.bb</filename>,
- but there is also a Git-based version,
- <filename>busybox_git.bb</filename>, which explicitly contains the line
- <literallayout class='monospaced'>
- DEFAULT_PREFERENCE = "-1"
- </literallayout>
- to ensure that the numbered, stable version is always preferred
- unless the developer selects otherwise.
- </para>
- </note>
- </section>
-
- <section id='bb-bitbake-dependencies'>
- <title>Dependencies</title>
-
- <para>
- Each target BitBake builds consists of multiple tasks such as
- <filename>fetch</filename>, <filename>unpack</filename>,
- <filename>patch</filename>, <filename>configure</filename>,
- and <filename>compile</filename>.
- For best performance on multi-core systems, BitBake considers each
- task as an independent
- entity with its own set of dependencies.
- </para>
-
- <para>
- Dependencies are defined through several variables.
- You can find information about variables BitBake uses in
- 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-bb-DEPENDS'><filename>DEPENDS</filename></link> and
- <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> variables when
- calculating dependencies.
- </para>
-
- <para>
- For more information on how BitBake handles dependencies, see the
- "<link linkend='dependencies'>Dependencies</link>" section.
- </para>
- </section>
-
- <section id='ref-bitbake-tasklist'>
- <title>The Task List</title>
-
- <para>
- Based on the generated list of providers and the dependency information,
- BitBake can now calculate exactly what tasks it needs to run and in what
- order it needs to run them.
- The
- "<link linkend='executing-tasks'>Executing Tasks</link>" section has more
- information on how BitBake chooses which task to execute next.
- </para>
-
- <para>
- The build now starts with BitBake forking off threads up to the limit set in the
- <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
- exceeded.
- </para>
-
- <para>
- It is worth noting that you can greatly speed up the build time by properly setting
- the <filename>BB_NUMBER_THREADS</filename> variable.
- </para>
-
- <para>
- As each task completes, a timestamp is written to the directory specified by the
- <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.
- Currently, invalid timestamps are only considered on a per
- recipe file basis.
- So, for example, if the configure stamp has a timestamp greater than the
- compile timestamp for a given target, then the compile task would rerun.
- Running the compile task again, however, has no effect on other providers
- that depend on that target.
- </para>
-
- <para>
- The exact format of the stamps is partly configurable.
- In modern versions of BitBake, a hash is appended to the
- stamp so that if the configuration changes, the stamp becomes
- invalid and the task is automatically rerun.
- This hash, or signature used, is governed by the signature policy
- that is configured (see the
- "<link linkend='checksums'>Checksums (Signatures)</link>"
- section for information).
- It is also possible to append extra metadata to the stamp using
- the <filename>[stamp-extra-info]</filename> task flag.
- For example, OpenEmbedded uses this flag to make some tasks machine-specific.
- </para>
-
- <note>
- Some tasks are marked as "nostamp" tasks.
- No timestamp file is created when these tasks are run.
- Consequently, "nostamp" tasks are always rerun.
- </note>
-
- <para>
- For more information on tasks, see the
- "<link linkend='tasks'>Tasks</link>" section.
- </para>
- </section>
-
- <section id='executing-tasks'>
- <title>Executing Tasks</title>
-
- <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-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.<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>
-
- <para>
- For Python tasks, BitBake executes the task internally and logs
- information to the controlling terminal.
- Future versions of BitBake will write the functions to files
- similar to the way shell tasks are handled.
- Logging will be handled in a way similar to shell tasks as well.
- </para>
-
- <para>
- The order in which BitBake runs the tasks is controlled by its
- task scheduler.
- It is possible to configure the scheduler and define custom
- implementations for specific use cases.
- For more information, see these variables that control the
- behavior:
- <itemizedlist>
- <listitem><para>
- <link linkend='var-bb-BB_SCHEDULER'><filename>BB_SCHEDULER</filename></link>
- </para></listitem>
- <listitem><para>
- <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
- function.
- This is done using the <filename>[prefuncs]</filename>
- and <filename>[postfuncs]</filename> flags of the task
- that lists the functions to run.
- </para>
- </section>
-
- <section id='checksums'>
- <title>Checksums (Signatures)</title>
-
- <para>
- A checksum is a unique signature of a task's inputs.
- The signature of a task can be used to determine if a task
- needs to be run.
- Because it is a change in a task's inputs that triggers running
- the task, BitBake needs to detect all the inputs to a given task.
- For shell tasks, this turns out to be fairly easy because
- BitBake generates a "run" shell script for each task and
- it is possible to create a checksum that gives you a good idea of when
- the task's data changes.
- </para>
-
- <para>
- To complicate the problem, some things should not be included in
- the checksum.
- First, there is the actual specific build path of a given task -
- the working directory.
- It does not matter if the working directory changes because it should not
- affect the output for target packages.
- 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-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>
-
- <para>
- Another problem results from the "run" scripts containing functions that
- might or might not get called.
- The incremental build solution contains code that figures out dependencies
- between shell functions.
- This code is used to prune the "run" scripts down to the minimum set,
- thereby alleviating this problem and making the "run" scripts much more
- readable as a bonus.
- </para>
-
- <para>
- So far we have solutions for shell scripts.
- What about Python tasks?
- The same approach applies even though these tasks are more difficult.
- The process needs to figure out what variables a Python function accesses
- and what functions it calls.
- Again, the incremental build solution contains code that first figures out
- the variable and function dependencies, and then creates a checksum for the data
- used as the input to the task.
- </para>
-
- <para>
- Like the working directory case, situations exist where dependencies
- should be ignored.
- For these cases, you can instruct the build process to ignore a dependency
- by using a line like the following:
- <literallayout class='monospaced'>
- PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
- </literallayout>
- This example ensures that the <filename>PACKAGE_ARCHS</filename> variable does not
- depend on the value of <filename>MACHINE</filename>, even if it does reference it.
- </para>
-
- <para>
- Equally, there are cases where we need to add dependencies BitBake
- is not able to find.
- You can accomplish this by using a line like the following:
- <literallayout class='monospaced'>
- PACKAGE_ARCHS[vardeps] = "MACHINE"
- </literallayout>
- This example explicitly adds the <filename>MACHINE</filename> variable as a
- dependency for <filename>PACKAGE_ARCHS</filename>.
- </para>
-
- <para>
- Consider a case with in-line Python, for example, where BitBake is not
- able to figure out dependencies.
- When running in debug mode (i.e. using <filename>-DDD</filename>), BitBake
- produces output when it discovers something for which it cannot figure out
- dependencies.
- </para>
-
- <para>
- Thus far, this section has limited discussion to the direct inputs into a task.
- Information based on direct inputs is referred to as the "basehash" in the
- code.
- However, there is still the question of a task's indirect inputs - the
- things that were already built and present in the build directory.
- The checksum (or signature) for a particular task needs to add the hashes
- of all the tasks on which the particular task depends.
- Choosing which dependencies to add is a policy decision.
- However, the effect is to generate a master checksum that combines the basehash
- and the hashes of the task's dependencies.
- </para>
-
- <para>
- At the code level, there are a variety of ways both the basehash and the
- dependent task hashes can be influenced.
- Within the BitBake configuration file, we can give BitBake some extra information
- to help it construct the basehash.
- The following statement effectively results in a list of global variable
- dependency excludes - variables never included in any checksum.
- This example uses variables from OpenEmbedded to help illustrate
- the concept:
- <literallayout class='monospaced'>
- BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
- SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL \
- USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
- PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
- CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
- </literallayout>
- The previous example excludes the work directory, which is part of
- <filename>TMPDIR</filename>.
- </para>
-
- <para>
- The rules for deciding which hashes of dependent tasks to include through
- dependency chains are more complex and are generally accomplished with a
- Python function.
- The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples
- of this and also illustrates how you can insert your own policy into the system
- if so desired.
- This file defines the two basic signature generators OpenEmbedded-Core
- uses: "OEBasic" and "OEBasicHash".
- By default, there is a dummy "noop" signature handler enabled in BitBake.
- This means that behavior is unchanged from previous versions.
- <filename>OE-Core</filename> uses the "OEBasicHash" signature handler by default
- through this setting in the <filename>bitbake.conf</filename> file:
- <literallayout class='monospaced'>
- BB_SIGNATURE_HANDLER ?= "OEBasicHash"
- </literallayout>
- The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the
- "OEBasic" version but adds the task hash to the stamp files.
- 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-bb-PR'><filename>PR</filename></link>
- values, and changes to metadata automatically ripple across the build.
- </para>
-
- <para>
- It is also worth noting that the end result of these signature generators is to
- make some dependency and hash information available to the build.
- This information includes:
- <itemizedlist>
- <listitem><para><filename>BB_BASEHASH_task-</filename><replaceable>taskname</replaceable>:
- The base hashes for each task in the recipe.
- </para></listitem>
- <listitem><para><filename>BB_BASEHASH_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>:
- The base hashes for each dependent task.
- </para></listitem>
- <listitem><para><filename>BBHASHDEPS_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>:
- The task dependencies for each task.
- </para></listitem>
- <listitem><para><filename>BB_TASKHASH</filename>:
- The hash of the currently running task.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- It is worth noting that BitBake's "-S" option lets you
- 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
- itself.
- The simplest parameter to pass is "none", which causes a
- set of signature information to be written out into
- <filename>STAMPS_DIR</filename>
- corresponding to the targets specified.
- The other currently available parameter is "printdiff",
- which causes BitBake to try to establish the closest
- signature match it can (e.g. in the sstate cache) and then
- run <filename>bitbake-diffsigs</filename> over the matches
- to determine the stamps and delta where these two
- stamp trees diverge.
- <note>
- It is likely that future versions of BitBake will
- provide other signature handlers triggered through
- additional "-S" parameters.
- </note>
- </para>
-
- <para>
- You can find more information on checksum metadata in the
- "<link linkend='task-checksums-and-setscene'>Task Checksums and Setscene</link>"
- section.
- </para>
- </section>
-
- <section id='setscene'>
- <title>Setscene</title>
-
- <para>
- The setscene process enables BitBake to handle "pre-built" artifacts.
- The ability to handle and reuse these artifacts allows BitBake
- the luxury of not having to build something from scratch every time.
- Instead, BitBake can use, when possible, existing build artifacts.
- </para>
-
- <para>
- BitBake needs to have reliable data indicating whether or not an
- artifact is compatible.
- Signatures, described in the previous section, provide an ideal
- way of representing whether an artifact is compatible.
- If a signature is the same, an object can be reused.
- </para>
-
- <para>
- If an object can be reused, the problem then becomes how to
- replace a given task or set of tasks with the pre-built artifact.
- BitBake solves the problem with the "setscene" process.
- </para>
-
- <para>
- When BitBake is asked to build a given target, before building anything,
- it first asks whether cached information is available for any of the
- targets it's building, or any of the intermediate targets.
- If cached information is available, BitBake uses this information instead of
- running the main tasks.
- </para>
-
- <para>
- BitBake first calls the function defined by the
- <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
- of the tasks for which it believes in can obtain artifacts.
- </para>
-
- <para>
- Next, for each of the tasks that were returned as possibilities,
- BitBake executes a setscene version of the task that the possible
- artifact covers.
- Setscene versions of a task have the string "_setscene" appended to the
- task name.
- So, for example, the task with the name <filename>xxx</filename> has
- a setscene task named <filename>xxx_setscene</filename>.
- The setscene version of the task executes and provides the necessary
- artifacts returning either success or failure.
- </para>
-
- <para>
- As previously mentioned, an artifact can cover more than one task.
- 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-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>
-
- <para>
- Finally, after all the setscene tasks have executed, BitBake calls the
- function listed in
- <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
- of the setscene result.
- </para>
-
- <para>
- You can find more information on setscene metadata in the
- "<link linkend='task-checksums-and-setscene'>Task Checksums and Setscene</link>"
- 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/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml b/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml
deleted file mode 100644
index fe4372ade..000000000
--- a/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml
+++ /dev/null
@@ -1,928 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter>
-<title>File Download Support</title>
-
- <para>
- BitBake's fetch module is a standalone piece of library code
- that deals with the intricacies of downloading source code
- and files from remote systems.
- Fetching source code is one of the cornerstones of building software.
- As such, this module forms an important part of BitBake.
- </para>
-
- <para>
- The current fetch module is called "fetch2" and refers to the
- fact that it is the second major version of the API.
- The original version is obsolete and has been removed from the codebase.
- Thus, in all cases, "fetch" refers to "fetch2" in this
- manual.
- </para>
-
- <section id='the-download-fetch'>
- <title>The Download (Fetch)</title>
-
- <para>
- BitBake takes several steps when fetching source code or files.
- The fetcher codebase deals with two distinct processes in order:
- obtaining the files from somewhere (cached or otherwise)
- and then unpacking those files into a specific location and
- perhaps in a specific way.
- Getting and unpacking the files is often optionally followed
- by patching.
- Patching, however, is not covered by this module.
- </para>
-
- <para>
- The code to execute the first part of this process, a fetch,
- looks something like the following:
- <literallayout class='monospaced'>
- src_uri = (d.getVar('SRC_URI') or "").split()
- fetcher = bb.fetch2.Fetch(src_uri, d)
- fetcher.download()
- </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-bb-SRC_URI'><filename>SRC_URI</filename></link>
- variable and then calls the <filename>download</filename>
- method to download the files.
- </para>
-
- <para>
- The instantiation of the fetch class is usually followed by:
- <literallayout class='monospaced'>
- rootdir = l.getVar('WORKDIR')
- fetcher.unpack(rootdir)
- </literallayout>
- This code unpacks the downloaded files to the
- specified by <filename>WORKDIR</filename>.
- <note>
- For convenience, the naming in these examples matches
- the variables used by OpenEmbedded.
- If you want to see the above code in action, examine
- the OpenEmbedded class file <filename>base.bbclass</filename>.
- </note>
- The <filename>SRC_URI</filename> and <filename>WORKDIR</filename>
- variables are not hardcoded into the fetcher, since those fetcher
- methods can be (and are) called with different variable names.
- In OpenEmbedded for example, the shared state (sstate) code uses
- the fetch module to fetch the sstate files.
- </para>
-
- <para>
- When the <filename>download()</filename> method is called,
- BitBake tries to resolve the URLs by looking for source files
- in a specific search order:
- <itemizedlist>
- <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-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link>
- variable.
- </para></listitem>
- <listitem><para><emphasis>Source URI:</emphasis>
- If pre-mirrors fail, BitBake uses the original URL (e.g from
- <filename>SRC_URI</filename>).
- </para></listitem>
- <listitem><para><emphasis>Mirror Sites:</emphasis>
- If fetch failures occur, BitBake next uses mirror locations as
- defined by the
- <link linkend='var-bb-MIRRORS'><filename>MIRRORS</filename></link>
- variable.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- For each URL passed to the fetcher, the fetcher
- calls the submodule that handles that particular URL type.
- This behavior can be the source of some confusion when you
- are providing URLs for the <filename>SRC_URI</filename>
- variable.
- Consider the following two URLs:
- <literallayout class='monospaced'>
- http://git.yoctoproject.org/git/poky;protocol=git
- git://git.yoctoproject.org/git/poky;protocol=http
- </literallayout>
- In the former case, the URL is passed to the
- <filename>wget</filename> fetcher, which does not
- understand "git".
- Therefore, the latter case is the correct form since the
- Git fetcher does know how to use HTTP as a transport.
- </para>
-
- <para>
- Here are some examples that show commonly used mirror
- definitions:
- <literallayout class='monospaced'>
- PREMIRRORS ?= "\
- bzr://.*/.* http://somemirror.org/sources/ \n \
- cvs://.*/.* http://somemirror.org/sources/ \n \
- git://.*/.* http://somemirror.org/sources/ \n \
- hg://.*/.* http://somemirror.org/sources/ \n \
- osc://.*/.* http://somemirror.org/sources/ \n \
- p4://.*/.* http://somemirror.org/sources/ \n \
- svn://.*/.* http://somemirror.org/sources/ \n"
-
- MIRRORS =+ "\
- ftp://.*/.* http://somemirror.org/sources/ \n \
- http://.*/.* http://somemirror.org/sources/ \n \
- https://.*/.* http://somemirror.org/sources/ \n"
- </literallayout>
- It is useful to note that BitBake supports
- cross-URLs.
- It is possible to mirror a Git repository on an HTTP
- server as a tarball.
- This is what the <filename>git://</filename> mapping in
- the previous example does.
- </para>
-
- <para>
- 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-bb-DL_DIR'><filename>DL_DIR</filename></link>
- variable.
- </para>
-
- <para>
- File integrity is of key importance for reproducing builds.
- For non-local archive downloads, the fetcher code can verify
- SHA-256 and MD5 checksums to ensure the archives have been
- downloaded correctly.
- You can specify these checksums by using the
- <filename>SRC_URI</filename> variable with the appropriate
- varflags as follows:
- <literallayout class='monospaced'>
- SRC_URI[md5sum] = "<replaceable>value</replaceable>"
- SRC_URI[sha256sum] = "<replaceable>value</replaceable>"
- </literallayout>
- You can also specify the checksums as parameters on the
- <filename>SRC_URI</filename> as shown below:
- <literallayout class='monospaced'>
- SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"
- </literallayout>
- If multiple URIs exist, you can specify the checksums either
- directly as in the previous example, or you can name the URLs.
- The following syntax shows how you name the URIs:
- <literallayout class='monospaced'>
- SRC_URI = "http://example.com/foobar.tar.bz2;name=foo"
- SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d
- </literallayout>
- After a file has been downloaded and has had its checksum checked,
- a ".done" stamp is placed in <filename>DL_DIR</filename>.
- BitBake uses this stamp during subsequent builds to avoid
- downloading or comparing a checksum for the file again.
- <note>
- It is assumed that local storage is safe from data corruption.
- If this were not the case, there would be bigger issues to worry about.
- </note>
- </para>
-
- <para>
- If
- <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-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.
- </para>
- </section>
-
- <section id='bb-the-unpack'>
- <title>The Unpack</title>
-
- <para>
- The unpack process usually immediately follows the download.
- For all URLs except Git URLs, BitBake uses the common
- <filename>unpack</filename> method.
- </para>
-
- <para>
- A number of parameters exist that you can specify within the
- URL to govern the behavior of the unpack stage:
- <itemizedlist>
- <listitem><para><emphasis>unpack:</emphasis>
- Controls whether the URL components are unpacked.
- If set to "1", which is the default, the components
- are unpacked.
- If set to "0", the unpack stage leaves the file alone.
- This parameter is useful when you want an archive to be
- copied in and not be unpacked.
- </para></listitem>
- <listitem><para><emphasis>dos:</emphasis>
- Applies to <filename>.zip</filename> and
- <filename>.jar</filename> files and specifies whether to
- use DOS line ending conversion on text files.
- </para></listitem>
- <listitem><para><emphasis>basepath:</emphasis>
- Instructs the unpack stage to strip the specified
- directories from the source path when unpacking.
- </para></listitem>
- <listitem><para><emphasis>subdir:</emphasis>
- Unpacks the specific URL to the specified subdirectory
- within the root directory.
- </para></listitem>
- </itemizedlist>
- The unpack call automatically decompresses and extracts files
- with ".Z", ".z", ".gz", ".xz", ".zip", ".jar", ".ipk", ".rpm".
- ".srpm", ".deb" and ".bz2" extensions as well as various combinations
- of tarball extensions.
- </para>
-
- <para>
- As mentioned, the Git fetcher has its own unpack method that
- is optimized to work with Git trees.
- Basically, this method works by cloning the tree into the final
- directory.
- The process is completed using references so that there is
- only one central copy of the Git metadata needed.
- </para>
- </section>
-
- <section id='bb-fetchers'>
- <title>Fetchers</title>
-
- <para>
- As mentioned earlier, the URL prefix determines which
- fetcher submodule BitBake uses.
- Each submodule can support different URL parameters,
- which are described in the following sections.
- </para>
-
- <section id='local-file-fetcher'>
- <title>Local file fetcher (<filename>file://</filename>)</title>
-
- <para>
- This submodule handles URLs that begin with
- <filename>file://</filename>.
- 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-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-bb-DL_DIR'><filename>DL_DIR</filename></link>
- by the time the <filename>download()</filename> method is called.
- </para>
-
- <para>
- If you specify a directory, the entire directory is
- unpacked.
- </para>
-
- <para>
- Here are a couple of example URLs, the first relative and
- the second absolute:
- <literallayout class='monospaced'>
- SRC_URI = "file://relativefile.patch"
- SRC_URI = "file:///Users/ich/very_important_software"
- </literallayout>
- </para>
- </section>
-
- <section id='http-ftp-fetcher'>
- <title>HTTP/FTP wget fetcher (<filename>http://</filename>, <filename>ftp://</filename>, <filename>https://</filename>)</title>
-
- <para>
- This fetcher obtains files from web and FTP servers.
- Internally, the fetcher uses the wget utility.
- </para>
-
- <para>
- The executable and parameters used are specified by the
- <filename>FETCHCMD_wget</filename> variable, which defaults
- to sensible values.
- The fetcher supports a parameter "downloadfilename" that
- 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-bb-DL_DIR'><filename>DL_DIR</filename></link>
- when dealing with multiple files that have the same name.
- </para>
-
- <para>
- Some example URLs are as follows:
- <literallayout class='monospaced'>
- SRC_URI = "http://oe.handhelds.org/not_there.aac"
- SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac"
- SRC_URI = "ftp://you@oe.handhelds.org/home/you/secret.plan"
- </literallayout>
- </para>
- <note>
- Because URL parameters are delimited by semi-colons, this can
- introduce ambiguity when parsing URLs that also contain semi-colons,
- for example:
- <literallayout class='monospaced'>
- SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47"
- </literallayout>
- Such URLs should should be modified by replacing semi-colons with '&amp;' characters:
- <literallayout class='monospaced'>
- SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&amp;a=snapshot&amp;h=a5dd47"
- </literallayout>
- In most cases this should work. Treating semi-colons and '&amp;' in queries
- identically is recommended by the World Wide Web Consortium (W3C).
- Note that due to the nature of the URL, you may have to specify the name
- of the downloaded file as well:
- <literallayout class='monospaced'>
- SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&amp;a=snapshot&amp;h=a5dd47;downloadfilename=myfile.bz2"
- </literallayout>
- </note>
- </section>
-
- <section id='cvs-fetcher'>
- <title>CVS fetcher (<filename>(cvs://</filename>)</title>
-
- <para>
- This submodule handles checking out files from the
- CVS version control system.
- You can configure it using a number of different variables:
- <itemizedlist>
- <listitem><para><emphasis><filename>FETCHCMD_cvs</filename>:</emphasis>
- The name of the executable to use when running
- the <filename>cvs</filename> command.
- This name is usually "cvs".
- </para></listitem>
- <listitem><para><emphasis><filename>SRCDATE</filename>:</emphasis>
- The date to use when fetching the CVS source code.
- A special value of "now" causes the checkout to
- be updated on every build.
- </para></listitem>
- <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>
- <listitem><para><emphasis><filename>CVS_PROXY_HOST</filename>:</emphasis>
- The name to use as a "proxy=" parameter to the
- <filename>cvs</filename> command.
- </para></listitem>
- <listitem><para><emphasis><filename>CVS_PROXY_PORT</filename>:</emphasis>
- The port number to use as a "proxyport=" parameter to
- the <filename>cvs</filename> command.
- </para></listitem>
- </itemizedlist>
- As well as the standard username and password URL syntax,
- you can also configure the fetcher with various URL parameters:
- </para>
-
- <para>
- The supported parameters are as follows:
- <itemizedlist>
- <listitem><para><emphasis>"method":</emphasis>
- The protocol over which to communicate with the CVS
- server.
- By default, this protocol is "pserver".
- If "method" is set to "ext", BitBake examines the
- "rsh" parameter and sets <filename>CVS_RSH</filename>.
- You can use "dir" for local directories.
- </para></listitem>
- <listitem><para><emphasis>"module":</emphasis>
- Specifies the module to check out.
- You must supply this parameter.
- </para></listitem>
- <listitem><para><emphasis>"tag":</emphasis>
- Describes which CVS TAG should be used for
- the checkout.
- By default, the TAG is empty.
- </para></listitem>
- <listitem><para><emphasis>"date":</emphasis>
- Specifies a date.
- If no "date" is specified, the
- <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.
- </para></listitem>
- <listitem><para><emphasis>"localdir":</emphasis>
- Used to rename the module.
- Effectively, you are renaming the output directory
- to which the module is unpacked.
- You are forcing the module into a special
- directory relative to
- <link linkend='var-bb-CVSDIR'><filename>CVSDIR</filename></link>.
- </para></listitem>
- <listitem><para><emphasis>"rsh"</emphasis>
- Used in conjunction with the "method" parameter.
- </para></listitem>
- <listitem><para><emphasis>"scmdata":</emphasis>
- Causes the CVS metadata to be maintained in the tarball
- the fetcher creates when set to "keep".
- The tarball is expanded into the work directory.
- By default, the CVS metadata is removed.
- </para></listitem>
- <listitem><para><emphasis>"fullpath":</emphasis>
- Controls whether the resulting checkout is at the
- module level, which is the default, or is at deeper
- paths.
- </para></listitem>
- <listitem><para><emphasis>"norecurse":</emphasis>
- Causes the fetcher to only checkout the specified
- directory with no recurse into any subdirectories.
- </para></listitem>
- <listitem><para><emphasis>"port":</emphasis>
- The port to which the CVS server connects.
- </para></listitem>
- </itemizedlist>
- Some example URLs are as follows:
- <literallayout class='monospaced'>
- SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
- SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"
- </literallayout>
- </para>
- </section>
-
- <section id='svn-fetcher'>
- <title>Subversion (SVN) Fetcher (<filename>svn://</filename>)</title>
-
- <para>
- This fetcher submodule fetches code from the
- Subversion source control system.
- The executable used is specified by
- <filename>FETCHCMD_svn</filename>, which defaults
- to "svn".
- The fetcher's temporary working directory is set by
- <link linkend='var-bb-SVNDIR'><filename>SVNDIR</filename></link>,
- which is usually <filename>DL_DIR/svn</filename>.
- </para>
-
- <para>
- The supported parameters are as follows:
- <itemizedlist>
- <listitem><para><emphasis>"module":</emphasis>
- The name of the svn module to checkout.
- You must provide this parameter.
- You can think of this parameter as the top-level
- directory of the repository data you want.
- </para></listitem>
- <listitem><para><emphasis>"path_spec":</emphasis>
- A specific directory in which to checkout the
- specified svn module.
- </para></listitem>
- <listitem><para><emphasis>"protocol":</emphasis>
- The protocol to use, which defaults to "svn".
- If "protocol" is set to "svn+ssh", the "ssh"
- parameter is also used.
- </para></listitem>
- <listitem><para><emphasis>"rev":</emphasis>
- The revision of the source code to checkout.
- </para></listitem>
- <listitem><para><emphasis>"scmdata":</emphasis>
- Causes the “.svn” directories to be available during
- compile-time when set to "keep".
- By default, these directories are removed.
- </para></listitem>
- <listitem><para><emphasis>"ssh":</emphasis>
- An optional parameter used when "protocol" is set
- to "svn+ssh".
- You can use this parameter to specify the ssh
- program used by svn.
- </para></listitem>
- <listitem><para><emphasis>"transportuser":</emphasis>
- When required, sets the username for the transport.
- By default, this parameter is empty.
- The transport username is different than the username
- used in the main URL, which is passed to the subversion
- command.
- </para></listitem>
- </itemizedlist>
- Following are three examples using svn:
- <literallayout class='monospaced'>
- SRC_URI = "svn://myrepos/proj1;module=vip;protocol=http;rev=667"
- SRC_URI = "svn://myrepos/proj1;module=opie;protocol=svn+ssh"
- SRC_URI = "svn://myrepos/proj1;module=trunk;protocol=http;path_spec=${MY_DIR}/proj1"
- </literallayout>
- </para>
- </section>
-
- <section id='git-fetcher'>
- <title>Git Fetcher (<filename>git://</filename>)</title>
-
- <para>
- This fetcher submodule fetches code from the Git
- source control system.
- The fetcher works by creating a bare clone of the
- remote into
- <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.
- This is done using alternates and by reference to
- minimize the amount of duplicate data on the disk and
- make the unpack process fast.
- The executable used can be set with
- <filename>FETCHCMD_git</filename>.
- </para>
-
- <para>
- This fetcher supports the following parameters:
- <itemizedlist>
- <listitem><para><emphasis>"protocol":</emphasis>
- The protocol used to fetch the files.
- The default is "git" when a hostname is set.
- If a hostname is not set, the Git protocol is "file".
- You can also use "http", "https", "ssh" and "rsync".
- </para></listitem>
- <listitem><para><emphasis>"nocheckout":</emphasis>
- Tells the fetcher to not checkout source code when
- unpacking when set to "1".
- Set this option for the URL where there is a custom
- routine to checkout code.
- The default is "0".
- </para></listitem>
- <listitem><para><emphasis>"rebaseable":</emphasis>
- Indicates that the upstream Git repository can be rebased.
- You should set this parameter to "1" if
- revisions can become detached from branches.
- In this case, the source mirror tarball is done per
- revision, which has a loss of efficiency.
- Rebasing the upstream Git repository could cause the
- current revision to disappear from the upstream repository.
- This option reminds the fetcher to preserve the local cache
- carefully for future use.
- The default value for this parameter is "0".
- </para></listitem>
- <listitem><para><emphasis>"nobranch":</emphasis>
- Tells the fetcher to not check the SHA validation
- for the branch when set to "1".
- The default is "0".
- Set this option for the recipe that refers to
- the commit that is valid for a tag instead of
- the branch.
- </para></listitem>
- <listitem><para><emphasis>"bareclone":</emphasis>
- Tells the fetcher to clone a bare clone into the
- destination directory without checking out a working tree.
- Only the raw Git metadata is provided.
- This parameter implies the "nocheckout" parameter as well.
- </para></listitem>
- <listitem><para><emphasis>"branch":</emphasis>
- The branch(es) of the Git tree to clone.
- If unset, this is assumed to be "master".
- The number of branch parameters much match the number of
- name parameters.
- </para></listitem>
- <listitem><para><emphasis>"rev":</emphasis>
- The revision to use for the checkout.
- The default is "master".
- </para></listitem>
- <listitem><para><emphasis>"tag":</emphasis>
- Specifies a tag to use for the checkout.
- To correctly resolve tags, BitBake must access the
- network.
- For that reason, tags are often not used.
- As far as Git is concerned, the "tag" parameter behaves
- effectively the same as the "rev" parameter.
- </para></listitem>
- <listitem><para><emphasis>"subpath":</emphasis>
- Limits the checkout to a specific subpath of the tree.
- By default, the whole tree is checked out.
- </para></listitem>
- <listitem><para><emphasis>"destsuffix":</emphasis>
- The name of the path in which to place the checkout.
- By default, the path is <filename>git/</filename>.
- </para></listitem>
- <listitem><para><emphasis>"usehead":</emphasis>
- Enables local <filename>git://</filename> URLs to use the
- current branch HEAD as the revision for use with
- <filename>AUTOREV</filename>.
- The "usehead" parameter implies no branch and only works
- when the transfer protocol is
- <filename>file://</filename>.
- </para></listitem>
- </itemizedlist>
- Here are some example URLs:
- <literallayout class='monospaced'>
- SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"
- SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http"
- </literallayout>
- </para>
- </section>
-
- <section id='gitsm-fetcher'>
- <title>Git Submodule Fetcher (<filename>gitsm://</filename>)</title>
-
- <para>
- 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-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.
- <note>
- <title>Notes and Warnings</title>
- <para>
- You must clean a recipe when switching between
- '<filename>git://</filename>' and
- '<filename>gitsm://</filename>' URLs.
- </para>
-
- <para>
- The Git Submodules fetcher is not a complete fetcher
- implementation.
- The fetcher has known issues where it does not use the
- normal source mirroring infrastructure properly. Further,
- the submodule sources it fetches are not visible to the
- licensing and source archiving infrastructures.
- </para>
- </note>
- </para>
- </section>
-
- <section id='clearcase-fetcher'>
- <title>ClearCase Fetcher (<filename>ccrc://</filename>)</title>
-
- <para>
- This fetcher submodule fetches code from a
- <ulink url='http://en.wikipedia.org/wiki/Rational_ClearCase'>ClearCase</ulink>
- repository.
- </para>
-
- <para>
- To use this fetcher, make sure your recipe has proper
- <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"
- SRCREV = "EXAMPLE_CLEARCASE_TAG"
- PV = "${@d.getVar("SRCREV", False).replace("/", "+")}"
- </literallayout>
- The fetcher uses the <filename>rcleartool</filename> or
- <filename>cleartool</filename> remote client, depending on
- which one is available.
- </para>
-
- <para>
- Following are options for the <filename>SRC_URI</filename>
- statement:
- <itemizedlist>
- <listitem><para><emphasis><filename>vob</filename></emphasis>:
- The name, which must include the
- prepending "/" character, of the ClearCase VOB.
- This option is required.
- </para></listitem>
- <listitem><para><emphasis><filename>module</filename></emphasis>:
- The module, which must include the
- prepending "/" character, in the selected VOB.
- <note>
- The <filename>module</filename> and <filename>vob</filename>
- options are combined to create the <filename>load</filename> rule in
- the view config spec.
- As an example, consider the <filename>vob</filename> and
- <filename>module</filename> values from the
- <filename>SRC_URI</filename> statement at the start of this section.
- Combining those values results in the following:
- <literallayout class='monospaced'>
- load /example_vob/example_module
- </literallayout>
- </note>
- </para></listitem>
- <listitem><para><emphasis><filename>proto</filename></emphasis>:
- The protocol, which can be either <filename>http</filename> or
- <filename>https</filename>.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- By default, the fetcher creates a configuration specification.
- If you want this specification written to an area other than the default,
- use the <filename>CCASE_CUSTOM_CONFIG_SPEC</filename> variable
- in your recipe to define where the specification is written.
- <note>
- the <filename>SRCREV</filename> loses its functionality if you
- specify this variable.
- However, <filename>SRCREV</filename> is still used to label the
- archive after a fetch even though it does not define what is
- fetched.
- </note>
- </para>
-
- <para>
- Here are a couple of other behaviors worth mentioning:
- <itemizedlist>
- <listitem><para>
- When using <filename>cleartool</filename>, the login of
- <filename>cleartool</filename> is handled by the system.
- The login require no special steps.
- </para></listitem>
- <listitem><para>
- In order to use <filename>rcleartool</filename> with authenticated
- users, an "rcleartool login" is necessary before using the fetcher.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='perforce-fetcher'>
- <title>Perforce Fetcher (<filename>p4://</filename>)</title>
-
- <para>
- This fetcher submodule fetches code from the
- <ulink url='https://www.perforce.com/'>Perforce</ulink>
- source control system.
- The executable used is specified by
- <filename>FETCHCMD_p4</filename>, which defaults
- to "p4".
- The fetcher's temporary working directory is set by
- <link linkend='var-bb-P4DIR'><filename>P4DIR</filename></link>,
- which defaults to "DL_DIR/p4".
- The fetcher does not make use of a perforce client, instead it
- relies on <filename>p4 files</filename> to retrieve a list of
- files and <filename>p4 print</filename> to transfer the content
- of those files locally.
- </para>
-
- <para>
- To use this fetcher, make sure your recipe has proper
- <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
- password if you do not wish to keep those values in a recipe
- itself.
- If you choose not to use <filename>P4CONFIG</filename>,
- or to explicitly set variables that <filename>P4CONFIG</filename>
- can contain, you can specify the <filename>P4PORT</filename> value,
- which is the server's URL and port number, and you can
- specify a username and password directly in your recipe within
- <filename>SRC_URI</filename>.
- </para>
-
- <para>
- Here is an example that relies on <filename>P4CONFIG</filename>
- to specify the server URL and port, username, and password, and
- fetches the Head Revision:
- <literallayout class='monospaced'>
- SRC_URI = "p4://example-depot/main/source/..."
- SRCREV = "${AUTOREV}"
- PV = "p4-${SRCPV}"
- S = "${WORKDIR}/p4"
- </literallayout>
- </para>
-
- <para>
- Here is an example that specifies the server URL and port,
- username, and password, and fetches a Revision based on a Label:
- <literallayout class='monospaced'>
- P4PORT = "tcp:p4server.example.net:1666"
- SRC_URI = "p4://user:passwd@example-depot/main/source/..."
- SRCREV = "release-1.0"
- PV = "p4-${SRCPV}"
- S = "${WORKDIR}/p4"
- </literallayout>
- <note>
- You should always set <filename>S</filename>
- to <filename>"${WORKDIR}/p4"</filename> in your recipe.
- </note>
- </para>
-
- <para>
- By default, the fetcher strips the depot location from the
- local file paths. In the above example, the content of
- <filename>example-depot/main/source/</filename>
- will be placed in <filename>${WORKDIR}/p4</filename>.
- For situations where preserving parts of the remote depot paths
- locally is desirable, the fetcher supports two parameters:
-
- <itemizedlist>
- <listitem><para>
- <emphasis>"module":</emphasis>
- The top-level depot location or directory to fetch. The
- value of this parameter can also point to a single file
- within the depot, in which case the local file path will
- include the module path.
- </para></listitem>
- <listitem><para>
- <emphasis>"remotepath":</emphasis>
- When used with the value "<filename>keep</filename>",
- the fetcher will mirror the full depot paths locally
- for the specified location, even in combination with
- the <filename>module</filename> parameter.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Here is an example use of the the <filename>module</filename>
- parameter:
-
- <literallayout class='monospaced'>
- SRC_URI = "p4://user:passwd@example-depot/main;module=source/..."
- </literallayout>
-
- In this case, the content of the top-level directory
- <filename>source/</filename> will be fetched to
- <filename>${P4DIR}</filename>, including the directory itself.
- The top-level directory will be accesible at
- <filename>${P4DIR}/source/</filename>.
- </para>
-
- <para>
- Here is an example use of the the <filename>remotepath</filename>
- parameter:
-
- <literallayout class='monospaced'>
- SRC_URI = "p4://user:passwd@example-depot/main;module=source/...;remotepath=keep"
- </literallayout>
-
- In this case, the content of the top-level directory
- <filename>source/</filename> will be fetched to
- <filename>${P4DIR}</filename>, but the complete depot paths will
- be mirrored locally. The top-level directory will be accessible
- at <filename>${P4DIR}/example-depot/main/source/</filename>.
- </para>
- </section>
-
- <section id='repo-fetcher'>
- <title>Repo Fetcher (<filename>repo://</filename>)</title>
-
- <para>
- This fetcher submodule fetches code from
- <filename>google-repo</filename> source control system.
- The fetcher works by initiating and syncing sources of the
- repository into
- <link linkend='var-bb-REPODIR'><filename>REPODIR</filename></link>,
- which is usually
- <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link><filename>/repo</filename>.
- </para>
-
- <para>
- This fetcher supports the following parameters:
- <itemizedlist>
- <listitem><para>
- <emphasis>"protocol":</emphasis>
- Protocol to fetch the repository manifest (default: git).
- </para></listitem>
- <listitem><para>
- <emphasis>"branch":</emphasis>
- Branch or tag of repository to get (default: master).
- </para></listitem>
- <listitem><para>
- <emphasis>"manifest":</emphasis>
- Name of the manifest file (default: <filename>default.xml</filename>).
- </para></listitem>
- </itemizedlist>
- Here are some example URLs:
- <literallayout class='monospaced'>
- SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml"
- SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml"
- </literallayout>
- </para>
- </section>
-
- <section id='other-fetchers'>
- <title>Other Fetchers</title>
-
- <para>
- Fetch submodules also exist for the following:
- <itemizedlist>
- <listitem><para>
- Bazaar (<filename>bzr://</filename>)
- </para></listitem>
- <listitem><para>
- Mercurial (<filename>hg://</filename>)
- </para></listitem>
- <listitem><para>
- npm (<filename>npm://</filename>)
- </para></listitem>
- <listitem><para>
- OSC (<filename>osc://</filename>)
- </para></listitem>
- <listitem><para>
- Secure FTP (<filename>sftp://</filename>)
- </para></listitem>
- <listitem><para>
- 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
- fetcher submodules.
- However, you might find the code helpful and readable.
- </para>
- </section>
- </section>
-
- <section id='auto-revisions'>
- <title>Auto Revisions</title>
-
- <para>
- We need to document <filename>AUTOREV</filename> and
- <filename>SRCREV_FORMAT</filename> here.
- </para>
- </section>
-</chapter>
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-hello.xml b/doc/bitbake-user-manual/bitbake-user-manual-hello.xml
deleted file mode 100644
index 11eb36aaf..000000000
--- a/doc/bitbake-user-manual/bitbake-user-manual-hello.xml
+++ /dev/null
@@ -1,513 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<appendix id='hello-world-example'>
- <title>Hello World Example</title>
-
- <section id='bitbake-hello-world'>
- <title>BitBake Hello World</title>
-
- <para>
- The simplest example commonly used to demonstrate any new
- programming language or tool is the
- "<ulink url="http://en.wikipedia.org/wiki/Hello_world_program">Hello World</ulink>"
- example.
- This appendix demonstrates, in tutorial form, Hello
- World within the context of BitBake.
- The tutorial describes how to create a new project
- and the applicable metadata files necessary to allow
- BitBake to build it.
- </para>
- </section>
-
- <section id='example-obtaining-bitbake'>
- <title>Obtaining BitBake</title>
-
- <para>
- See the
- "<link linkend='obtaining-bitbake'>Obtaining BitBake</link>"
- section for information on how to obtain BitBake.
- Once you have the source code on your machine, the BitBake directory
- appears as follows:
- <literallayout class='monospaced'>
- $ ls -al
- total 100
- drwxrwxr-x. 9 wmat wmat 4096 Jan 31 13:44 .
- drwxrwxr-x. 3 wmat wmat 4096 Feb 4 10:45 ..
- -rw-rw-r--. 1 wmat wmat 365 Nov 26 04:55 AUTHORS
- drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 bin
- drwxrwxr-x. 4 wmat wmat 4096 Jan 31 13:44 build
- -rw-rw-r--. 1 wmat wmat 16501 Nov 26 04:55 ChangeLog
- drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 classes
- drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 conf
- drwxrwxr-x. 3 wmat wmat 4096 Nov 26 04:55 contrib
- -rw-rw-r--. 1 wmat wmat 17987 Nov 26 04:55 COPYING
- drwxrwxr-x. 3 wmat wmat 4096 Nov 26 04:55 doc
- -rw-rw-r--. 1 wmat wmat 69 Nov 26 04:55 .gitignore
- -rw-rw-r--. 1 wmat wmat 849 Nov 26 04:55 HEADER
- drwxrwxr-x. 5 wmat wmat 4096 Jan 31 13:44 lib
- -rw-rw-r--. 1 wmat wmat 195 Nov 26 04:55 MANIFEST.in
- -rw-rw-r--. 1 wmat wmat 2887 Nov 26 04:55 TODO
- </literallayout>
- </para>
-
- <para>
- At this point, you should have BitBake cloned to
- a directory that matches the previous listing except for
- dates and user names.
- </para>
- </section>
-
- <section id='setting-up-the-bitbake-environment'>
- <title>Setting Up the BitBake Environment</title>
-
- <para>
- First, you need to be sure that you can run BitBake.
- Set your working directory to where your local BitBake
- files are and run the following command:
- <literallayout class='monospaced'>
- $ ./bin/bitbake --version
- BitBake Build Tool Core version 1.23.0, bitbake version 1.23.0
- </literallayout>
- The console output tells you what version you are running.
- </para>
-
- <para>
- The recommended method to run BitBake is from a directory of your
- choice.
- To be able to run BitBake from any directory, you need to add the
- executable binary to your binary to your shell's environment
- <filename>PATH</filename> variable.
- First, look at your current <filename>PATH</filename> variable
- by entering the following:
- <literallayout class='monospaced'>
- $ echo $PATH
- </literallayout>
- Next, add the directory location for the BitBake binary to the
- <filename>PATH</filename>.
- Here is an example that adds the
- <filename>/home/scott-lenovo/bitbake/bin</filename> directory
- to the front of the <filename>PATH</filename> variable:
- <literallayout class='monospaced'>
- $ export PATH=/home/scott-lenovo/bitbake/bin:$PATH
- </literallayout>
- You should now be able to enter the <filename>bitbake</filename>
- command from the command line while working from any directory.
- </para>
- </section>
-
- <section id='the-hello-world-example'>
- <title>The Hello World Example</title>
-
- <para>
- The overall goal of this exercise is to build a
- complete "Hello World" example utilizing task and layer
- concepts.
- Because this is how modern projects such as OpenEmbedded and
- the Yocto Project utilize BitBake, the example
- provides an excellent starting point for understanding
- BitBake.
- </para>
-
- <para>
- To help you understand how to use BitBake to build targets,
- the example starts with nothing but the <filename>bitbake</filename>
- command, which causes BitBake to fail and report problems.
- The example progresses by adding pieces to the build to
- eventually conclude with a working, minimal "Hello World"
- example.
- </para>
-
- <para>
- While every attempt is made to explain what is happening during
- the example, the descriptions cannot cover everything.
- You can find further information throughout this manual.
- Also, you can actively participate in the
- <ulink url='http://lists.openembedded.org/mailman/listinfo/bitbake-devel'></ulink>
- discussion mailing list about the BitBake build tool.
- </para>
-
- <note>
- This example was inspired by and drew heavily from
- <ulink url="http://www.mail-archive.com/yocto@yoctoproject.org/msg09379.html">Mailing List post - The BitBake equivalent of "Hello, World!"</ulink>.
- </note>
-
- <para>
- As stated earlier, the goal of this example
- is to eventually compile "Hello World".
- However, it is unknown what BitBake needs and what you have
- to provide in order to achieve that goal.
- Recall that BitBake utilizes three types of metadata files:
- <link linkend='configuration-files'>Configuration Files</link>,
- <link linkend='classes'>Classes</link>, and
- <link linkend='recipes'>Recipes</link>.
- But where do they go?
- How does BitBake find them?
- BitBake's error messaging helps you answer these types of questions
- and helps you better understand exactly what is going on.
- </para>
-
- <para>
- Following is the complete "Hello World" example.
- </para>
-
- <orderedlist>
- <listitem><para><emphasis>Create a Project Directory:</emphasis>
- First, set up a directory for the "Hello World" project.
- Here is how you can do so in your home directory:
- <literallayout class='monospaced'>
- $ mkdir ~/hello
- $ cd ~/hello
- </literallayout>
- This is the directory that BitBake will use to do all of
- its work.
- You can use this directory to keep all the metafiles needed
- by BitBake.
- Having a project directory is a good way to isolate your
- project.
- </para></listitem>
- <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:
- <literallayout class='monospaced'>
- $ bitbake
- The BBPATH variable is not set and bitbake did not
- find a conf/bblayers.conf file in the expected location.
- Maybe you accidentally invoked bitbake from the wrong directory?
- DEBUG: Removed the following variables from the environment:
- GNOME_DESKTOP_SESSION_ID, XDG_CURRENT_DESKTOP,
- GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG, no_proxy,
- XDG_SESSION_PATH, XAUTHORITY, SESSION_MANAGER, SHLVL,
- MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, WINDOWID, EDITOR,
- GPG_AGENT_INFO, SSH_AUTH_SOCK, GDMSESSION, GNOME_KEYRING_PID,
- XDG_SEAT_PATH, XDG_CONFIG_DIRS, LESSOPEN, DBUS_SESSION_BUS_ADDRESS,
- _, XDG_SESSION_COOKIE, DESKTOP_SESSION, LESSCLOSE, DEFAULTS_PATH,
- UBUNTU_MENUPROXY, OLDPWD, XDG_DATA_DIRS, COLORTERM, LS_COLORS
- </literallayout>
- The majority of this output is specific to environment variables
- that are not directly relevant to BitBake.
- However, the very first message regarding the
- <filename>BBPATH</filename> variable and the
- <filename>conf/bblayers.conf</filename> file
- is relevant.</para>
- <para>
- When you run BitBake, it begins looking for metadata files.
- The
- <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
- find any configuration files (<filename>.conf</filename>)
- or recipe files (<filename>.bb</filename>) at all.
- BitBake also cannot find the <filename>bitbake.conf</filename>
- file.
- </para></listitem>
- <listitem><para><emphasis>Setting <filename>BBPATH</filename>:</emphasis>
- For this example, you can set <filename>BBPATH</filename>
- in the same manner that you set <filename>PATH</filename>
- earlier in the appendix.
- You should realize, though, that it is much more flexible to set the
- <filename>BBPATH</filename> variable up in a configuration
- file for each project.</para>
- <para>From your shell, enter the following commands to set and
- export the <filename>BBPATH</filename> variable:
- <literallayout class='monospaced'>
- $ BBPATH="<replaceable>projectdirectory</replaceable>"
- $ export BBPATH
- </literallayout>
- Use your actual project directory in the command.
- BitBake uses that directory to find the metadata it needs for
- your project.
- <note>
- When specifying your project directory, do not use the
- tilde ("~") character as BitBake does not expand that character
- as the shell would.
- </note>
- </para></listitem>
- <listitem><para><emphasis>Run BitBake:</emphasis>
- Now that you have <filename>BBPATH</filename> defined, run
- the <filename>bitbake</filename> command again:
- <literallayout class='monospaced'>
- $ bitbake
- ERROR: Traceback (most recent call last):
- File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
- return func(fn, *args)
- File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 173, in parse_config_file
- return bb.parse.handle(fn, data, include)
- File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 99, in handle
- return h['handle'](fn, data, include)
- File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 120, in handle
- abs_fn = resolve_file(fn, data)
- File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 117, in resolve_file
- raise IOError("file %s not found in %s" % (fn, bbpath))
- IOError: file conf/bitbake.conf not found in /home/scott-lenovo/hello
-
- ERROR: Unable to parse conf/bitbake.conf: file conf/bitbake.conf not found in /home/scott-lenovo/hello
- </literallayout>
- This sample output shows that BitBake could not find the
- <filename>conf/bitbake.conf</filename> file in the project
- directory.
- This file is the first thing BitBake must find in order
- to build a target.
- And, since the project directory for this example is
- empty, you need to provide a <filename>conf/bitbake.conf</filename>
- file.
- </para></listitem>
- <listitem><para><emphasis>Creating <filename>conf/bitbake.conf</filename>:</emphasis>
- The <filename>conf/bitbake.conf</filename> includes a number of
- configuration variables BitBake uses for metadata and recipe
- files.
- For this example, you need to create the file in your project directory
- and define some key BitBake variables.
- For more information on the <filename>bitbake.conf</filename> file,
- see
- <ulink url='http://git.openembedded.org/bitbake/tree/conf/bitbake.conf'></ulink>.
- </para>
- <para>Use the following commands to create the <filename>conf</filename>
- directory in the project directory:
- <literallayout class='monospaced'>
- $ mkdir conf
- </literallayout>
- From within the <filename>conf</filename> directory, use
- some editor to create the <filename>bitbake.conf</filename>
- so that it contains the following:
- <literallayout class='monospaced'>
- <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-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
- variables <filename>STAMP</filename>,
- <filename>T</filename>, and <filename>B</filename>,
- prevent more than one recipe from working. You can fix
- this by either setting <filename>PN</filename> to have
- a value similar to what OpenEmbedded and BitBake use
- in the default <filename>bitbake.conf</filename> file
- (see previous example). Or, by manually updating each
- recipe to set <filename>PN</filename>. You will also
- need to include <filename>PN</filename> as part of the
- <filename>STAMP</filename>, <filename>T</filename>, and
- <filename>B</filename> variable definitions in the
- <filename>local.conf</filename> file.
- </note>
- The <filename>TMPDIR</filename> variable establishes a directory
- that BitBake uses for build output and intermediate files other
- than the cached information used by the
- <link linkend='setscene'>Setscene</link> process.
- Here, the <filename>TMPDIR</filename> directory is set to
- <filename>hello/tmp</filename>.
- <note><title>Tip</title>
- You can always safely delete the <filename>tmp</filename>
- directory in order to rebuild a BitBake target.
- The build process creates the directory for you
- when you run BitBake.
- </note></para>
- <para>For information about each of the other variables defined in this
- example, click on the links to take you to the definitions in
- the glossary.
- </para></listitem>
- <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:
- <literallayout class='monospaced'>
- $ bitbake
- ERROR: Traceback (most recent call last):
- File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
- return func(fn, *args)
- File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 177, in _inherit
- bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
- File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 92, in inherit
- include(fn, file, lineno, d, "inherit")
- File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 100, in include
- raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
- ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
-
- ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
- </literallayout>
- In the sample output, BitBake could not find the
- <filename>classes/base.bbclass</filename> file.
- You need to create that file next.
- </para></listitem>
- <listitem><para><emphasis>Creating <filename>classes/base.bbclass</filename>:</emphasis>
- BitBake uses class files to provide common code and functionality.
- The minimally required class for BitBake is the
- <filename>classes/base.bbclass</filename> file.
- The <filename>base</filename> class is implicitly inherited by
- every recipe.
- BitBake looks for the class in the <filename>classes</filename>
- directory of the project (i.e <filename>hello/classes</filename>
- in this example).
- </para>
- <para>Create the <filename>classes</filename> directory as follows:
- <literallayout class='monospaced'>
- $ cd $HOME/hello
- $ mkdir classes
- </literallayout>
- Move to the <filename>classes</filename> directory and then
- create the <filename>base.bbclass</filename> file by inserting
- this single line:
- <literallayout class='monospaced'>
- addtask build
- </literallayout>
- The minimal task that BitBake runs is the
- <filename>do_build</filename> task.
- This is all the example needs in order to build the project.
- Of course, the <filename>base.bbclass</filename> can have much
- more depending on which build environments BitBake is
- supporting.
- </para></listitem>
- <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:
- <literallayout class='monospaced'>
- $ bitbake
- Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
- </literallayout>
- BitBake is finally reporting no errors.
- However, you can see that it really does not have anything
- to do.
- You need to create a recipe that gives BitBake something to do.
- </para></listitem>
- <listitem><para><emphasis>Creating a Layer:</emphasis>
- While it is not really necessary for such a small example,
- it is good practice to create a layer in which to keep your
- code separate from the general metadata used by BitBake.
- Thus, this example creates and uses a layer called "mylayer".
- <note>
- You can find additional information on layers in the
- "<link linkend='layers'>Layers</link>" section.
- </note></para>
-
- <para>Minimally, you need a recipe file and a layer configuration
- file in your layer.
- The configuration file needs to be in the <filename>conf</filename>
- directory inside the layer.
- Use these commands to set up the layer and the <filename>conf</filename>
- directory:
- <literallayout class='monospaced'>
- $ cd $HOME
- $ mkdir mylayer
- $ cd mylayer
- $ mkdir conf
- </literallayout>
- 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-bb-LAYERDIR'>LAYERDIR</link>}"
-
- <link linkend='var-bb-BBFILES'>BBFILES</link> += "${LAYERDIR}/*.bb"
-
- <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>
- <para>You need to create the recipe file next.
- Inside your layer at the top-level, use an editor and create
- a recipe file named <filename>printhello.bb</filename> that
- has the following:
- <literallayout class='monospaced'>
- <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("********************");
- bb.plain("* *");
- bb.plain("* Hello, World! *");
- bb.plain("* *");
- bb.plain("********************");
- }
- </literallayout>
- The recipe file simply provides a description of the
- recipe, the name, version, and the <filename>do_build</filename>
- task, which prints out "Hello World" to the console.
- For more information on these variables, follow the links
- to the glossary.
- </para></listitem>
- <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'>
- $ cd $HOME/hello
- $ bitbake printhello
- ERROR: no recipe files to build, check your BBPATH and BBFILES?
-
- Summary: There was 1 ERROR message shown, returning a non-zero exit code.
- </literallayout>
- We have created the layer with the recipe and the layer
- configuration file but it still seems that BitBake cannot
- find the recipe.
- BitBake needs a <filename>conf/bblayers.conf</filename> that
- lists the layers for the project.
- Without this file, BitBake cannot find the recipe.
- </para></listitem>
- <listitem><para><emphasis>Creating <filename>conf/bblayers.conf</filename>:</emphasis>
- BitBake uses the <filename>conf/bblayers.conf</filename> file
- to locate layers needed for the project.
- This file must reside in the <filename>conf</filename> directory
- of the project (i.e. <filename>hello/conf</filename> for this
- example).</para>
- <para>Set your working directory to the <filename>hello/conf</filename>
- directory and then create the <filename>bblayers.conf</filename>
- file so that it contains the following:
- <literallayout class='monospaced'>
- BBLAYERS ?= " \
- /home/&lt;you&gt;/mylayer \
- "
- </literallayout>
- 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>
- Now that you have supplied the <filename>bblayers.conf</filename>
- file, run the <filename>bitbake</filename> command and provide
- the target:
- <literallayout class='monospaced'>
- $ bitbake printhello
- Parsing recipes: 100% |##################################################################################|
- Time: 00:00:00
- Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0 skipped, 0 masked, 0 errors.
- NOTE: Resolving any missing task queue dependencies
- NOTE: Preparing RunQueue
- NOTE: Executing RunQueue Tasks
- ********************
- * *
- * Hello, World! *
- * *
- ********************
- NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
- </literallayout>
- BitBake finds the <filename>printhello</filename> recipe and
- successfully runs the task.
- <note>
- After the first execution, re-running
- <filename>bitbake printhello</filename> again will not
- result in a BitBake run that prints the same console
- output.
- The reason for this is that the first time the
- <filename>printhello.bb</filename> recipe's
- <filename>do_build</filename> task executes
- successfully, BitBake writes a stamp file for the task.
- Thus, the next time you attempt to run the task
- using that same <filename>bitbake</filename> command,
- BitBake notices the stamp and therefore determines
- that the task does not need to be re-run.
- If you delete the <filename>tmp</filename> directory
- or run <filename>bitbake -c clean printhello</filename>
- and then re-run the build, the "Hello, World!" message will
- be printed again.
- </note>
- </para></listitem>
- </orderedlist>
- </section>
-</appendix>
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-intro.xml b/doc/bitbake-user-manual/bitbake-user-manual-intro.xml
deleted file mode 100644
index 995c2fa7b..000000000
--- a/doc/bitbake-user-manual/bitbake-user-manual-intro.xml
+++ /dev/null
@@ -1,891 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id="bitbake-user-manual-intro">
- <title>Overview</title>
-
- <para>
- Welcome to the BitBake User Manual.
- This manual provides information on the BitBake tool.
- The information attempts to be as independent as possible regarding
- systems that use BitBake, such as OpenEmbedded and the
- Yocto Project.
- In some cases, scenarios or examples within the context of
- a build system are used in the manual to help with understanding.
- For these cases, the manual clearly states the context.
- </para>
-
- <section id="intro">
- <title>Introduction</title>
-
- <para>
- Fundamentally, BitBake is a generic task execution
- engine that allows shell and Python tasks to be run
- efficiently and in parallel while working within
- complex inter-task dependency constraints.
- One of BitBake's main users, OpenEmbedded, takes this core
- and builds embedded Linux software stacks using
- a task-oriented approach.
- </para>
-
- <para>
- Conceptually, BitBake is similar to GNU Make in
- some regards but has significant differences:
- <itemizedlist>
- <listitem><para>
- BitBake executes tasks according to provided
- metadata that builds up the tasks.
- Metadata is stored in recipe (<filename>.bb</filename>)
- and related recipe "append" (<filename>.bbappend</filename>)
- files, configuration (<filename>.conf</filename>) and
- underlying include (<filename>.inc</filename>) files, and
- in class (<filename>.bbclass</filename>) files.
- The metadata provides
- BitBake with instructions on what tasks to run and
- the dependencies between those tasks.
- </para></listitem>
- <listitem><para>
- BitBake includes a fetcher library for obtaining source
- code from various places such as local files, source control
- systems, or websites.
- </para></listitem>
- <listitem><para>
- The instructions for each unit to be built (e.g. a piece
- of software) are known as "recipe" files and
- contain all the information about the unit
- (dependencies, source file locations, checksums, description
- and so on).
- </para></listitem>
- <listitem><para>
- BitBake includes a client/server abstraction and can
- be used from a command line or used as a service over
- XML-RPC and has several different user interfaces.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id="history-and-goals">
- <title>History and Goals</title>
-
- <para>
- BitBake was originally a part of the OpenEmbedded project.
- It was inspired by the Portage package management system
- used by the Gentoo Linux distribution.
- On December 7, 2004, OpenEmbedded project team member
- Chris Larson split the project into two distinct pieces:
- <itemizedlist>
- <listitem><para>BitBake, a generic task executor</para></listitem>
- <listitem><para>OpenEmbedded, a metadata set utilized by
- BitBake</para></listitem>
- </itemizedlist>
- Today, BitBake is the primary basis of the
- <ulink url="http://www.openembedded.org/">OpenEmbedded</ulink>
- project, which is being used to build and maintain Linux
- distributions such as the
- <ulink url='http://www.angstrom-distribution.org/'>Angstrom Distribution</ulink>,
- and which is also being used as the build tool for Linux projects
- such as the
- <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink>.
- </para>
-
- <para>
- Prior to BitBake, no other build tool adequately met the needs of
- an aspiring embedded Linux distribution.
- All of the build systems used by traditional desktop Linux
- distributions lacked important functionality, and none of the
- ad hoc Buildroot-based systems, prevalent in the
- embedded space, were scalable or maintainable.
- </para>
-
- <para>
- Some important original goals for BitBake were:
- <itemizedlist>
- <listitem><para>
- Handle cross-compilation.
- </para></listitem>
- <listitem><para>
- Handle inter-package dependencies (build time on
- target architecture, build time on native
- architecture, and runtime).
- </para></listitem>
- <listitem><para>
- Support running any number of tasks within a given
- package, including, but not limited to, fetching
- upstream sources, unpacking them, patching them,
- configuring them, and so forth.
- </para></listitem>
- <listitem><para>
- Be Linux distribution agnostic for both build and
- target systems.
- </para></listitem>
- <listitem><para>
- Be architecture agnostic.
- </para></listitem>
- <listitem><para>
- Support multiple build and target operating systems
- (e.g. Cygwin, the BSDs, and so forth).
- </para></listitem>
- <listitem><para>
- Be self-contained, rather than tightly
- integrated into the build machine's root
- filesystem.
- </para></listitem>
- <listitem><para>
- Handle conditional metadata on the target architecture,
- operating system, distribution, and machine.
- </para></listitem>
- <listitem><para>
- Be easy to use the tools to supply local metadata and packages
- against which to operate.
- </para></listitem>
- <listitem><para>
- Be easy to use BitBake to collaborate between multiple
- projects for their builds.
- </para></listitem>
- <listitem><para>
- Provide an inheritance mechanism to share
- common metadata between many packages.
- </para></listitem>
- </itemizedlist>
- Over time it became apparent that some further requirements
- were necessary:
- <itemizedlist>
- <listitem><para>
- Handle variants of a base recipe (e.g. native, sdk,
- and multilib).
- </para></listitem>
- <listitem><para>
- Split metadata into layers and allow layers
- to enhance or override other layers.
- </para></listitem>
- <listitem><para>
- Allow representation of a given set of input variables
- to a task as a checksum.
- Based on that checksum, allow acceleration of builds
- with prebuilt components.
- </para></listitem>
- </itemizedlist>
- BitBake satisfies all the original requirements and many more
- with extensions being made to the basic functionality to
- reflect the additional requirements.
- Flexibility and power have always been the priorities.
- BitBake is highly extensible and supports embedded Python code and
- execution of any arbitrary tasks.
- </para>
- </section>
-
- <section id="Concepts">
- <title>Concepts</title>
-
- <para>
- BitBake is a program written in the Python language.
- At the highest level, BitBake interprets metadata, decides
- what tasks are required to run, and executes those tasks.
- Similar to GNU Make, BitBake controls how software is
- built.
- GNU Make achieves its control through "makefiles", while
- BitBake uses "recipes".
- </para>
-
- <para>
- BitBake extends the capabilities of a simple
- tool like GNU Make by allowing for the definition of much more
- complex tasks, such as assembling entire embedded Linux
- distributions.
- </para>
-
- <para>
- The remainder of this section introduces several concepts
- that should be understood in order to better leverage
- the power of BitBake.
- </para>
-
- <section id='recipes'>
- <title>Recipes</title>
-
- <para>
- BitBake Recipes, which are denoted by the file extension
- <filename>.bb</filename>, are the most basic metadata files.
- These recipe files provide BitBake with the following:
- <itemizedlist>
- <listitem><para>Descriptive information about the
- package (author, homepage, license, and so on)</para></listitem>
- <listitem><para>The version of the recipe</para></listitem>
- <listitem><para>Existing dependencies (both build
- and runtime dependencies)</para></listitem>
- <listitem><para>Where the source code resides and
- how to fetch it</para></listitem>
- <listitem><para>Whether the source code requires
- any patches, where to find them, and how to apply
- 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>
- </para>
-
- <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 <firstterm>recipes</firstterm>.
- <note>
- The term "package" is also commonly used to describe recipes.
- However, since the same word is used to describe packaged
- output from a project, it is best to maintain a single
- descriptive term - "recipes".
- Put another way, a single "recipe" file is quite capable
- of generating a number of related but separately installable
- "packages".
- In fact, that ability is fairly common.
- </note>
- </para>
- </section>
-
- <section id='configuration-files'>
- <title>Configuration Files</title>
-
- <para>
- Configuration files, which are denoted by the
- <filename>.conf</filename> extension, define
- various configuration variables that govern the project's build
- process.
- These files fall into several areas that define
- 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
- <filename>conf</filename> directory.
- </para>
- </section>
-
- <section id='classes'>
- <title>Classes</title>
-
- <para>
- Class files, which are denoted by the
- <filename>.bbclass</filename> extension, contain
- information that is useful to share between metadata files.
- The BitBake source tree currently comes with one class metadata file
- called <filename>base.bbclass</filename>.
- You can find this file in the
- <filename>classes</filename> directory.
- The <filename>base.bbclass</filename> class files is special since it
- is always included automatically for all recipes
- and classes.
- This class contains definitions for standard basic tasks such
- as fetching, unpacking, configuring (empty by default),
- compiling (runs any Makefile present), installing (empty by
- default) and packaging (empty by default).
- These tasks are often overridden or extended by other classes
- added during the project development process.
- </para>
- </section>
-
- <section id='layers'>
- <title>Layers</title>
-
- <para>
- 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
- your metadata, the easier it is to cope with future changes.
- </para>
-
- <para>
- 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 <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.
- This situation gives you a couple of layers: one for the machine
- configurations and one for the GUI environment.
- It is important to understand, however, that the BSP layer can still
- make machine-specific additions to recipes within
- the GUI environment layer without polluting the GUI layer itself
- with those machine-specific changes.
- You can accomplish this through a recipe that is a BitBake append
- (<filename>.bbappend</filename>) file.
- </para>
- </section>
-
- <section id='append-bbappend-files'>
- <title>Append Files</title>
-
- <para>
- Append files, which are files that have the
- <filename>.bbappend</filename> file extension, extend or
- override information in an existing recipe file.
- </para>
-
- <para>
- BitBake expects every append file to have a corresponding recipe file.
- Furthermore, the append file and corresponding recipe file
- must use the same root filename.
- The filenames can differ only in the file type suffix used
- (e.g. <filename>formfactor_0.0.bb</filename> and
- <filename>formfactor_0.0.bbappend</filename>).
- </para>
-
- <para>
- Information in append files extends or
- overrides the information in the underlying,
- similarly-named recipe files.
- </para>
-
- <para>
- When you name an append file, you can use the
- "<filename>%</filename>" wildcard character to allow for matching
- recipe names.
- For example, suppose you have an append file named
- as follows:
- <literallayout class='monospaced'>
- busybox_1.21.%.bbappend
- </literallayout>
- That append file would match any <filename>busybox_1.21.</filename><replaceable>x</replaceable><filename>.bb</filename>
- version of the recipe.
- So, the append file would match the following recipe names:
- <literallayout class='monospaced'>
- busybox_1.21.1.bb
- busybox_1.21.2.bb
- busybox_1.21.3.bb
- </literallayout>
- <note><title>Important</title>
- The use of the "<filename>%</filename>" character
- is limited in that it only works directly in front of the
- <filename>.bbappend</filename> portion of the append file's
- name.
- You cannot use the wildcard character in any other
- location of the name.
- </note>
- If the <filename>busybox</filename> recipe was updated to
- <filename>busybox_1.3.0.bb</filename>, the append name would not
- match.
- However, if you named the append file
- <filename>busybox_1.%.bbappend</filename>, then you would have a match.
- </para>
-
- <para>
- In the most general case, you could name the append file something as
- simple as <filename>busybox_%.bbappend</filename> to be entirely
- version independent.
- </para>
- </section>
- </section>
-
- <section id='obtaining-bitbake'>
- <title>Obtaining BitBake</title>
-
- <para>
- You can obtain BitBake several different ways:
- <itemizedlist>
- <listitem><para><emphasis>Cloning BitBake:</emphasis>
- Using Git to clone the BitBake source code repository
- is the recommended method for obtaining BitBake.
- Cloning the repository makes it easy to get bug fixes
- and have access to stable branches and the master
- branch.
- Once you have cloned BitBake, you should use
- the latest stable
- branch for development since the master branch is for
- BitBake development and might contain less stable changes.
- </para>
- <para>You usually need a version of BitBake
- that matches the metadata you are using.
- The metadata is generally backwards compatible but
- not forward compatible.</para>
- <para>Here is an example that clones the BitBake repository:
- <literallayout class='monospaced'>
- $ git clone git://git.openembedded.org/bitbake
- </literallayout>
- This command clones the BitBake Git repository into a
- directory called <filename>bitbake</filename>.
- Alternatively, you can
- designate a directory after the
- <filename>git clone</filename> command
- if you want to call the new directory something
- other than <filename>bitbake</filename>.
- Here is an example that names the directory
- <filename>bbdev</filename>:
- <literallayout class='monospaced'>
- $ git clone git://git.openembedded.org/bitbake bbdev
- </literallayout></para></listitem>
- <listitem><para><emphasis>Installation using your Distribution
- Package Management System:</emphasis>
- This method is not
- recommended because the BitBake version that is
- provided by your distribution, in most cases,
- is several
- releases behind a snapshot of the BitBake repository.
- </para></listitem>
- <listitem><para><emphasis>Taking a snapshot of BitBake:</emphasis>
- Downloading a snapshot of BitBake from the
- source code repository gives you access to a known
- branch or release of BitBake.
- <note>
- Cloning the Git repository, as described earlier,
- is the preferred method for getting BitBake.
- Cloning the repository makes it easier to update as
- patches are added to the stable branches.
- </note></para>
- <para>The following example downloads a snapshot of
- BitBake version 1.17.0:
- <literallayout class='monospaced'>
- $ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz
- $ tar zxpvf bitbake-1.17.0.tar.gz
- </literallayout>
- After extraction of the tarball using the tar utility,
- you have a directory entitled
- <filename>bitbake-1.17.0</filename>.
- </para></listitem>
- <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
- system, such as Poky.
- Rather than manually checking out individual layers and
- gluing them together yourself, you can check
- out an entire build system.
- The checkout will already include a version of BitBake that
- has been thoroughly tested for compatibility with the other
- components.
- For information on how to check out a particular BitBake-based
- build system, consult that build system's supporting documentation.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id="bitbake-user-manual-command">
- <title>The BitBake Command</title>
-
- <para>
- The <filename>bitbake</filename> command is the primary interface
- to the BitBake tool.
- This section presents the BitBake command syntax and provides
- several execution examples.
- </para>
-
- <section id='usage-and-syntax'>
- <title>Usage and syntax</title>
-
- <para>
- Following is the usage and syntax for BitBake:
- <literallayout class='monospaced'>
- $ bitbake -h
- Usage: bitbake [options] [recipename/target recipe:do_task ...]
-
- Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
- It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
- will provide the layer, BBFILES and other configuration information.
-
- Options:
- --version show program's version number and exit
- -h, --help show this help message and exit
- -b BUILDFILE, --buildfile=BUILDFILE
- Execute tasks from a specific .bb recipe directly.
- WARNING: Does not handle any dependencies from other
- recipes.
- -k, --continue Continue as much as possible after an error. While the
- target that failed and anything depending on it cannot
- be built, as much as possible will be built before
- stopping.
- -f, --force Force the specified targets/task to run (invalidating
- any existing stamp file).
- -c CMD, --cmd=CMD Specify the task to execute. The exact options
- available depend on the metadata. Some examples might
- be 'compile' or 'populate_sysroot' or 'listtasks' may
- give a list of the tasks available.
- -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
- Invalidate the stamp for the specified task such as
- 'compile' and then run the default task for the
- specified target(s).
- -r PREFILE, --read=PREFILE
- Read the specified file before bitbake.conf.
- -R POSTFILE, --postread=POSTFILE
- Read the specified file after bitbake.conf.
- -v, --verbose Enable tracing of shell tasks (with 'set -x'). Also
- print bb.note(...) messages to stdout (in addition to
- writing them to ${T}/log.do_&lt;task&gt;).
- -D, --debug Increase the debug level. You can specify this more
- than once. -D sets the debug level to 1, where only
- bb.debug(1, ...) messages are printed to stdout; -DD
- sets the debug level to 2, where both bb.debug(1, ...)
- and bb.debug(2, ...) messages are printed; etc.
- Without -D, no debug messages are printed. Note that
- -D only affects output to stdout. All debug messages
- are written to ${T}/log.do_taskname, regardless of the
- debug level.
- -q, --quiet Output less log message data to the terminal. You can
- specify this more than once.
- -n, --dry-run Don't execute, just go through the motions.
- -S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER
- Dump out the signature construction information, with
- no task execution. The SIGNATURE_HANDLER parameter is
- passed to the handler. Two common values are none and
- printdiff but the handler may define more/less. none
- means only dump the signature, printdiff means compare
- the dumped signature with the cached one.
- -p, --parse-only Quit after parsing the BB recipes.
- -s, --show-versions Show current and preferred versions of all recipes.
- -e, --environment Show the global or per-recipe environment complete
- with information about where variables were
- set/changed.
- -g, --graphviz Save dependency tree information for the specified
- targets in the dot syntax.
- -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
- Assume these dependencies don't exist and are already
- provided (equivalent to ASSUME_PROVIDED). Useful to
- make dependency graphs more appealing
- -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
- Show debug logging for the specified logging domains
- -P, --profile Profile the command and save reports.
- -u UI, --ui=UI The user interface to use (knotty, ncurses or taskexp
- - default knotty).
- --token=XMLRPCTOKEN Specify the connection token to be used when
- connecting to a remote server.
- --revisions-changed Set the exit code depending on whether upstream
- floating revisions have changed or not.
- --server-only Run bitbake without a UI, only starting a server
- (cooker) process.
- -B BIND, --bind=BIND The name/address for the bitbake xmlrpc server to bind
- to.
- -T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT
- Set timeout to unload bitbake server due to
- inactivity, set to -1 means no unload, default:
- Environment variable BB_SERVER_TIMEOUT.
- --no-setscene Do not run any setscene tasks. sstate will be ignored
- and everything needed, built.
- --setscene-only Only run setscene tasks, don't run any real tasks.
- --remote-server=REMOTE_SERVER
- Connect to the specified server.
- -m, --kill-server Terminate any running bitbake server.
- --observe-only Connect to a server as an observing-only client.
- --status-only Check the status of the remote bitbake server.
- -w WRITEEVENTLOG, --write-log=WRITEEVENTLOG
- Writes the event log of the build to a bitbake event
- json file. Use '' (empty string) to assign the name
- automatically.
- --runall=RUNALL Run the specified task for any recipe in the taskgraph
- of the specified target (even if it wouldn't otherwise
- have run).
- --runonly=RUNONLY Run only the specified task within the taskgraph of
- the specified targets (and any task dependencies those
- tasks may have).
- </literallayout>
- </para>
- </section>
-
- <section id='bitbake-examples'>
- <title>Examples</title>
-
- <para>
- This section presents some examples showing how to use BitBake.
- </para>
-
- <section id='example-executing-a-task-against-a-single-recipe'>
- <title>Executing a Task Against a Single Recipe</title>
-
- <para>
- Executing tasks for a single recipe file is relatively simple.
- You specify the file in question, and BitBake parses
- it and executes the specified task.
- If you do not specify a task, BitBake executes the default
- task, which is "build”.
- BitBake obeys inter-task dependencies when doing
- so.
- </para>
-
- <para>
- The following command runs the build task, which is
- the default task, on the <filename>foo_1.0.bb</filename>
- recipe file:
- <literallayout class='monospaced'>
- $ bitbake -b foo_1.0.bb
- </literallayout>
- The following command runs the clean task on the
- <filename>foo.bb</filename> recipe file:
- <literallayout class='monospaced'>
- $ bitbake -b foo.bb -c clean
- </literallayout>
- <note>
- The "-b" option explicitly does not handle recipe
- dependencies.
- Other than for debugging purposes, it is instead
- recommended that you use the syntax presented in the
- next section.
- </note>
- </para>
- </section>
-
- <section id='executing-tasks-against-a-set-of-recipe-files'>
- <title>Executing Tasks Against a Set of Recipe Files</title>
-
- <para>
- There are a number of additional complexities introduced
- when one wants to manage multiple <filename>.bb</filename>
- files.
- Clearly there needs to be a way to tell BitBake what
- files are available and, of those, which you
- want to execute.
- There also needs to be a way for each recipe
- to express its dependencies, both for build-time and
- runtime.
- There must be a way for you to express recipe preferences
- when multiple recipes provide the same functionality, or when
- there are multiple versions of a recipe.
- </para>
-
- <para>
- The <filename>bitbake</filename> command, when not using
- "--buildfile" or "-b" only accepts a "PROVIDES".
- You cannot provide anything else.
- By default, a recipe file generally "PROVIDES" its
- "packagename" as shown in the following example:
- <literallayout class='monospaced'>
- $ bitbake foo
- </literallayout>
- This next example "PROVIDES" the package name and also uses
- the "-c" option to tell BitBake to just execute the
- <filename>do_clean</filename> task:
- <literallayout class='monospaced'>
- $ bitbake -c clean foo
- </literallayout>
- </para>
- </section>
-
- <section id='executing-a-list-of-task-and-recipe-combinations'>
- <title>Executing a List of Task and Recipe Combinations</title>
-
- <para>
- The BitBake command line supports specifying different
- tasks for individual targets when you specify multiple
- targets.
- For example, suppose you had two targets (or recipes)
- <filename>myfirstrecipe</filename> and
- <filename>mysecondrecipe</filename> and you needed
- BitBake to run <filename>taskA</filename> for the first
- recipe and <filename>taskB</filename> for the second
- recipe:
- <literallayout class='monospaced'>
- $ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB
- </literallayout>
- </para>
- </section>
-
- <section id='generating-dependency-graphs'>
- <title>Generating Dependency Graphs</title>
-
- <para>
- BitBake is able to generate dependency graphs using
- the <filename>dot</filename> syntax.
- You can convert these graphs into images using the
- <filename>dot</filename> tool from
- <ulink url='http://www.graphviz.org'>Graphviz</ulink>.
- </para>
-
- <para>
- When you generate a dependency graph, BitBake writes two files
- to the current working directory:
- <itemizedlist>
- <listitem><para>
- <emphasis><filename>task-depends.dot</filename>:</emphasis>
- Shows dependencies between tasks.
- These dependencies match BitBake's internal task execution list.
- </para></listitem>
- <listitem><para>
- <emphasis><filename>pn-buildlist</filename>:</emphasis>
- Shows a simple list of targets that are to be built.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- To stop depending on common depends, use the "-I" depend
- option and BitBake omits them from the graph.
- Leaving this information out can produce more readable graphs.
- This way, you can remove from the graph
- <filename>DEPENDS</filename> from inherited classes
- such as <filename>base.bbclass</filename>.
- </para>
-
- <para>
- Here are two examples that create dependency graphs.
- The second example omits depends common in OpenEmbedded from
- the graph:
- <literallayout class='monospaced'>
- $ bitbake -g foo
-
- $ bitbake -g -I virtual/kernel -I eglibc foo
- </literallayout>
- </para>
- </section>
-
- <section id='executing-a-multiple-configuration-build'>
- <title>Executing a Multiple Configuration Build</title>
-
- <para>
- BitBake is able to build multiple images or packages
- using a single command where the different targets
- require different configurations (multiple configuration
- builds).
- Each target, in this scenario, is referred to as a
- "multiconfig".
- </para>
-
- <para>
- To accomplish a multiple configuration build, you must
- define each target's configuration separately using
- a parallel configuration file in the build directory.
- The location for these multiconfig configuration files
- is specific.
- They must reside in the current build directory in
- a sub-directory of <filename>conf</filename> named
- <filename>multiconfig</filename>.
- Following is an example for two separate targets:
- <imagedata fileref="figures/bb_multiconfig_files.png" align="center" width="4in" depth="3in" />
- </para>
-
- <para>
- The reason for this required file hierarchy
- is because the <filename>BBPATH</filename> variable
- is not constructed until the layers are parsed.
- Consequently, using the configuration file as a
- pre-configuration file is not possible unless it is
- located in the current working directory.
- </para>
-
- <para>
- Minimally, each configuration file must define the
- machine and the temporary directory BitBake uses
- for the build.
- Suggested practice dictates that you do not
- overlap the temporary directories used during the
- builds.
- </para>
-
- <para>
- Aside from separate configuration files for each
- target, you must also enable BitBake to perform multiple
- configuration builds.
- Enabling is accomplished by setting the
- <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
- for <filename>target1</filename> and
- <filename>target2</filename> defined in the build
- directory.
- The following statement in the
- <filename>local.conf</filename> file both enables
- BitBake to perform multiple configuration builds and
- specifies the two extra multiconfigs:
- <literallayout class='monospaced'>
- BBMULTICONFIG = "target1 target2"
- </literallayout>
- </para>
-
- <para>
- Once the target configuration files are in place and
- BitBake has been enabled to perform multiple configuration
- builds, use the following command form to start the
- builds:
- <literallayout class='monospaced'>
- $ bitbake [mc:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable> [[[mc:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable>] ... ]
- </literallayout>
- Here is an example for two extra multiconfigs:
- <filename>target1</filename> and
- <filename>target2</filename>:
- <literallayout class='monospaced'>
- $ bitbake mc::<replaceable>target</replaceable> mc:target1:<replaceable>target</replaceable> mc:target2:<replaceable>target</replaceable>
- </literallayout>
- </para>
- </section>
-
- <section id='bb-enabling-multiple-configuration-build-dependencies'>
- <title>Enabling Multiple Configuration Build Dependencies</title>
-
- <para>
- Sometimes dependencies can exist between targets
- (multiconfigs) in a multiple configuration build.
- For example, suppose that in order to build an image
- for a particular architecture, the root filesystem of
- another build for a different architecture needs to
- exist.
- In other words, the image for the first multiconfig depends
- on the root filesystem of the second multiconfig.
- This dependency is essentially that the task in the recipe
- that builds one multiconfig is dependent on the
- completion of the task in the recipe that builds
- another multiconfig.
- </para>
-
- <para>
- To enable dependencies in a multiple configuration
- build, you must declare the dependencies in the recipe
- using the following statement form:
- <literallayout class='monospaced'>
- <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] = "mc:target1:target2:<replaceable>image2</replaceable>:<replaceable>rootfs_task</replaceable>"
- </literallayout>
- In this example, the
- <replaceable>from_multiconfig</replaceable> is "target1" and
- the <replaceable>to_multiconfig</replaceable> is "target2".
- The task on which the image whose recipe contains
- <replaceable>image_task</replaceable> depends on the
- completion of the <replaceable>rootfs_task</replaceable>
- used to build out <replaceable>image2</replaceable>, which
- is associated with the "target2" multiconfig.
- </para>
-
- <para>
- Once you set up this dependency, you can build the
- "target1" multiconfig using a BitBake command as follows:
- <literallayout class='monospaced'>
- $ bitbake mc:target1:<replaceable>image1</replaceable>
- </literallayout>
- This command executes all the tasks needed to create
- <replaceable>image1</replaceable> for the "target1"
- multiconfig.
- Because of the dependency, BitBake also executes through
- the <replaceable>rootfs_task</replaceable> for the "target2"
- multiconfig build.
- </para>
-
- <para>
- Having a recipe depend on the root filesystem of another
- build might not seem that useful.
- Consider this change to the statement in the
- <replaceable>image1</replaceable> recipe:
- <literallayout class='monospaced'>
- <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"
- build since the "target1" build depends on it.
- </para>
-
- <para>
- Because "target1" and "target2" are enabled for multiple
- configuration builds and have separate configuration
- files, BitBake places the artifacts for each build in the
- respective temporary build directories.
- </para>
- </section>
- </section>
- </section>
-</chapter>
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml b/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml
deleted file mode 100644
index 0ca532161..000000000
--- a/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml
+++ /dev/null
@@ -1,2862 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id="bitbake-user-manual-metadata">
- <title>Syntax and Operators</title>
-
- <para>
- 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
- as well as provides examples.
- </para>
-
- <section id='basic-syntax'>
- <title>Basic Syntax</title>
-
- <para>
- This section provides some basic syntax examples.
- </para>
-
- <section id='basic-variable-setting'>
- <title>Basic Variable Setting</title>
-
- <para>
- The following example sets <filename>VARIABLE</filename> to
- "value".
- This assignment occurs immediately as the statement is parsed.
- It is a "hard" assignment.
- <literallayout class='monospaced'>
- VARIABLE = "value"
- </literallayout>
- As expected, if you include leading or trailing spaces as part of
- an assignment, the spaces are retained:
- <literallayout class='monospaced'>
- VARIABLE = " value"
- VARIABLE = "value "
- </literallayout>
- Setting <filename>VARIABLE</filename> to "" sets it to an empty string,
- while setting the variable to " " sets it to a blank space
- (i.e. these are not the same values).
- <literallayout class='monospaced'>
- VARIABLE = ""
- VARIABLE = " "
- </literallayout>
- </para>
-
- <para>
- You can use single quotes instead of double quotes
- when setting a variable's value.
- Doing so allows you to use values that contain the double
- quote character:
- <literallayout class='monospaced'>
- VARIABLE = 'I have a " in my value'
- </literallayout>
- <note>
- Unlike in Bourne shells, single quotes work identically
- to double quotes in all other ways.
- They do not suppress variable expansions.
- </note>
- </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>
-
- <para>
- Outside of
- <link linkend='functions'>functions</link>, BitBake joins
- any line ending in a backslash character ("\")
- with the following line before parsing statements.
- The most common use for the "\" character is to split variable
- assignments over multiple lines, as in the following example:
- <literallayout class='monospaced'>
- FOO = "bar \
- baz \
- qaz"
- </literallayout>
- Both the "\" character and the newline character
- that follow it are removed when joining lines.
- Thus, no newline characters end up in the value of
- <filename>FOO</filename>.
- </para>
-
- <para>
- Consider this additional example where the two
- assignments both assign "barbaz" to
- <filename>FOO</filename>:
- <literallayout class='monospaced'>
- FOO = "barbaz"
-
- FOO = "bar\
- baz"
- </literallayout>
- <note>
- BitBake does not interpret escape sequences like
- "\n" in variable values.
- For these to have an effect, the value must be passed
- to some utility that interprets escape sequences,
- such as <filename>printf</filename> or
- <filename>echo -n</filename>.
- </note>
- </para>
- </section>
-
- <section id='variable-expansion'>
- <title>Variable Expansion</title>
-
- <para>
- Variables can reference the contents of other variables
- using a syntax that is similar to variable expansion in
- Bourne shells.
- The following assignments
- result in A containing "aval" and B evaluating to "preavalpost".
- <literallayout class='monospaced'>
- A = "aval"
- B = "pre${A}post"
- </literallayout>
- <note>
- Unlike in Bourne shells, the curly braces are mandatory:
- Only <filename>${FOO}</filename> and not
- <filename>$FOO</filename> is recognized as an expansion of
- <filename>FOO</filename>.
- </note>
- The "=" operator does not immediately expand variable
- references in the right-hand side.
- Instead, expansion is deferred until the variable assigned to
- is actually used.
- The result depends on the current values of the referenced
- variables.
- The following example should clarify this behavior:
- <literallayout class='monospaced'>
- A = "${B} baz"
- B = "${C} bar"
- C = "foo"
- *At this point, ${A} equals "foo bar baz"*
- C = "qux"
- *At this point, ${A} equals "qux bar baz"*
- B = "norf"
- *At this point, ${A} equals "norf baz"*
- </literallayout>
- Contrast this behavior with the
- <link linkend='immediate-variable-expansion'>immediate variable expansion</link>
- operator (i.e. ":=").
- </para>
-
- <para>
- If the variable expansion syntax is used on a variable that
- does not exist, the string is kept as is.
- For example, given the following assignment,
- <filename>BAR</filename> expands to the literal string
- "${FOO}" as long as <filename>FOO</filename> does not exist.
- <literallayout class='monospaced'>
- BAR = "${FOO}"
- </literallayout>
- </para>
- </section>
-
- <section id='setting-a-default-value'>
- <title>Setting a default value (?=)</title>
-
- <para>
- You can use the "?=" operator to achieve a "softer" assignment
- for a variable.
- This type of assignment allows you to define a variable if it
- is undefined when the statement is parsed, but to leave the
- value alone if the variable has a value.
- Here is an example:
- <literallayout class='monospaced'>
- A ?= "aval"
- </literallayout>
- If <filename>A</filename> is set at the time this statement is parsed,
- the variable retains its value.
- However, if <filename>A</filename> is not set,
- the variable is set to "aval".
- <note>
- This assignment is immediate.
- Consequently, if multiple "?=" assignments
- to a single variable exist, the first of those ends up getting
- used.
- </note>
- </para>
- </section>
-
- <section id='setting-a-weak-default-value'>
- <title>Setting a weak default value (??=)</title>
-
- <para>
- It is possible to use a "weaker" assignment than in the
- previous section by using the "??=" operator.
- This assignment behaves identical to "?=" except that the
- assignment is made at the end of the parsing process rather
- than immediately.
- Consequently, when multiple "??=" assignments exist, the last
- one is used.
- Also, any "=" or "?=" assignment will override the value set with
- "??=".
- Here is an example:
- <literallayout class='monospaced'>
- A ??= "somevalue"
- A ??= "someothervalue"
- </literallayout>
- If <filename>A</filename> is set before the above statements are parsed,
- the variable retains its value.
- If <filename>A</filename> is not set,
- the variable is set to "someothervalue".
- </para>
-
- <para>
- Again, this assignment is a "lazy" or "weak" assignment
- because it does not occur until the end
- of the parsing process.
- </para>
- </section>
-
- <section id='immediate-variable-expansion'>
- <title>Immediate variable expansion (:=)</title>
-
- <para>
- The ":=" operator results in a variable's
- contents being expanded immediately,
- rather than when the variable is actually used:
- <literallayout class='monospaced'>
- T = "123"
- A := "test ${T}"
- T = "456"
- B := "${T} ${C}"
- C = "cval"
- C := "${C}append"
- </literallayout>
- In this example, <filename>A</filename> contains
- "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>
- </section>
-
- <section id='appending-and-prepending'>
- <title>Appending (+=) and prepending (=+) With Spaces</title>
-
- <para>
- Appending and prepending values is common and can be accomplished
- using the "+=" and "=+" operators.
- These operators insert a space between the current
- value and prepended or appended value.
- </para>
-
- <para>
- These operators take immediate effect during parsing.
- Here are some examples:
- <literallayout class='monospaced'>
- B = "bval"
- B += "additionaldata"
- C = "cval"
- C =+ "test"
- </literallayout>
- The variable <filename>B</filename> contains
- "bval additionaldata" and <filename>C</filename>
- contains "test cval".
- </para>
- </section>
-
- <section id='appending-and-prepending-without-spaces'>
- <title>Appending (.=) and Prepending (=.) Without Spaces</title>
-
- <para>
- If you want to append or prepend values without an
- inserted space, use the ".=" and "=." operators.
- </para>
-
- <para>
- These operators take immediate effect during parsing.
- Here are some examples:
- <literallayout class='monospaced'>
- B = "bval"
- B .= "additionaldata"
- C = "cval"
- C =. "test"
- </literallayout>
- The variable <filename>B</filename> contains
- "bvaladditionaldata" and
- <filename>C</filename> contains "testcval".
- </para>
- </section>
-
- <section id='appending-and-prepending-override-style-syntax'>
- <title>Appending and Prepending (Override Style Syntax)</title>
-
- <para>
- You can also append and prepend a variable's value
- using an override style syntax.
- When you use this syntax, no spaces are inserted.
- </para>
-
- <para>
- These operators differ from the ":=", ".=", "=.", "+=", and "=+"
- 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"
- B_append = " additional data"
- C = "cval"
- C_prepend = "additional data "
- D = "dval"
- D_append = "additional data"
- </literallayout>
- The variable <filename>B</filename> becomes
- "bval additional data" and <filename>C</filename> becomes
- "additional data cval".
- The variable <filename>D</filename> becomes
- "dvaladditional data".
- <note>
- You must control all spacing when you use the
- override syntax.
- </note>
- </para>
-
- <para>
- It is also possible to append and prepend to shell
- functions and BitBake-style Python functions.
- See the
- "<link linkend='shell-functions'>Shell Functions</link>" and
- "<link linkend='bitbake-style-python-functions'>BitBake-Style Python Functions</link>
- sections for examples.
- </para>
- </section>
-
- <section id='removing-override-style-syntax'>
- <title>Removal (Override Style Syntax)</title>
-
- <para>
- You can remove values from lists using the removal
- override style syntax.
- Specifying a value for removal causes all occurrences of that
- value to be removed from the variable.
- </para>
-
- <para>
- When you use this syntax, BitBake expects one or more strings.
- Surrounding spaces and spacing are preserved.
- Here is an example:
- <literallayout class='monospaced'>
- FOO = "123 456 789 123456 123 456 123 456"
- FOO_remove = "123"
- FOO_remove = "456"
- FOO2 = " abc def ghi abcdef abc def abc def def"
- FOO2_remove = " \
- def \
- abc \
- ghi \
- "
- </literallayout>
- The variable <filename>FOO</filename> becomes
- "&nbsp;&nbsp;789&nbsp;123456&nbsp;&nbsp;&nbsp;&nbsp;"
- and <filename>FOO2</filename> becomes
- "&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;abcdef&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;".
- </para>
-
- <para>
- Like "_append" and "_prepend", "_remove"
- is applied at variable expansion time.
- </para>
- </section>
-
- <section id='override-style-operation-advantages'>
- <title>Override Style Operation Advantages</title>
-
- <para>
- An advantage of the override style operations
- "_append", "_prepend", and "_remove" as compared to the
- "+=" and "=+" operators is that the override style
- operators provide guaranteed operations.
- For example, consider a class <filename>foo.bbclass</filename>
- that needs to add the value "val" to the variable
- <filename>FOO</filename>, and a recipe that uses
- <filename>foo.bbclass</filename> as follows:
- <literallayout class='monospaced'>
- inherit foo
-
- FOO = "initial"
- </literallayout>
- If <filename>foo.bbclass</filename> uses the "+=" operator,
- as follows, then the final value of <filename>FOO</filename>
- will be "initial", which is not what is desired:
- <literallayout class='monospaced'>
- FOO += "val"
- </literallayout>
- If, on the other hand, <filename>foo.bbclass</filename>
- uses the "_append" operator, then the final value of
- <filename>FOO</filename> will be "initial val", as intended:
- <literallayout class='monospaced'>
- FOO_append = " val"
- </literallayout>
- <note>
- It is never necessary to use "+=" together with "_append".
- The following sequence of assignments appends "barbaz" to
- <filename>FOO</filename>:
- <literallayout class='monospaced'>
- FOO_append = "bar"
- FOO_append = "baz"
- </literallayout>
- The only effect of changing the second assignment in the
- previous example to use "+=" would be to add a space before
- "baz" in the appended value (due to how the "+=" operator
- works).
- </note>
- Another advantage of the override style operations is that
- you can combine them with other overrides as described in the
- "<link linkend='conditional-syntax-overrides'>Conditional Syntax (Overrides)</link>"
- section.
- </para>
- </section>
-
- <section id='variable-flag-syntax'>
- <title>Variable Flag Syntax</title>
-
- <para>
- Variable flags are BitBake's implementation of variable properties
- or attributes.
- It is a way of tagging extra information onto a variable.
- You can find more out about variable flags in general in the
- "<link linkend='variable-flags'>Variable Flags</link>"
- section.
- </para>
-
- <para>
- You can define, append, and prepend values to variable flags.
- All the standard syntax operations previously mentioned work
- for variable flags except for override style syntax
- (i.e. "_prepend", "_append", and "_remove").
- </para>
-
- <para>
- Here are some examples showing how to set variable flags:
- <literallayout class='monospaced'>
- FOO[a] = "abc"
- FOO[b] = "123"
- FOO[a] += "456"
- </literallayout>
- The variable <filename>FOO</filename> has two flags:
- <filename>[a]</filename> and <filename>[b]</filename>.
- The flags are immediately set to "abc" and "123", respectively.
- The <filename>[a]</filename> flag becomes "abc 456".
- </para>
-
- <para>
- No need exists to pre-define variable flags.
- You can simply start using them.
- One extremely common application
- is to attach some brief documentation to a BitBake variable as
- follows:
- <literallayout class='monospaced'>
- CACHE[doc] = "The directory holding the cache of the metadata."
- </literallayout>
- </para>
- </section>
-
- <section id='inline-python-variable-expansion'>
- <title>Inline Python Variable Expansion</title>
-
- <para>
- You can use inline Python variable expansion to
- set variables.
- Here is an example:
- <literallayout class='monospaced'>
- DATE = "${@time.strftime('%Y%m%d',time.gmtime())}"
- </literallayout>
- This example results in the <filename>DATE</filename>
- variable being set to the current date.
- </para>
-
- <para>
- Probably the most common use of this feature is to extract
- the value of variables from BitBake's internal data dictionary,
- <filename>d</filename>.
- The following lines select the values of a package name
- and its version number, respectively:
- <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'}"
- </literallayout>
- <note>
- Inline Python expressions work just like variable expansions
- insofar as the "=" and ":=" operators are concerned.
- Given the following assignment, <filename>foo()</filename>
- is called each time <filename>FOO</filename> is expanded:
- <literallayout class='monospaced'>
- FOO = "${@foo()}"
- </literallayout>
- Contrast this with the following immediate assignment, where
- <filename>foo()</filename> is only called once, while the
- assignment is parsed:
- <literallayout class='monospaced'>
- FOO := "${@foo()}"
- </literallayout>
- </note>
- For a different way to set variables with Python code during
- parsing, see the
- "<link linkend='anonymous-python-functions'>Anonymous Python Functions</link>"
- section.
- </para>
- </section>
-
- <section id='unsetting-variables'>
- <title>Unsetting variables</title>
-
- <para>
- It is possible to completely remove a variable or a variable flag
- from BitBake's internal data dictionary by using the "unset" keyword.
- Here is an example:
- <literallayout class='monospaced'>
- unset DATE
- unset do_fetch[noexec]
- </literallayout>
- These two statements remove the <filename>DATE</filename> and the
- <filename>do_fetch[noexec]</filename> flag.
- </para>
-
- </section>
-
- <section id='providing-pathnames'>
- <title>Providing Pathnames</title>
-
- <para>
- When specifying pathnames for use with BitBake,
- do not use the tilde ("~") character as a shortcut
- for your home directory.
- Doing so might cause BitBake to not recognize the
- path since BitBake does not expand this character in
- the same way a shell would.
- </para>
-
- <para>
- Instead, provide a fuller path as the following
- example illustrates:
- <literallayout class='monospaced'>
- BBLAYERS ?= " \
- /home/scott-lenovo/LayerA \
- "
- </literallayout>
- </para>
- </section>
- </section>
-
- <section id='exporting-variables-to-the-environment'>
- <title>Exporting Variables to the Environment</title>
-
- <para>
- You can export variables to the environment of running
- tasks by using the <filename>export</filename> keyword.
- For example, in the following example, the
- <filename>do_foo</filename> task prints "value from
- the environment" when run:
- <literallayout class='monospaced'>
- export ENV_VARIABLE
- ENV_VARIABLE = "value from the environment"
-
- do_foo() {
- bbplain "$ENV_VARIABLE"
- }
- </literallayout>
- <note>
- BitBake does not expand <filename>$ENV_VARIABLE</filename>
- in this case because it lacks the obligatory
- <filename>{}</filename>.
- Rather, <filename>$ENV_VARIABLE</filename> is expanded
- by the shell.
- </note>
- It does not matter whether
- <filename>export ENV_VARIABLE</filename> appears before or
- after assignments to <filename>ENV_VARIABLE</filename>.
- </para>
-
- <para>
- It is also possible to combine <filename>export</filename>
- with setting a value for the variable.
- Here is an example:
- <literallayout class='monospaced'>
- export ENV_VARIABLE = "<replaceable>variable-value</replaceable>"
- </literallayout>
- In the output of <filename>bitbake -e</filename>, variables
- that are exported to the environment are preceded by "export".
- </para>
-
- <para>
- Among the variables commonly exported to the environment
- are <filename>CC</filename> and <filename>CFLAGS</filename>,
- which are picked up by many build systems.
- </para>
- </section>
-
- <section id='conditional-syntax-overrides'>
- <title>Conditional Syntax (Overrides)</title>
-
- <para>
- BitBake uses
- <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
- <filename>OVERRIDES</filename> as conditional metadata,
- talks about key expansion in relationship to
- <filename>OVERRIDES</filename>, and provides some examples
- to help with understanding.
- </para>
-
- <section id='conditional-metadata'>
- <title>Conditional Metadata</title>
-
- <para>
- You can use <filename>OVERRIDES</filename> to conditionally select
- a specific version of a variable and to conditionally
- append or prepend the value of a variable.
- <note>
- Overrides can only use lower-case characters.
- Additionally, underscores are not permitted in override names
- as they are used to separate overrides from each other and
- from the variable name.
- </note>
- <itemizedlist>
- <listitem><para><emphasis>Selecting a Variable:</emphasis>
- The <filename>OVERRIDES</filename> variable is
- a colon-character-separated list that contains items
- for which you want to satisfy conditions.
- Thus, if you have a variable that is conditional on “arm”, and “arm”
- is in <filename>OVERRIDES</filename>, then the “arm”-specific
- version of the variable is used rather than the non-conditional
- version.
- Here is an example:
- <literallayout class='monospaced'>
- OVERRIDES = "architecture:os:machine"
- TEST = "default"
- TEST_os = "osspecific"
- TEST_nooverride = "othercondvalue"
- </literallayout>
- In this example, the <filename>OVERRIDES</filename>
- variable lists three overrides:
- "architecture", "os", and "machine".
- The variable <filename>TEST</filename> by itself has a default
- value of "default".
- You select the os-specific version of the <filename>TEST</filename>
- variable by appending the "os" override to the variable
- (i.e.<filename>TEST_os</filename>).
- </para>
-
- <para>
- To better understand this, consider a practical example
- that assumes an OpenEmbedded metadata-based Linux
- kernel recipe file.
- The following lines from the recipe file first set
- the kernel branch variable <filename>KBRANCH</filename>
- to a default value, then conditionally override that
- value based on the architecture of the build:
- <literallayout class='monospaced'>
- KBRANCH = "standard/base"
- KBRANCH_qemuarm = "standard/arm-versatile-926ejs"
- KBRANCH_qemumips = "standard/mti-malta32"
- KBRANCH_qemuppc = "standard/qemuppc"
- KBRANCH_qemux86 = "standard/common-pc/base"
- KBRANCH_qemux86-64 = "standard/common-pc-64/base"
- KBRANCH_qemumips64 = "standard/mti-malta64"
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Appending and Prepending:</emphasis>
- BitBake also supports append and prepend operations to
- variable values based on whether a specific item is
- listed in <filename>OVERRIDES</filename>.
- Here is an example:
- <literallayout class='monospaced'>
- DEPENDS = "glibc ncurses"
- OVERRIDES = "machine:local"
- DEPENDS_append_machine = " libmad"
- </literallayout>
- In this example, <filename>DEPENDS</filename> becomes
- "glibc ncurses libmad".
- </para>
-
- <para>
- Again, using an OpenEmbedded metadata-based
- kernel recipe file as an example, the
- following lines will conditionally append to the
- <filename>KERNEL_FEATURES</filename> variable based
- on the architecture:
- <literallayout class='monospaced'>
- KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
- KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
- KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
- </literallayout>
- </para></listitem>
- <listitem><para><emphasis>Setting a Variable for a Single Task:</emphasis>
- BitBake supports setting a variable just for the
- duration of a single task.
- Here is an example:
- <literallayout class='monospaced'>
- FOO_task-configure = "val 1"
- FOO_task-compile = "val 2"
- </literallayout>
- In the previous example, <filename>FOO</filename>
- has the value "val 1" while the
- <filename>do_configure</filename> task is executed,
- and the value "val 2" while the
- <filename>do_compile</filename> task is executed.
- </para>
-
- <para>Internally, this is implemented by prepending
- the task (e.g. "task-compile:") to the value of
- <link linkend='var-bb-OVERRIDES'><filename>OVERRIDES</filename></link>
- for the local datastore of the <filename>do_compile</filename>
- task.</para>
-
- <para>You can also use this syntax with other combinations
- (e.g. "<filename>_prepend</filename>") as shown in the
- following example:
- <literallayout class='monospaced'>
- EXTRA_OEMAKE_prepend_task-compile = "${PARALLEL_MAKE} "
- </literallayout>
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='key-expansion'>
- <title>Key Expansion</title>
-
- <para>
- 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,
- 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>
- </section>
-
- <section id='variable-interaction-worked-examples'>
- <title>Examples</title>
-
- <para>
- Despite the previous explanations that show the different forms of
- variable definitions, it can be hard to work
- out exactly what happens when variable operators, conditional
- overrides, and unconditional overrides are combined.
- This section presents some common scenarios along
- with explanations for variable interactions that
- typically confuse users.
- </para>
-
- <para>
- There is often confusion concerning the order in which
- overrides and various "append" operators take effect.
- Recall that an append or prepend operation using "_append"
- and "_prepend" does not result in an immediate assignment
- as would "+=", ".=", "=+", or "=.".
- Consider the following example:
- <literallayout class='monospaced'>
- OVERRIDES = "foo"
- A = "Z"
- A_foo_append = "X"
- </literallayout>
- For this case, <filename>A</filename> is
- unconditionally set to "Z" and "X" is
- unconditionally and immediately appended to the variable
- <filename>A_foo</filename>.
- Because overrides have not been applied yet,
- <filename>A_foo</filename> is set to "X" due to the append
- and <filename>A</filename> simply equals "Z".
- </para>
-
- <para>
- Applying overrides, however, changes things.
- Since "foo" is listed in <filename>OVERRIDES</filename>,
- the conditional variable <filename>A</filename> is replaced
- with the "foo" version, which is equal to "X".
- So effectively, <filename>A_foo</filename> replaces <filename>A</filename>.
- </para>
-
- <para>
- This next example changes the order of the override and
- the append:
- <literallayout class='monospaced'>
- OVERRIDES = "foo"
- A = "Z"
- A_append_foo = "X"
- </literallayout>
- For this case, before overrides are handled,
- <filename>A</filename> is set to "Z" and <filename>A_append_foo</filename>
- is set to "X".
- Once the override for "foo" is applied, however,
- <filename>A</filename> gets appended with "X".
- Consequently, <filename>A</filename> becomes "ZX".
- Notice that spaces are not appended.
- </para>
-
- <para>
- This next example has the order of the appends and overrides reversed
- back as in the first example:
- <literallayout class='monospaced'>
- OVERRIDES = "foo"
- A = "Y"
- A_foo_append = "Z"
- A_foo_append = "X"
- </literallayout>
- For this case, before any overrides are resolved,
- <filename>A</filename> is set to "Y" using an immediate assignment.
- After this immediate assignment, <filename>A_foo</filename> is set
- to "Z", and then further appended with
- "X" leaving the variable set to "ZX".
- Finally, applying the override for "foo" results in the conditional
- variable <filename>A</filename> becoming "ZX" (i.e.
- <filename>A</filename> is replaced with <filename>A_foo</filename>).
- </para>
-
- <para>
- This final example mixes in some varying operators:
- <literallayout class='monospaced'>
- A = "1"
- A_append = "2"
- A_append = "3"
- A += "4"
- A .= "5"
- </literallayout>
- For this case, the type of append operators are affecting the
- order of assignments as BitBake passes through the code
- multiple times.
- Initially, <filename>A</filename> is set to "1 45" because
- of the three statements that use immediate operators.
- After these assignments are made, BitBake applies the
- "_append" operations.
- Those operations result in <filename>A</filename> becoming "1 4523".
- </para>
- </section>
- </section>
-
- <section id='sharing-functionality'>
- <title>Sharing Functionality</title>
-
- <para>
- BitBake allows for metadata sharing through include files
- (<filename>.inc</filename>) and class files
- (<filename>.bbclass</filename>).
- For example, suppose you have a piece of common functionality
- such as a task definition that you want to share between
- more than one recipe.
- In this case, creating a <filename>.bbclass</filename>
- file that contains the common functionality and then using
- the <filename>inherit</filename> directive in your recipes to
- inherit the class would be a common way to share the task.
- </para>
-
- <para>
- This section presents the mechanisms BitBake provides to
- allow you to share functionality between recipes.
- Specifically, the mechanisms include <filename>include</filename>,
- <filename>inherit</filename>, <filename>INHERIT</filename>, and
- <filename>require</filename> directives.
- </para>
-
- <section id='locating-include-and-class-files'>
- <title>Locating Include and Class Files</title>
-
- <para>
- BitBake uses the
- <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>
- directives.
- <note>
- The <filename>BBPATH</filename> variable is analogous to
- the environment variable <filename>PATH</filename>.
- </note>
- </para>
-
- <para>
- In order for include and class files to be found by BitBake,
- they need to be located in a "classes" subdirectory that can
- be found in <filename>BBPATH</filename>.
- </para>
- </section>
-
- <section id='inherit-directive'>
- <title><filename>inherit</filename> Directive</title>
-
- <para>
- When writing a recipe or class file, you can use the
- <filename>inherit</filename> directive to inherit the
- functionality of a class (<filename>.bbclass</filename>).
- BitBake only supports this directive when used within recipe
- and class files (i.e. <filename>.bb</filename> and
- <filename>.bbclass</filename>).
- </para>
-
- <para>
- The <filename>inherit</filename> directive is a rudimentary
- means of specifying functionality contained in class files
- that your recipes require.
- For example, you can easily abstract out the tasks involved in
- building a package that uses Autoconf and Automake and put
- those tasks into a class file and then have your recipe
- inherit that class file.
- </para>
-
- <para>
- As an example, your recipes could use the following directive
- to inherit an <filename>autotools.bbclass</filename> file.
- The class file would contain common functionality for using
- Autotools that could be shared across recipes:
- <literallayout class='monospaced'>
- inherit autotools
- </literallayout>
- In this case, BitBake would search for the directory
- <filename>classes/autotools.bbclass</filename>
- in <filename>BBPATH</filename>.
- <note>
- You can override any values and functions of the
- inherited class within your recipe by doing so
- after the "inherit" statement.
- </note>
- If you want to use the directive to inherit
- multiple classes, separate them with spaces.
- The following example shows how to inherit both the
- <filename>buildhistory</filename> and <filename>rm_work</filename>
- classes:
- <literallayout class='monospaced'>
- inherit buildhistory rm_work
- </literallayout>
- </para>
-
- <para>
- An advantage with the inherit directive as compared to both
- the
- <link linkend='include-directive'>include</link> and
- <link linkend='require-inclusion'>require</link> directives
- is that you can inherit class files conditionally.
- You can accomplish this by using a variable expression
- after the <filename>inherit</filename> statement.
- Here is an example:
- <literallayout class='monospaced'>
- inherit ${VARNAME}
- </literallayout>
- If <filename>VARNAME</filename> is going to be set, it needs
- to be set before the <filename>inherit</filename> statement
- is parsed.
- One way to achieve a conditional inherit in this case is to use
- overrides:
- <literallayout class='monospaced'>
- VARIABLE = ""
- VARIABLE_someoverride = "myclass"
- </literallayout>
- </para>
-
- <para>
- Another method is by using anonymous Python.
- Here is an example:
- <literallayout class='monospaced'>
- python () {
- if condition == value:
- d.setVar('VARIABLE', 'myclass')
- else:
- d.setVar('VARIABLE', '')
- }
- </literallayout>
- </para>
-
- <para>
- Alternatively, you could use an in-line Python expression
- in the following form:
- <literallayout class='monospaced'>
- inherit ${@'classname' if condition else ''}
- inherit ${@functionname(params)}
- </literallayout>
- In all cases, if the expression evaluates to an empty
- string, the statement does not trigger a syntax error
- because it becomes a no-op.
- </para>
- </section>
-
- <section id='include-directive'>
- <title><filename>include</filename> Directive</title>
-
- <para>
- BitBake understands the <filename>include</filename>
- directive.
- This directive causes BitBake to parse whatever file you specify,
- and to insert that file at that location.
- The directive is much like its equivalent in Make except
- that if the path specified on the include line is a relative
- path, BitBake locates the first file it can find
- within <filename>BBPATH</filename>.
- </para>
-
- <para>
- The include directive is a more generic method of including
- functionality as compared to the
- <link linkend='inherit-directive'>inherit</link> directive,
- which is restricted to class (i.e. <filename>.bbclass</filename>)
- files.
- The include directive is applicable for any other kind of
- shared or encapsulated functionality or configuration that
- does not suit a <filename>.bbclass</filename> file.
- </para>
-
- <para>
- As an example, suppose you needed a recipe to include some
- self-test definitions:
- <literallayout class='monospaced'>
- include test_defs.inc
- </literallayout>
- <note>
- The <filename>include</filename> directive does not
- produce an error when the file cannot be found.
- Consequently, it is recommended that if the file you
- are including is expected to exist, you should use
- <link linkend='require-inclusion'><filename>require</filename></link>
- instead of <filename>include</filename>.
- Doing so makes sure that an error is produced if the
- file cannot be found.
- </note>
- </para>
- </section>
-
- <section id='require-inclusion'>
- <title><filename>require</filename> Directive</title>
-
- <para>
- BitBake understands the <filename>require</filename>
- directive.
- This directive behaves just like the
- <filename>include</filename> directive with the exception that
- BitBake raises a parsing error if the file to be included cannot
- be found.
- Thus, any file you require is inserted into the file that is
- being parsed at the location of the directive.
- </para>
-
- <para>
- The require directive, like the include directive previously
- described, is a more generic method of including
- functionality as compared to the
- <link linkend='inherit-directive'>inherit</link> directive,
- which is restricted to class (i.e. <filename>.bbclass</filename>)
- files.
- The require directive is applicable for any other kind of
- shared or encapsulated functionality or configuration that
- does not suit a <filename>.bbclass</filename> file.
- </para>
-
- <para>
- Similar to how BitBake handles
- <link linkend='include-directive'><filename>include</filename></link>,
- if the path specified
- on the require line is a relative path, BitBake locates
- the first file it can find within <filename>BBPATH</filename>.
- </para>
-
- <para>
- As an example, suppose you have two versions of a recipe
- (e.g. <filename>foo_1.2.2.bb</filename> and
- <filename>foo_2.0.0.bb</filename>) where
- each version contains some identical functionality that could be
- shared.
- You could create an include file named <filename>foo.inc</filename>
- that contains the common definitions needed to build "foo".
- You need to be sure <filename>foo.inc</filename> is located in the
- same directory as your two recipe files as well.
- Once these conditions are set up, you can share the functionality
- using a <filename>require</filename> directive from within each
- recipe:
- <literallayout class='monospaced'>
- require foo.inc
- </literallayout>
- </para>
- </section>
-
- <section id='inherit-configuration-directive'>
- <title><filename>INHERIT</filename> Configuration Directive</title>
-
- <para>
- When creating a configuration file (<filename>.conf</filename>),
- you can use the
- <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.
- </para>
-
- <para>
- As an example, suppose you needed to inherit a class
- file called <filename>abc.bbclass</filename> from a
- configuration file as follows:
- <literallayout class='monospaced'>
- INHERIT += "abc"
- </literallayout>
- This configuration directive causes the named
- class to be inherited at the point of the directive
- during parsing.
- As with the <filename>inherit</filename> directive, the
- <filename>.bbclass</filename> file must be located in a
- "classes" subdirectory in one of the directories specified
- in <filename>BBPATH</filename>.
- <note>
- Because <filename>.conf</filename> files are parsed
- first during BitBake's execution, using
- <filename>INHERIT</filename> to inherit a class effectively
- inherits the class globally (i.e. for all recipes).
- </note>
- If you want to use the directive to inherit
- multiple classes, you can provide them on the same line in the
- <filename>local.conf</filename> file.
- Use spaces to separate the classes.
- The following example shows how to inherit both the
- <filename>autotools</filename> and <filename>pkgconfig</filename>
- classes:
- <literallayout class='monospaced'>
- INHERIT += "autotools pkgconfig"
- </literallayout>
- </para>
- </section>
- </section>
-
- <section id='functions'>
- <title>Functions</title>
-
- <para>
- As with most languages, functions are the building blocks that
- are used to build up operations into tasks.
- BitBake supports these types of functions:
- <itemizedlist>
- <listitem><para><emphasis>Shell Functions:</emphasis>
- Functions written in shell script and executed either
- directly as functions, tasks, or both.
- They can also be called by other shell functions.
- </para></listitem>
- <listitem><para><emphasis>BitBake-Style Python Functions:</emphasis>
- Functions written in Python and executed by BitBake or other
- Python functions using <filename>bb.build.exec_func()</filename>.
- </para></listitem>
- <listitem><para><emphasis>Python Functions:</emphasis>
- Functions written in Python and executed by Python.
- </para></listitem>
- <listitem><para><emphasis>Anonymous Python Functions:</emphasis>
- Python functions executed automatically during
- parsing.
- </para></listitem>
- </itemizedlist>
- Regardless of the type of function, you can only
- define them in class (<filename>.bbclass</filename>)
- and recipe (<filename>.bb</filename> or <filename>.inc</filename>)
- files.
- </para>
-
- <section id='shell-functions'>
- <title>Shell Functions</title>
-
- <para>
- Functions written in shell script and executed either
- directly as functions, tasks, or both.
- They can also be called by other shell functions.
- Here is an example shell function definition:
- <literallayout class='monospaced'>
- some_function () {
- echo "Hello World"
- }
- </literallayout>
- When you create these types of functions in your recipe
- or class files, you need to follow the shell programming
- rules.
- The scripts are executed by <filename>/bin/sh</filename>,
- which may not be a bash shell but might be something
- such as <filename>dash</filename>.
- You should not use Bash-specific script (bashisms).
- </para>
-
- <para>
- Overrides and override-style operators like
- <filename>_append</filename> and
- <filename>_prepend</filename> can also be applied to
- shell functions.
- Most commonly, this application would be used in a
- <filename>.bbappend</filename> file to modify functions in
- the main recipe.
- It can also be used to modify functions inherited from
- classes.
- </para>
-
- <para>
- As an example, consider the following:
- <literallayout class='monospaced'>
- do_foo() {
- bbplain first
- fn
- }
-
- fn_prepend() {
- bbplain second
- }
-
- fn() {
- bbplain third
- }
-
- do_foo_append() {
- bbplain fourth
- }
- </literallayout>
- Running <filename>do_foo</filename>
- prints the following:
- <literallayout class='monospaced'>
- recipename do_foo: first
- recipename do_foo: second
- recipename do_foo: third
- recipename do_foo: fourth
- </literallayout>
- <note>
- Overrides and override-style operators can
- be applied to any shell function, not just
- <link linkend='tasks'>tasks</link>.
- </note>
- You can use the <filename>bitbake -e</filename>&nbsp;<replaceable>recipename</replaceable>
- command to view the final assembled function
- after all overrides have been applied.
- </para>
- </section>
-
- <section id='bitbake-style-python-functions'>
- <title>BitBake-Style Python Functions</title>
-
- <para>
- These functions are written in Python and executed by
- BitBake or other Python functions using
- <filename>bb.build.exec_func()</filename>.
- </para>
-
- <para>
- An example BitBake function is:
- <literallayout class='monospaced'>
- python some_python_function () {
- d.setVar("TEXT", "Hello World")
- print d.getVar("TEXT")
- }
- </literallayout>
- Because the Python "bb" and "os" modules are already
- imported, you do not need to import these modules.
- Also in these types of functions, the datastore ("d")
- is a global variable and is always automatically
- available.
- <note>
- Variable expressions (e.g. <filename>${X}</filename>)
- are no longer expanded within Python functions.
- This behavior is intentional in order to allow you
- to freely set variable values to expandable expressions
- without having them expanded prematurely.
- If you do wish to expand a variable within a Python
- function, use <filename>d.getVar("X")</filename>.
- Or, for more complicated expressions, use
- <filename>d.expand()</filename>.
- </note>
- </para>
-
- <para>
- Similar to shell functions, you can also apply overrides
- and override-style operators to BitBake-style Python
- functions.
- </para>
-
- <para>
- As an example, consider the following:
- <literallayout class='monospaced'>
- python do_foo_prepend() {
- bb.plain("first")
- }
-
- python do_foo() {
- bb.plain("second")
- }
-
- python do_foo_append() {
- bb.plain("third")
- }
- </literallayout>
- Running <filename>do_foo</filename> prints
- the following:
- <literallayout class='monospaced'>
- recipename do_foo: first
- recipename do_foo: second
- recipename do_foo: third
- </literallayout>
- You can use the <filename>bitbake -e</filename>&nbsp;<replaceable>recipename</replaceable>
- command to view the final assembled function
- after all overrides have been applied.
- </para>
- </section>
-
- <section id='python-functions'>
- <title>Python Functions</title>
-
- <para>
- These functions are written in Python and are executed by
- other Python code.
- Examples of Python functions are utility functions
- that you intend to call from in-line Python or
- from within other Python functions.
- Here is an example:
- <literallayout class='monospaced'>
- def get_depends(d):
- if d.getVar('SOMECONDITION'):
- return "dependencywithcond"
- else:
- return "dependency"
- SOMECONDITION = "1"
- DEPENDS = "${@get_depends(d)}"
- </literallayout>
- This would result in <filename>DEPENDS</filename>
- containing <filename>dependencywithcond</filename>.
- </para>
-
- <para>
- Here are some things to know about Python functions:
- <itemizedlist>
- <listitem><para>Python functions can take parameters.
- </para></listitem>
- <listitem><para>The BitBake datastore is not
- automatically available.
- Consequently, you must pass it in as a
- parameter to the function.
- </para></listitem>
- <listitem><para>The "bb" and "os" Python modules are
- automatically available.
- You do not need to import them.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='bitbake-style-python-functions-versus-python-functions'>
- <title>BitBake-Style Python Functions Versus Python Functions</title>
-
- <para>
- Following are some important differences between
- BitBake-style Python functions and regular Python
- functions defined with "def":
- <itemizedlist>
- <listitem><para>
- Only BitBake-style Python functions can be
- <link linkend='tasks'>tasks</link>.
- </para></listitem>
- <listitem><para>
- Overrides and override-style operators can only
- be applied to BitBake-style Python functions.
- </para></listitem>
- <listitem><para>
- Only regular Python functions can take arguments
- and return values.
- </para></listitem>
- <listitem><para>
- <link linkend='variable-flags'>Variable flags</link>
- such as <filename>[dirs]</filename>,
- <filename>[cleandirs]</filename>, and
- <filename>[lockfiles]</filename> can be used
- on BitBake-style Python functions, but not on
- regular Python functions.
- </para></listitem>
- <listitem><para>
- BitBake-style Python functions generate a separate
- <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>
- if they are executed as tasks.</para>
-
- <para>
- Regular Python functions execute "inline" and do not
- generate any files in <filename>${T}</filename>.
- </para></listitem>
- <listitem><para>
- Regular Python functions are called with the usual
- Python syntax.
- BitBake-style Python functions are usually tasks and
- are called directly by BitBake, but can also be called
- manually from Python code by using the
- <filename>bb.build.exec_func()</filename> function.
- Here is an example:
- <literallayout class='monospaced'>
- bb.build.exec_func("my_bitbake_style_function", d)
- </literallayout>
- <note>
- <filename>bb.build.exec_func()</filename> can also
- be used to run shell functions from Python code.
- If you want to run a shell function before a Python
- function within the same task, then you can use a
- parent helper Python function that starts by running
- the shell function with
- <filename>bb.build.exec_func()</filename> and then
- runs the Python code.
- </note></para>
-
- <para>To detect errors from functions executed with
- <filename>bb.build.exec_func()</filename>, you
- can catch the <filename>bb.build.FuncFailed</filename>
- exception.
- <note>
- Functions in metadata (recipes and classes) should
- not themselves raise
- <filename>bb.build.FuncFailed</filename>.
- Rather, <filename>bb.build.FuncFailed</filename>
- should be viewed as a general indicator that the
- called function failed by raising an exception.
- For example, an exception raised by
- <filename>bb.fatal()</filename> will be caught inside
- <filename>bb.build.exec_func()</filename>, and a
- <filename>bb.build.FuncFailed</filename> will be raised
- in response.
- </note>
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Due to their simplicity, you should prefer regular Python functions
- over BitBake-style Python functions unless you need a feature specific
- to BitBake-style Python functions.
- Regular Python functions in metadata are a more recent invention than
- BitBake-style Python functions, and older code tends to use
- <filename>bb.build.exec_func()</filename> more often.
- </para>
- </section>
-
- <section id='anonymous-python-functions'>
- <title>Anonymous Python Functions</title>
-
- <para>
- Sometimes it is useful to set variables or perform
- other operations programmatically during parsing.
- To do this, you can define special Python functions,
- called anonymous Python functions, that run at the
- end of parsing.
- For example, the following conditionally sets a variable
- based on the value of another variable:
- <literallayout class='monospaced'>
- python () {
- if d.getVar('SOMEVAR') == 'value':
- d.setVar('ANOTHERVAR', 'value2')
- }
- </literallayout>
- An equivalent way to mark a function as an anonymous
- function is to give it the name "__anonymous", rather
- than no name.
- </para>
-
- <para>
- Anonymous Python functions always run at the end
- of parsing, regardless of where they are defined.
- If a recipe contains many anonymous functions, they
- run in the same order as they are defined within the
- recipe.
- As an example, consider the following snippet:
- <literallayout class='monospaced'>
- python () {
- d.setVar('FOO', 'foo 2')
- }
-
- FOO = "foo 1"
-
- python () {
- d.appendVar('BAR', ' bar 2')
- }
-
- BAR = "bar 1"
- </literallayout>
- The previous example is conceptually equivalent to the
- following snippet:
- <literallayout class='monospaced'>
- FOO = "foo 1"
- BAR = "bar 1"
- FOO = "foo 2"
- BAR += "bar 2"
- </literallayout>
- <filename>FOO</filename> ends up with the value "foo 2",
- and <filename>BAR</filename> with the value "bar 1 bar 2".
- Just as in the second snippet, the values set for the
- variables within the anonymous functions become available
- to tasks, which always run after parsing.
- </para>
-
- <para>
- Overrides and override-style operators such as
- "<filename>_append</filename>" are applied before
- anonymous functions run.
- In the following example, <filename>FOO</filename> ends
- up with the value "foo from anonymous":
- <literallayout class='monospaced'>
- FOO = "foo"
- FOO_append = " from outside"
-
- python () {
- d.setVar("FOO", "foo from anonymous")
- }
- </literallayout>
- For methods you can use with anonymous Python functions,
- see the
- "<link linkend='functions-you-can-call-from-within-python'>Functions You Can Call From Within Python</link>"
- section.
- For a different method to run Python code during parsing,
- see the
- "<link linkend='inline-python-variable-expansion'>Inline Python Variable Expansion</link>"
- section.
- </para>
- </section>
-
- <section id='flexible-inheritance-for-class-functions'>
- <title>Flexible Inheritance for Class Functions</title>
-
- <para>
- Through coding techniques and the use of
- <filename>EXPORT_FUNCTIONS</filename>, BitBake supports
- exporting a function from a class such that the
- class function appears as the default implementation
- of the function, but can still be called if a recipe
- inheriting the class needs to define its own version of
- the function.
- </para>
-
- <para>
- To understand the benefits of this feature, consider
- the basic scenario where a class defines a task function
- and your recipe inherits the class.
- In this basic scenario, your recipe inherits the task
- function as defined in the class.
- If desired, your recipe can add to the start and end of the
- function by using the "_prepend" or "_append" operations
- respectively, or it can redefine the function completely.
- However, if it redefines the function, there is
- no means for it to call the class version of the function.
- <filename>EXPORT_FUNCTIONS</filename> provides a mechanism
- that enables the recipe's version of the function to call
- the original version of the function.
- </para>
-
- <para>
- To make use of this technique, you need the following
- things in place:
- <itemizedlist>
- <listitem><para>
- The class needs to define the function as follows:
- <literallayout class='monospaced'>
- <replaceable>classname</replaceable><filename>_</filename><replaceable>functionname</replaceable>
- </literallayout>
- For example, if you have a class file
- <filename>bar.bbclass</filename> and a function named
- <filename>do_foo</filename>, the class must define the function
- as follows:
- <literallayout class='monospaced'>
- bar_do_foo
- </literallayout>
- </para></listitem>
- <listitem><para>
- The class needs to contain the <filename>EXPORT_FUNCTIONS</filename>
- statement as follows:
- <literallayout class='monospaced'>
- EXPORT_FUNCTIONS <replaceable>functionname</replaceable>
- </literallayout>
- For example, continuing with the same example, the
- statement in the <filename>bar.bbclass</filename> would be
- as follows:
- <literallayout class='monospaced'>
- EXPORT_FUNCTIONS do_foo
- </literallayout>
- </para></listitem>
- <listitem><para>
- You need to call the function appropriately from within your
- recipe.
- Continuing with the same example, if your recipe
- needs to call the class version of the function,
- it should call <filename>bar_do_foo</filename>.
- Assuming <filename>do_foo</filename> was a shell function
- and <filename>EXPORT_FUNCTIONS</filename> was used as above,
- the recipe's function could conditionally call the
- class version of the function as follows:
- <literallayout class='monospaced'>
- do_foo() {
- if [ somecondition ] ; then
- bar_do_foo
- else
- # Do something else
- fi
- }
- </literallayout>
- To call your modified version of the function as defined
- in your recipe, call it as <filename>do_foo</filename>.
- </para></listitem>
- </itemizedlist>
- With these conditions met, your single recipe
- can freely choose between the original function
- as defined in the class file and the modified function in your recipe.
- If you do not set up these conditions, you are limited to using one function
- or the other.
- </para>
- </section>
- </section>
-
- <section id='tasks'>
- <title>Tasks</title>
-
- <para>
- Tasks are BitBake execution units that make up the
- steps that BitBake can run for a given recipe.
- Tasks are only supported in recipes and classes
- (i.e. in <filename>.bb</filename> files and files
- included or inherited from <filename>.bb</filename>
- files).
- By convention, tasks have names that start with "do_".
- </para>
-
- <section id='promoting-a-function-to-a-task'>
- <title>Promoting a Function to a Task</title>
-
- <para>
- Tasks are either
- <link linkend='shell-functions'>shell functions</link> or
- <link linkend='bitbake-style-python-functions'>BitBake-style Python functions</link>
- that have been promoted to tasks by using the
- <filename>addtask</filename> command.
- The <filename>addtask</filename> command can also
- optionally describe dependencies between the
- task and other tasks.
- Here is an example that shows how to define a task
- and declare some dependencies:
- <literallayout class='monospaced'>
- python do_printdate () {
- import time
- print time.strftime('%Y%m%d', time.gmtime())
- }
- addtask printdate after do_fetch before do_build
- </literallayout>
- The first argument to <filename>addtask</filename>
- is the name of the function to promote to
- a task.
- If the name does not start with "do_", "do_" is
- implicitly added, which enforces the convention that
- all task names start with "do_".
- </para>
-
- <para>
- In the previous example, the
- <filename>do_printdate</filename> task becomes a
- dependency of the <filename>do_build</filename>
- task, which is the default task (i.e. the task run by
- the <filename>bitbake</filename> command unless
- another task is specified explicitly).
- Additionally, the <filename>do_printdate</filename>
- task becomes dependent upon the
- <filename>do_fetch</filename> task.
- Running the <filename>do_build</filename> task
- results in the <filename>do_printdate</filename>
- task running first.
- <note>
- If you try out the previous example, you might see that
- the <filename>do_printdate</filename> task is only run
- the first time you build the recipe with
- the <filename>bitbake</filename> command.
- This is because BitBake considers the task "up-to-date"
- after that initial run.
- If you want to force the task to always be rerun for
- experimentation purposes, you can make BitBake always
- consider the task "out-of-date" by using the
- <filename>[</filename><link linkend='variable-flags'><filename>nostamp</filename></link><filename>]</filename>
- variable flag, as follows:
- <literallayout class='monospaced'>
- do_printdate[nostamp] = "1"
- </literallayout>
- You can also explicitly run the task and provide the
- <filename>-f</filename> option as follows:
- <literallayout class='monospaced'>
- $ bitbake <replaceable>recipe</replaceable> -c printdate -f
- </literallayout>
- When manually selecting a task to run with the
- <filename>bitbake</filename>&nbsp;<replaceable>recipe</replaceable>&nbsp;<filename>-c</filename>&nbsp;<replaceable>task</replaceable>
- command, you can omit the "do_" prefix as part of the
- task name.
- </note>
- </para>
-
- <para>
- You might wonder about the practical effects of using
- <filename>addtask</filename> without specifying any
- dependencies as is done in the following example:
- <literallayout class='monospaced'>
- addtask printdate
- </literallayout>
- In this example, assuming dependencies have not been
- added through some other means, the only way to run
- the task is by explicitly selecting it with
- <filename>bitbake</filename>&nbsp;<replaceable>recipe</replaceable>&nbsp;<filename>-c printdate</filename>.
- You can use the
- <filename>do_listtasks</filename> task to list all tasks
- defined in a recipe as shown in the following example:
- <literallayout class='monospaced'>
- $ bitbake <replaceable>recipe</replaceable> -c listtasks
- </literallayout>
- For more information on task dependencies, see the
- "<link linkend='dependencies'>Dependencies</link>"
- section.
- </para>
-
- <para>
- See the
- "<link linkend='variable-flags'>Variable Flags</link>"
- section for information on variable flags you can use with
- tasks.
- </para>
- </section>
-
- <section id='deleting-a-task'>
- <title>Deleting a Task</title>
-
- <para>
- As well as being able to add tasks, you can delete them.
- Simply use the <filename>deltask</filename> command to
- delete a task.
- For example, to delete the example task used in the previous
- sections, you would use:
- <literallayout class='monospaced'>
- deltask printdate
- </literallayout>
- If you delete a task using the <filename>deltask</filename>
- command and the task has dependencies, the dependencies are
- not reconnected.
- For example, suppose you have three tasks named
- <filename>do_a</filename>, <filename>do_b</filename>, and
- <filename>do_c</filename>.
- Furthermore, <filename>do_c</filename> is dependent on
- <filename>do_b</filename>, which in turn is dependent on
- <filename>do_a</filename>.
- Given this scenario, if you use <filename>deltask</filename>
- to delete <filename>do_b</filename>, the implicit dependency
- relationship between <filename>do_c</filename> and
- <filename>do_a</filename> through <filename>do_b</filename>
- no longer exists, and <filename>do_c</filename> dependencies
- are not updated to include <filename>do_a</filename>.
- Thus, <filename>do_c</filename> is free to run before
- <filename>do_a</filename>.
- </para>
-
- <para>
- If you want dependencies such as these to remain intact, use
- the <filename>[noexec]</filename> varflag to disable the task
- instead of using the <filename>deltask</filename> command to
- delete it:
- <literallayout class='monospaced'>
- do_b[noexec] = "1"
- </literallayout>
- </para>
- </section>
-
- <section id='passing-information-into-the-build-task-environment'>
- <title>Passing Information Into the Build Task Environment</title>
-
- <para>
- When running a task, BitBake tightly controls the shell execution
- environment of the build tasks to make
- sure unwanted contamination from the build machine cannot
- influence the build.
- <note>
- By default, BitBake cleans the environment to include only those
- 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-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link>
- variable.
- </note>
- Consequently, if you do want something to get passed into the
- build task environment, you must take these two steps:
- <orderedlist>
- <listitem><para>
- Tell BitBake to load what you want from the environment
- into the datastore.
- You can do so through the
- <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>
- 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 BitBake to allow that
- variable into the datastore:
- <literallayout class='monospaced'>
- export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"
- </literallayout></para></listitem>
- <listitem><para>
- Tell BitBake to export what you have loaded into the
- datastore to the task environment of every running task.
- Loading something from the environment into the datastore
- (previous step) only makes it available in the datastore.
- To export it to the task environment of every running task,
- use a command similar to the following in your local configuration
- file <filename>local.conf</filename> or your
- distribution configuration file:
- <literallayout class='monospaced'>
- export CCACHE_DIR
- </literallayout>
- <note>
- A side effect of the previous steps is that BitBake
- records the variable as a dependency of the build process
- in things like the setscene checksums.
- If doing so results in unnecessary rebuilds of tasks, you can
- whitelist the variable so that the setscene code
- ignores the dependency when it creates checksums.
- </note></para></listitem>
- </orderedlist>
- </para>
-
- <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
- a special variable named
- <link linkend='var-bb-BB_ORIGENV'><filename>BB_ORIGENV</filename></link>.
- </para>
-
- <para>
- The <filename>BB_ORIGENV</filename> variable returns a datastore
- object that can be queried using the standard datastore operators
- such as <filename>getVar(, False)</filename>.
- The datastore object is useful, for example, to find the original
- <filename>DISPLAY</filename> variable.
- Here is an example:
- <literallayout class='monospaced'>
- origenv = d.getVar("BB_ORIGENV", False)
- bar = origenv.getVar("BAR", False)
- </literallayout>
- The previous example returns <filename>BAR</filename> from the original
- execution environment.
- </para>
- </section>
- </section>
-
- <section id='variable-flags'>
- <title>Variable Flags</title>
-
- <para>
- Variable flags (varflags) help control a task's functionality
- and dependencies.
- BitBake reads and writes varflags to the datastore using the following
- command forms:
- <literallayout class='monospaced'>
- <replaceable>variable</replaceable> = d.getVarFlags("<replaceable>variable</replaceable>")
- self.d.setVarFlags("FOO", {"func": True})
- </literallayout>
- </para>
-
- <para>
- When working with varflags, the same syntax, with the exception of
- overrides, applies.
- In other words, you can set, append, and prepend varflags just like
- variables.
- See the
- "<link linkend='variable-flag-syntax'>Variable Flag Syntax</link>"
- section for details.
- </para>
-
- <para>
- BitBake has a defined set of varflags available for recipes and
- classes.
- Tasks support a number of these flags which control various
- functionality of the task:
- <itemizedlist>
- <listitem><para><emphasis><filename>[cleandirs]</filename>:</emphasis>
- Empty directories that should be created before the
- task runs.
- Directories that already exist are removed and recreated
- to empty them.
- </para></listitem>
- <listitem><para><emphasis><filename>[depends]</filename>:</emphasis>
- Controls inter-task dependencies.
- See the
- <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.
- </para></listitem>
- <listitem><para><emphasis><filename>[deptask]</filename>:</emphasis>
- Controls task build-time dependencies.
- See the
- <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link>
- variable and the
- "<link linkend='build-dependencies'>Build Dependencies</link>"
- section for more information.
- </para></listitem>
- <listitem><para><emphasis><filename>[dirs]</filename>:</emphasis>
- Directories that should be created before the task runs.
- Directories that already exist are left as is.
- The last directory listed is used as the
- current working directory for the task.
- </para></listitem>
- <listitem><para><emphasis><filename>[lockfiles]</filename>:</emphasis>
- Specifies one or more lockfiles to lock while the task
- executes.
- Only one task may hold a lockfile, and any task that
- attempts to lock an already locked file will block until
- the lock is released.
- You can use this variable flag to accomplish mutual
- exclusion.
- </para></listitem>
- <listitem><para><emphasis><filename>[noexec]</filename>:</emphasis>
- When set to "1", marks the task as being empty, with
- no execution required.
- You can use the <filename>[noexec]</filename> flag to set up
- tasks as dependency placeholders, or to disable tasks defined
- elsewhere that are not needed in a particular recipe.
- </para></listitem>
- <listitem><para><emphasis><filename>[nostamp]</filename>:</emphasis>
- When set to "1", tells BitBake to not generate a stamp
- file for a task, which implies the task should always
- be executed.
- <note><title>Caution</title>
- Any task that depends (possibly indirectly) on a
- <filename>[nostamp]</filename> task will always be
- executed as well.
- This can cause unnecessary rebuilding if you are
- not careful.
- </note>
- </para></listitem>
- <listitem><para><emphasis><filename>[number_threads]</filename>:</emphasis>
- Limits tasks to a specific number of simultaneous threads
- during execution.
- This varflag is useful when your build host has a large number
- 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-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
- variable but is task-specific.</para>
-
- <para>Set the value globally.
- For example, the following makes sure the
- <filename>do_fetch</filename> task uses no more than two
- simultaneous execution threads:
- <literallayout class='monospaced'>
- do_fetch[number_threads] = "2"
- </literallayout>
- <note><title>Warnings</title>
- <itemizedlist>
- <listitem><para>
- Setting the varflag in individual recipes rather
- than globally can result in unpredictable behavior.
- </para></listitem>
- <listitem><para>
- Setting the varflag to a value greater than the
- value used in the <filename>BB_NUMBER_THREADS</filename>
- variable causes <filename>number_threads</filename>
- to have no effect.
- </para></listitem>
- </itemizedlist>
- </note>
- </para></listitem>
- <listitem><para><emphasis><filename>[postfuncs]</filename>:</emphasis>
- List of functions to call after the completion of the task.
- </para></listitem>
- <listitem><para><emphasis><filename>[prefuncs]</filename>:</emphasis>
- List of functions to call before the task executes.
- </para></listitem>
- <listitem><para><emphasis><filename>[rdepends]</filename>:</emphasis>
- Controls inter-task runtime dependencies.
- See the
- <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link>
- variable, the
- <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.
- </para></listitem>
- <listitem><para><emphasis><filename>[rdeptask]</filename>:</emphasis>
- Controls task runtime dependencies.
- See the
- <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link>
- variable, the
- <link linkend='var-bb-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
- variable, and the
- "<link linkend='runtime-dependencies'>Runtime Dependencies</link>"
- section for more information.
- </para></listitem>
- <listitem><para><emphasis><filename>[recideptask]</filename>:</emphasis>
- When set in conjunction with
- <filename>recrdeptask</filename>, specifies a task that
- should be inspected for additional dependencies.
- </para></listitem>
- <listitem><para><emphasis><filename>[recrdeptask]</filename>:</emphasis>
- Controls task recursive runtime dependencies.
- See the
- <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link>
- variable, the
- <link linkend='var-bb-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
- variable, and the
- "<link linkend='recursive-dependencies'>Recursive Dependencies</link>"
- section for more information.
- </para></listitem>
- <listitem><para><emphasis><filename>[stamp-extra-info]</filename>:</emphasis>
- Extra stamp information to append to the task's stamp.
- As an example, OpenEmbedded uses this flag to allow
- machine-specific tasks.
- </para></listitem>
- <listitem><para><emphasis><filename>[umask]</filename>:</emphasis>
- The umask to run the task under.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Several varflags are useful for controlling how signatures are
- calculated for variables.
- For more information on this process, see the
- "<link linkend='checksums'>Checksums (Signatures)</link>"
- section.
- <itemizedlist>
- <listitem><para><emphasis><filename>[vardeps]</filename>:</emphasis>
- Specifies a space-separated list of additional
- variables to add to a variable's dependencies
- for the purposes of calculating its signature.
- Adding variables to this list is useful, for example, when
- a function refers to a variable in a manner that
- does not allow BitBake to automatically determine
- that the variable is referred to.
- </para></listitem>
- <listitem><para><emphasis><filename>[vardepsexclude]</filename>:</emphasis>
- Specifies a space-separated list of variables
- that should be excluded from a variable's dependencies
- for the purposes of calculating its signature.
- </para></listitem>
- <listitem><para><emphasis><filename>[vardepvalue]</filename>:</emphasis>
- If set, instructs BitBake to ignore the actual
- value of the variable and instead use the specified
- value when calculating the variable's signature.
- </para></listitem>
- <listitem><para><emphasis><filename>[vardepvalueexclude]</filename>:</emphasis>
- Specifies a pipe-separated list of strings to exclude
- from the variable's value when calculating the
- variable's signature.
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='events'>
- <title>Events</title>
-
- <para>
- BitBake allows installation of event handlers within recipe
- and class files.
- Events are triggered at certain points during operation, such
- as the beginning of operation against a given recipe
- (i.e. <filename>*.bb</filename>), the start of a given task,
- a task failure, a task success, and so forth.
- The intent is to make it easy to do things like email
- notification on build failures.
- </para>
-
- <para>
- Following is an example event handler that prints the name
- of the event and the content of the
- <filename>FILE</filename> variable:
- <literallayout class='monospaced'>
- addhandler myclass_eventhandler
- python myclass_eventhandler() {
- from bb.event import getName
- print("The name of the Event is %s" % getName(e))
- print("The file we run for is %s" % d.getVar('FILE'))
- }
- myclass_eventhandler[eventmask] = "bb.event.BuildStarted bb.event.BuildCompleted"
- </literallayout>
- In the previous example, an eventmask has been set so that
- the handler only sees the "BuildStarted" and "BuildCompleted"
- events.
- This event handler gets called every time an event matching
- the eventmask is triggered.
- A global variable "e" is defined, which represents the current
- event.
- With the <filename>getName(e)</filename> method, you can get
- the name of the triggered event.
- The global datastore is available as "d".
- In legacy code, you might see "e.data" used to get the datastore.
- However, realize that "e.data" is deprecated and you should use
- "d" going forward.
- </para>
-
- <para>
- The context of the datastore is appropriate to the event
- in question.
- For example, "BuildStarted" and "BuildCompleted" events run
- before any tasks are executed so would be in the global
- configuration datastore namespace.
- No recipe-specific metadata exists in that namespace.
- The "BuildStarted" and "BuildCompleted" events also run in
- the main cooker/server process rather than any worker context.
- Thus, any changes made to the datastore would be seen by other
- cooker/server events within the current build but not seen
- outside of that build or in any worker context.
- Task events run in the actual tasks in question consequently
- have recipe-specific and task-specific contents.
- These events run in the worker context and are discarded at
- the end of task execution.
- </para>
-
- <para>
- During a standard build, the following common events might
- occur.
- The following events are the most common kinds of events that
- most metadata might have an interest in viewing:
- <itemizedlist>
- <listitem><para>
- <filename>bb.event.ConfigParsed()</filename>:
- Fired when the base configuration; which consists of
- <filename>bitbake.conf</filename>,
- <filename>base.bbclass</filename> and any global
- <filename>INHERIT</filename> statements; has been parsed.
- You can see multiple such events when each of the
- workers parse the base configuration or if the server
- changes configuration and reparses.
- Any given datastore only has one such event executed
- against it, however.
- If
- <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.
- </para></listitem>
- <listitem><para>
- <filename>bb.event.HeartbeatEvent()</filename>:
- Fires at regular time intervals of one second.
- You can configure the interval time using the
- <filename>BB_HEARTBEAT_EVENT</filename> variable.
- The event's "time" attribute is the
- <filename>time.time()</filename> value when the
- event is triggered.
- This event is useful for activities such as
- system state monitoring.
- </para></listitem>
- <listitem><para>
- <filename>bb.event.ParseStarted()</filename>:
- Fired when BitBake is about to start parsing recipes.
- This event's "total" attribute represents the number of
- recipes BitBake plans to parse.
- </para></listitem>
- <listitem><para>
- <filename>bb.event.ParseProgress()</filename>:
- Fired as parsing progresses.
- This event's "current" attribute is the number of
- recipes parsed as well as the "total" attribute.
- </para></listitem>
- <listitem><para>
- <filename>bb.event.ParseCompleted()</filename>:
- Fired when parsing is complete.
- This event's "cached", "parsed", "skipped", "virtuals",
- "masked", and "errors" attributes provide statistics
- for the parsing results.
- </para></listitem>
- <listitem><para>
- <filename>bb.event.BuildStarted()</filename>:
- Fired when a new build starts.
- BitBake fires multiple "BuildStarted" events (one per configuration)
- when multiple configuration (multiconfig) is enabled.
- </para></listitem>
- <listitem><para>
- <filename>bb.build.TaskStarted()</filename>:
- Fired when a task starts.
- This event's "taskfile" attribute points to the recipe
- from which the task originates.
- The "taskname" attribute, which is the task's name,
- includes the <filename>do_</filename> prefix, and the
- "logfile" attribute point to where the task's output is
- stored.
- Finally, the "time" attribute is the task's execution start
- time.
- </para></listitem>
- <listitem><para>
- <filename>bb.build.TaskInvalid()</filename>:
- Fired if BitBake tries to execute a task that does not exist.
- </para></listitem>
- <listitem><para>
- <filename>bb.build.TaskFailedSilent()</filename>:
- Fired for setscene tasks that fail and should not be
- presented to the user verbosely.
- </para></listitem>
- <listitem><para>
- <filename>bb.build.TaskFailed()</filename>:
- Fired for normal tasks that fail.
- </para></listitem>
- <listitem><para>
- <filename>bb.build.TaskSucceeded()</filename>:
- Fired when a task successfully completes.
- </para></listitem>
- <listitem><para>
- <filename>bb.event.BuildCompleted()</filename>:
- Fired when a build finishes.
- </para></listitem>
- <listitem><para>
- <filename>bb.cooker.CookerExit()</filename>:
- Fired when the BitBake server/cooker shuts down.
- This event is usually only seen by the UIs as a
- sign they should also shutdown.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- This next list of example events occur based on specific
- requests to the server.
- These events are often used to communicate larger pieces of
- information from the BitBake server to other parts of
- BitBake such as user interfaces:
- <itemizedlist>
- <listitem><para>
- <filename>bb.event.TreeDataPreparationStarted()</filename>
- </para></listitem>
- <listitem><para>
- <filename>bb.event.TreeDataPreparationProgress()</filename>
- </para></listitem>
- <listitem><para>
- <filename>bb.event.TreeDataPreparationCompleted()</filename>
- </para></listitem>
- <listitem><para>
- <filename>bb.event.DepTreeGenerated()</filename>
- </para></listitem>
- <listitem><para>
- <filename>bb.event.CoreBaseFilesFound()</filename>
- </para></listitem>
- <listitem><para>
- <filename>bb.event.ConfigFilePathFound()</filename>
- </para></listitem>
- <listitem><para>
- <filename>bb.event.FilesMatchingFound()</filename>
- </para></listitem>
- <listitem><para>
- <filename>bb.event.ConfigFilesFound()</filename>
- </para></listitem>
- <listitem><para>
- <filename>bb.event.TargetsTreeGenerated()</filename>
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='variants-class-extension-mechanism'>
- <title>Variants - Class Extension Mechanism</title>
-
- <para>
- BitBake supports two features that facilitate creating
- 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-bb-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link>
- and
- <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-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>,
- and <filename>multilib</filename> classes.
- </note>
- <itemizedlist>
- <listitem><para><emphasis><filename>BBCLASSEXTEND</filename>:</emphasis>
- This variable is a space separated list of classes used to "extend" the
- recipe for each variant.
- Here is an example that results in a second incarnation of the current
- recipe being available.
- This second incarnation will have the "native" class inherited.
- <literallayout class='monospaced'>
- BBCLASSEXTEND = "native"
- </literallayout></para></listitem>
- <listitem><para><emphasis><filename>BBVERSIONS</filename>:</emphasis>
- This variable allows a single recipe to build multiple versions of a
- project from a single recipe file.
- You can also specify conditional metadata
- (using the
- <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'>
- BBVERSIONS = "1.0 2.0 git"
- SRC_URI_git = "git://someurl/somepath.git"
-
- BBVERSIONS = "1.0.[0-6]:1.0.0+ \ 1.0.[7-9]:1.0.7+"
- SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;patch=1"
- </literallayout>
- The name of the range defaults to the original version of the
- recipe.
- For example, in OpenEmbedded, the recipe file
- <filename>foo_1.0.0+.bb</filename> creates a default name range
- of <filename>1.0.0+</filename>.
- This is useful because the range name is not only placed
- 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-bb-FILESPATH'><filename>FILESPATH</filename></link>).
- </para></listitem>
- </itemizedlist>
- </para>
- </section>
-
- <section id='dependencies'>
- <title>Dependencies</title>
-
- <para>
- To allow for efficient parallel processing, BitBake handles
- dependencies at the task level.
- Dependencies can exist both between tasks within a single recipe
- and between tasks in different recipes.
- Following are examples of each:
- <itemizedlist>
- <listitem><para>For tasks within a single recipe, a
- recipe's <filename>do_configure</filename>
- task might need to complete before its
- <filename>do_compile</filename> task can run.
- </para></listitem>
- <listitem><para>For tasks in different recipes, one
- recipe's <filename>do_configure</filename>
- task might require another recipe's
- <filename>do_populate_sysroot</filename>
- task to finish first such that the libraries and headers
- provided by the other recipe are available.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- This section describes several ways to declare dependencies.
- Remember, even though dependencies are declared in different ways, they
- are all simply dependencies between tasks.
- </para>
-
- <section id='dependencies-internal-to-the-bb-file'>
- <title>Dependencies Internal to the <filename>.bb</filename> File</title>
-
- <para>
- BitBake uses the <filename>addtask</filename> directive
- to manage dependencies that are internal to a given recipe
- file.
- You can use the <filename>addtask</filename> directive to
- indicate when a task is dependent on other tasks or when
- other tasks depend on that recipe.
- Here is an example:
- <literallayout class='monospaced'>
- addtask printdate after do_fetch before do_build
- </literallayout>
- In this example, the <filename>do_printdate</filename>
- task depends on the completion of the
- <filename>do_fetch</filename> task, and the
- <filename>do_build</filename> task depends on the
- completion of the <filename>do_printdate</filename>
- task.
- <note><para>
- For a task to run, it must be a direct or indirect
- dependency of some other task that is scheduled to
- run.</para>
-
- <para>For illustration, here are some examples:
- <itemizedlist>
- <listitem><para>
- The directive
- <filename>addtask mytask before do_configure</filename>
- causes <filename>do_mytask</filename> to run before
- <filename>do_configure</filename> runs.
- Be aware that <filename>do_mytask</filename> still only
- runs if its <link linkend='checksums'>input checksum</link>
- has changed since the last time it was run.
- Changes to the input checksum of
- <filename>do_mytask</filename> also indirectly cause
- <filename>do_configure</filename> to run.
- </para></listitem>
- <listitem><para>
- The directive
- <filename>addtask mytask after do_configure</filename>
- by itself never causes <filename>do_mytask</filename>
- to run.
- <filename>do_mytask</filename> can still be run manually
- as follows:
- <literallayout class='monospaced'>
- $ bitbake <replaceable>recipe</replaceable> -c mytask
- </literallayout>
- Declaring <filename>do_mytask</filename> as a dependency
- of some other task that is scheduled to run also causes
- it to run.
- Regardless, the task runs after
- <filename>do_configure</filename>.
- </para></listitem>
- </itemizedlist></para>
- </note>
- </para>
- </section>
-
- <section id='build-dependencies'>
- <title>Build Dependencies</title>
-
- <para>
- BitBake uses the
- <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
- item listed in <filename>DEPENDS</filename> that must
- complete before that task can be executed.
- Here is an example:
- <literallayout class='monospaced'>
- do_configure[deptask] = "do_populate_sysroot"
- </literallayout>
- In this example, the <filename>do_populate_sysroot</filename>
- task of each item in <filename>DEPENDS</filename> must complete before
- <filename>do_configure</filename> can execute.
- </para>
- </section>
-
- <section id='runtime-dependencies'>
- <title>Runtime Dependencies</title>
-
- <para>
- BitBake uses the
- <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>
-
- <para>
- The <filename>PACKAGES</filename> variable lists runtime
- packages.
- Each of those packages can have <filename>RDEPENDS</filename> and
- <filename>RRECOMMENDS</filename> runtime dependencies.
- The <filename>[rdeptask]</filename> flag for tasks is used to
- signify the task of each
- item runtime dependency which must have completed before that
- task can be executed.
- <literallayout class='monospaced'>
- do_package_qa[rdeptask] = "do_packagedata"
- </literallayout>
- 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>
-
- <section id='recursive-dependencies'>
- <title>Recursive Dependencies</title>
-
- <para>
- BitBake uses the <filename>[recrdeptask]</filename> flag to manage
- recursive task dependencies.
- BitBake looks through the build-time and runtime
- dependencies of the current recipe, looks through
- the task's inter-task
- dependencies, and then adds dependencies for the
- listed task.
- Once BitBake has accomplished this, it recursively works through
- the dependencies of those tasks.
- Iterative passes continue until all dependencies are discovered
- and added.
- </para>
-
- <para>
- The <filename>[recrdeptask]</filename> flag is most commonly
- used in high-level
- recipes that need to wait for some task to finish "globally".
- For example, <filename>image.bbclass</filename> has the following:
- <literallayout class='monospaced'>
- do_rootfs[recrdeptask] += "do_packagedata"
- </literallayout>
- This statement says that the <filename>do_packagedata</filename>
- task of the current recipe and all recipes reachable
- (by way of dependencies) from the
- image recipe must run before the <filename>do_rootfs</filename>
- task can run.
- </para>
-
- <para>
- 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>
-
- <section id='inter-task-dependencies'>
- <title>Inter-Task Dependencies</title>
-
- <para>
- BitBake uses the <filename>[depends]</filename>
- flag in a more generic form
- to manage inter-task dependencies.
- This more generic form allows for inter-dependency
- checks for specific tasks rather than checks for
- the data in <filename>DEPENDS</filename>.
- Here is an example:
- <literallayout class='monospaced'>
- do_patch[depends] = "quilt-native:do_populate_sysroot"
- </literallayout>
- In this example, the <filename>do_populate_sysroot</filename>
- task of the target <filename>quilt-native</filename>
- must have completed before the
- <filename>do_patch</filename> task can execute.
- </para>
-
- <para>
- The <filename>[rdepends]</filename> flag works in a similar
- way but takes targets
- in the runtime namespace instead of the build-time dependency
- namespace.
- </para>
- </section>
- </section>
-
- <section id='functions-you-can-call-from-within-python'>
- <title>Functions You Can Call From Within Python</title>
-
- <para>
- BitBake provides many functions you can call from
- within Python functions.
- This section lists the most commonly used functions,
- and mentions where to find others.
- </para>
-
- <section id='functions-for-accessing-datastore-variables'>
- <title>Functions for Accessing Datastore Variables</title>
-
- <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
- access.
- Here is a list of available operations:
- </para>
-
- <para>
- <informaltable frame='none'>
- <tgroup cols='2' align='left' colsep='1' rowsep='1'>
- <colspec colname='c1' colwidth='1*'/>
- <colspec colname='c2' colwidth='1*'/>
- <thead>
- <row>
- <entry align="left"><emphasis>Operation</emphasis></entry>
- <entry align="left"><emphasis>Description</emphasis></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry align="left"><filename>d.getVar("X", expand)</filename></entry>
- <entry align="left">Returns the value of variable "X".
- Using "expand=True" expands the value.
- Returns "None" if the variable "X" does not exist.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.setVar("X", "value")</filename></entry>
- <entry align="left">Sets the variable "X" to "value".</entry>
- </row>
- <row>
- <entry align="left"><filename>d.appendVar("X", "value")</filename></entry>
- <entry align="left">Adds "value" to the end of the variable "X".
- Acts like <filename>d.setVar("X", "value")</filename>
- if the variable "X" does not exist.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.prependVar("X", "value")</filename></entry>
- <entry align="left">Adds "value" to the start of the variable "X".
- Acts like <filename>d.setVar("X", "value")</filename>
- if the variable "X" does not exist.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.delVar("X")</filename></entry>
- <entry align="left">Deletes the variable "X" from the datastore.
- Does nothing if the variable "X" does not exist.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.renameVar("X", "Y")</filename></entry>
- <entry align="left">Renames the variable "X" to "Y".
- Does nothing if the variable "X" does not exist.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.getVarFlag("X", flag, expand)</filename></entry>
- <entry align="left">Returns the value of variable "X".
- Using "expand=True" expands the value.
- Returns "None" if either the variable "X" or the named flag
- does not exist.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.setVarFlag("X", flag, "value")</filename></entry>
- <entry align="left">Sets the named flag for variable "X" to "value".</entry>
- </row>
- <row>
- <entry align="left"><filename>d.appendVarFlag("X", flag, "value")</filename></entry>
- <entry align="left">Appends "value" to the named flag on the
- variable "X".
- Acts like <filename>d.setVarFlag("X", flag, "value")</filename>
- if the named flag does not exist.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.prependVarFlag("X", flag, "value")</filename></entry>
- <entry align="left">Prepends "value" to the named flag on
- the variable "X".
- Acts like <filename>d.setVarFlag("X", flag, "value")</filename>
- if the named flag does not exist.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.delVarFlag("X", flag)</filename></entry>
- <entry align="left">Deletes the named flag on the variable
- "X" from the datastore.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.setVarFlags("X", flagsdict)</filename></entry>
- <entry align="left">Sets the flags specified in
- the <filename>flagsdict()</filename> parameter.
- <filename>setVarFlags</filename> does not clear previous flags.
- Think of this operation as <filename>addVarFlags</filename>.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.getVarFlags("X")</filename></entry>
- <entry align="left">Returns a <filename>flagsdict</filename>
- of the flags for the variable "X".
- Returns "None" if the variable "X" does not exist.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.delVarFlags("X")</filename></entry>
- <entry align="left">Deletes all the flags for the variable "X".
- Does nothing if the variable "X" does not exist.</entry>
- </row>
- <row>
- <entry align="left"><filename>d.expand(expression)</filename></entry>
- <entry align="left">Expands variable references in the specified
- string expression.
- References to variables that do not exist are left as is.
- For example, <filename>d.expand("foo ${X}")</filename>
- expands to the literal string "foo ${X}" if the
- variable "X" does not exist.</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </para>
- </section>
-
- <section id='other-functions'>
- <title>Other Functions</title>
-
- <para>
- You can find many other functions that can be called
- from Python by looking at the source code of the
- <filename>bb</filename> module, which is in
- <filename>bitbake/lib/bb</filename>.
- For example,
- <filename>bitbake/lib/bb/utils.py</filename> includes
- the commonly used functions
- <filename>bb.utils.contains()</filename> and
- <filename>bb.utils.mkdirhier()</filename>, which come
- with docstrings.
- </para>
- </section>
- </section>
-
- <section id='task-checksums-and-setscene'>
- <title>Task Checksums and Setscene</title>
-
- <para>
- BitBake uses checksums (or signatures) along with the setscene
- to determine if a task needs to be run.
- This section describes the process.
- To help understand how BitBake does this, the section assumes an
- OpenEmbedded metadata-based example.
- </para>
-
- <para>
- These checksums are stored in
- <link linkend='var-bb-STAMP'><filename>STAMP</filename></link>.
- You can examine the checksums using the following BitBake command:
- <literallayout class='monospaced'>
- $ bitbake-dumpsigs
- </literallayout>
- This command returns the signature data in a readable format
- that allows you to examine the inputs used when the
- OpenEmbedded build system generates signatures.
- For example, using <filename>bitbake-dumpsigs</filename>
- allows you to examine the <filename>do_compile</filename>
- task's “sigdata” for a C application (e.g.
- <filename>bash</filename>).
- Running the command also reveals that the “CC” variable is part of
- the inputs that are hashed.
- Any changes to this variable would invalidate the stamp and
- cause the <filename>do_compile</filename> task to run.
- </para>
-
- <para>
- The following list describes related variables:
- <itemizedlist>
- <listitem><para>
- <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-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-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-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-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-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-bb-STAMP'><filename>STAMP</filename></link>:
- The base path to create stamp files.
- </para></listitem>
- <listitem><para>
- <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>
- </itemizedlist>
- </para>
- </section>
-
- <section id='wildcard-support-in-variables'>
- <title>Wildcard Support in Variables</title>
-
- <para>
- Support for wildcard use in variables varies depending on the
- context in which it is used.
- For example, some variables and file names allow limited use of
- wildcards through the "<filename>%</filename>" and
- "<filename>*</filename>" characters.
- Other variables or names support Python's
- <ulink url='https://docs.python.org/3/library/glob.html'><filename>glob</filename></ulink>
- syntax,
- <ulink url='https://docs.python.org/3/library/fnmatch.html#module-fnmatch'><filename>fnmatch</filename></ulink>
- syntax, or
- <ulink url='https://docs.python.org/3/library/re.html#re'><filename>Regular Expression (re)</filename></ulink>
- syntax.
- </para>
-
- <para>
- For variables that have wildcard suport, the
- documentation describes which form of wildcard, its
- use, and its limitations.
- </para>
- </section>
-
-</chapter>
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml b/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
deleted file mode 100644
index 4c29b2464..000000000
--- a/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
--->
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-style.css b/doc/bitbake-user-manual/bitbake-user-manual-style.css
deleted file mode 100644
index 65da2a4e3..000000000
--- a/doc/bitbake-user-manual/bitbake-user-manual-style.css
+++ /dev/null
@@ -1,984 +0,0 @@
-/*
- Generic XHTML / DocBook XHTML CSS Stylesheet.
-
- Browser wrangling and typographic design by
- Oyvind Kolas / pippin@gimp.org
-
- Customised for Poky by
- Matthew Allum / mallum@o-hand.com
-
- Thanks to:
- Liam R. E. Quin
- William Skaggs
- Jakub Steiner
-
- Structure
- ---------
-
- The stylesheet is divided into the following sections:
-
- Positioning
- Margins, paddings, width, font-size, clearing.
- Decorations
- Borders, style
- Colors
- Colors
- Graphics
- Graphical backgrounds
- Nasty IE tweaks
- Workarounds needed to make it work in internet explorer,
- currently makes the stylesheet non validating, but up until
- this point it is validating.
- Mozilla extensions
- Transparency for footer
- Rounded corners on boxes
-
-*/
-
-
- /*************** /
- / Positioning /
-/ ***************/
-
-body {
- font-family: Verdana, Sans, sans-serif;
-
- min-width: 640px;
- width: 80%;
- margin: 0em auto;
- padding: 2em 5em 5em 5em;
- color: #333;
-}
-
-h1,h2,h3,h4,h5,h6,h7 {
- font-family: Arial, Sans;
- color: #00557D;
- clear: both;
-}
-
-h1 {
- font-size: 2em;
- text-align: left;
- padding: 0em 0em 0em 0em;
- margin: 2em 0em 0em 0em;
-}
-
-h2.subtitle {
- margin: 0.10em 0em 3.0em 0em;
- padding: 0em 0em 0em 0em;
- font-size: 1.8em;
- padding-left: 20%;
- font-weight: normal;
- font-style: italic;
-}
-
-h2 {
- margin: 2em 0em 0.66em 0em;
- padding: 0.5em 0em 0em 0em;
- font-size: 1.5em;
- font-weight: bold;
-}
-
-h3.subtitle {
- margin: 0em 0em 1em 0em;
- padding: 0em 0em 0em 0em;
- font-size: 142.14%;
- text-align: right;
-}
-
-h3 {
- margin: 1em 0em 0.5em 0em;
- padding: 1em 0em 0em 0em;
- font-size: 140%;
- font-weight: bold;
-}
-
-h4 {
- margin: 1em 0em 0.5em 0em;
- padding: 1em 0em 0em 0em;
- font-size: 120%;
- font-weight: bold;
-}
-
-h5 {
- margin: 1em 0em 0.5em 0em;
- padding: 1em 0em 0em 0em;
- font-size: 110%;
- font-weight: bold;
-}
-
-h6 {
- margin: 1em 0em 0em 0em;
- padding: 1em 0em 0em 0em;
- font-size: 110%;
- font-weight: bold;
-}
-
-.authorgroup {
- background-color: transparent;
- background-repeat: no-repeat;
- padding-top: 256px;
- background-image: url("figures/bitbake-title.png");
- background-position: left top;
- margin-top: -256px;
- padding-right: 50px;
- margin-left: 0px;
- text-align: right;
- width: 740px;
-}
-
-h3.author {
- margin: 0em 0me 0em 0em;
- padding: 0em 0em 0em 0em;
- font-weight: normal;
- font-size: 100%;
- color: #333;
- clear: both;
-}
-
-.author tt.email {
- font-size: 66%;
-}
-
-.titlepage hr {
- width: 0em;
- clear: both;
-}
-
-.revhistory {
- padding-top: 2em;
- clear: both;
-}
-
-.toc,
-.list-of-tables,
-.list-of-examples,
-.list-of-figures {
- padding: 1.33em 0em 2.5em 0em;
- color: #00557D;
-}
-
-.toc p,
-.list-of-tables p,
-.list-of-figures p,
-.list-of-examples p {
- padding: 0em 0em 0em 0em;
- padding: 0em 0em 0.3em;
- margin: 1.5em 0em 0em 0em;
-}
-
-.toc p b,
-.list-of-tables p b,
-.list-of-figures p b,
-.list-of-examples p b{
- font-size: 100.0%;
- font-weight: bold;
-}
-
-.toc dl,
-.list-of-tables dl,
-.list-of-figures dl,
-.list-of-examples dl {
- margin: 0em 0em 0.5em 0em;
- padding: 0em 0em 0em 0em;
-}
-
-.toc dt {
- margin: 0em 0em 0em 0em;
- padding: 0em 0em 0em 0em;
-}
-
-.toc dd {
- margin: 0em 0em 0em 2.6em;
- padding: 0em 0em 0em 0em;
-}
-
-div.glossary dl,
-div.variablelist dl {
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
- font-weight: normal;
- width: 20em;
- text-align: right;
-}
-
-.variablelist dl dt {
- margin-top: 0.5em;
-}
-
-.glossary dl dd,
-.variablelist dl dd {
- margin-top: -1em;
- margin-left: 25.5em;
-}
-
-.glossary dd p,
-.variablelist dd p {
- margin-top: 0em;
- margin-bottom: 1em;
-}
-
-
-div.calloutlist table td {
- padding: 0em 0em 0em 0em;
- margin: 0em 0em 0em 0em;
-}
-
-div.calloutlist table td p {
- margin-top: 0em;
- margin-bottom: 1em;
-}
-
-div p.copyright {
- text-align: left;
-}
-
-div.legalnotice p.legalnotice-title {
- margin-bottom: 0em;
-}
-
-p {
- line-height: 1.5em;
- margin-top: 0em;
-
-}
-
-dl {
- padding-top: 0em;
-}
-
-hr {
- border: solid 1px;
-}
-
-
-.mediaobject,
-.mediaobjectco {
- text-align: center;
-}
-
-img {
- border: none;
-}
-
-ul {
- padding: 0em 0em 0em 1.5em;
-}
-
-ul li {
- padding: 0em 0em 0em 0em;
-}
-
-ul li p {
- text-align: left;
-}
-
-table {
- width :100%;
-}
-
-th {
- padding: 0.25em;
- text-align: left;
- font-weight: normal;
- vertical-align: top;
-}
-
-td {
- padding: 0.25em;
- vertical-align: top;
-}
-
-p a[id] {
- margin: 0px;
- padding: 0px;
- display: inline;
- background-image: none;
-}
-
-a {
- text-decoration: underline;
- color: #444;
-}
-
-pre {
- overflow: auto;
-}
-
-a:hover {
- text-decoration: underline;
- /*font-weight: bold;*/
-}
-
-/* This style defines how the permalink character
- appears by itself and when hovered over with
- the mouse. */
-
-[alt='Permalink'] { color: #eee; }
-[alt='Permalink']:hover { color: black; }
-
-
-div.informalfigure,
-div.informalexample,
-div.informaltable,
-div.figure,
-div.table,
-div.example {
- margin: 1em 0em;
- padding: 1em;
- page-break-inside: avoid;
-}
-
-
-div.informalfigure p.title b,
-div.informalexample p.title b,
-div.informaltable p.title b,
-div.figure p.title b,
-div.example p.title b,
-div.table p.title b{
- padding-top: 0em;
- margin-top: 0em;
- font-size: 100%;
- font-weight: normal;
-}
-
-.mediaobject .caption,
-.mediaobject .caption p {
- text-align: center;
- font-size: 80%;
- padding-top: 0.5em;
- padding-bottom: 0.5em;
-}
-
-.epigraph {
- padding-left: 55%;
- margin-bottom: 1em;
-}
-
-.epigraph p {
- text-align: left;
-}
-
-.epigraph .quote {
- font-style: italic;
-}
-.epigraph .attribution {
- font-style: normal;
- text-align: right;
-}
-
-span.application {
- font-style: italic;
-}
-
-.programlisting {
- font-family: monospace;
- font-size: 80%;
- white-space: pre;
- margin: 1.33em 0em;
- padding: 1.33em;
-}
-
-.tip,
-.warning,
-.caution,
-.note {
- margin-top: 1em;
- margin-bottom: 1em;
-
-}
-
-/* force full width of table within div */
-.tip table,
-.warning table,
-.caution table,
-.note table {
- border: none;
- width: 100%;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
- padding: 0.8em 0.0em 0.0em 0.0em;
- margin : 0em 0em 0em 0em;
-}
-
-.tip p,
-.warning p,
-.caution p,
-.note p {
- margin-top: 0.5em;
- margin-bottom: 0.5em;
- padding-right: 1em;
- text-align: left;
-}
-
-.acronym {
- text-transform: uppercase;
-}
-
-b.keycap,
-.keycap {
- padding: 0.09em 0.3em;
- margin: 0em;
-}
-
-.itemizedlist li {
- clear: none;
-}
-
-.filename {
- font-size: medium;
- font-family: Courier, monospace;
-}
-
-
-div.navheader, div.heading{
- position: absolute;
- left: 0em;
- top: 0em;
- width: 100%;
- background-color: #cdf;
- width: 100%;
-}
-
-div.navfooter, div.footing{
- position: fixed;
- left: 0em;
- bottom: 0em;
- background-color: #eee;
- width: 100%;
-}
-
-
-div.navheader td,
-div.navfooter td {
- font-size: 66%;
-}
-
-div.navheader table th {
- /*font-family: Georgia, Times, serif;*/
- /*font-size: x-large;*/
- font-size: 80%;
-}
-
-div.navheader table {
- border-left: 0em;
- border-right: 0em;
- border-top: 0em;
- width: 100%;
-}
-
-div.navfooter table {
- border-left: 0em;
- border-right: 0em;
- border-bottom: 0em;
- width: 100%;
-}
-
-div.navheader table td a,
-div.navfooter table td a {
- color: #777;
- text-decoration: none;
-}
-
-/* normal text in the footer */
-div.navfooter table td {
- color: black;
-}
-
-div.navheader table td a:visited,
-div.navfooter table td a:visited {
- color: #444;
-}
-
-
-/* links in header and footer */
-div.navheader table td a:hover,
-div.navfooter table td a:hover {
- text-decoration: underline;
- background-color: transparent;
- color: #33a;
-}
-
-div.navheader hr,
-div.navfooter hr {
- display: none;
-}
-
-
-.qandaset tr.question td p {
- margin: 0em 0em 1em 0em;
- padding: 0em 0em 0em 0em;
-}
-
-.qandaset tr.answer td p {
- margin: 0em 0em 1em 0em;
- padding: 0em 0em 0em 0em;
-}
-.answer td {
- padding-bottom: 1.5em;
-}
-
-.emphasis {
- font-weight: bold;
-}
-
-
- /************* /
- / decorations /
-/ *************/
-
-.titlepage {
-}
-
-.part .title {
-}
-
-.subtitle {
- border: none;
-}
-
-/*
-h1 {
- border: none;
-}
-
-h2 {
- border-top: solid 0.2em;
- border-bottom: solid 0.06em;
-}
-
-h3 {
- border-top: 0em;
- border-bottom: solid 0.06em;
-}
-
-h4 {
- border: 0em;
- border-bottom: solid 0.06em;
-}
-
-h5 {
- border: 0em;
-}
-*/
-
-.programlisting {
- border: solid 1px;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example {
- border: 1px solid;
-}
-
-
-
-.tip,
-.warning,
-.caution,
-.note {
- border: 1px solid;
-}
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
- border-bottom: 1px solid;
-}
-
-.question td {
- border-top: 1px solid black;
-}
-
-.answer {
-}
-
-
-b.keycap,
-.keycap {
- border: 1px solid;
-}
-
-
-div.navheader, div.heading{
- border-bottom: 1px solid;
-}
-
-
-div.navfooter, div.footing{
- border-top: 1px solid;
-}
-
- /********* /
- / colors /
-/ *********/
-
-body {
- color: #333;
- background: white;
-}
-
-a {
- background: transparent;
-}
-
-a:hover {
- background-color: #dedede;
-}
-
-
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7,
-h8 {
- background-color: transparent;
-}
-
-hr {
- border-color: #aaa;
-}
-
-
-.tip, .warning, .caution, .note {
- border-color: #fff;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
- border-bottom-color: #fff;
-}
-
-
-.warning {
- background-color: #f0f0f2;
-}
-
-.caution {
- background-color: #f0f0f2;
-}
-
-.tip {
- background-color: #f0f0f2;
-}
-
-.note {
- background-color: #f0f0f2;
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
- color: #044;
-}
-
-div.figure,
-div.table,
-div.example,
-div.informalfigure,
-div.informaltable,
-div.informalexample {
- border-color: #aaa;
-}
-
-pre.programlisting {
- color: black;
- background-color: #fff;
- border-color: #aaa;
- border-width: 2px;
-}
-
-.guimenu,
-.guilabel,
-.guimenuitem {
- background-color: #eee;
-}
-
-
-b.keycap,
-.keycap {
- background-color: #eee;
- border-color: #999;
-}
-
-
-div.navheader {
- border-color: black;
-}
-
-
-div.navfooter {
- border-color: black;
-}
-
-
- /*********** /
- / graphics /
-/ ***********/
-
-/*
-body {
- background-image: url("images/body_bg.jpg");
- background-attachment: fixed;
-}
-
-.navheader,
-.note,
-.tip {
- background-image: url("images/note_bg.jpg");
- background-attachment: fixed;
-}
-
-.warning,
-.caution {
- background-image: url("images/warning_bg.jpg");
- background-attachment: fixed;
-}
-
-.figure,
-.informalfigure,
-.example,
-.informalexample,
-.table,
-.informaltable {
- background-image: url("images/figure_bg.jpg");
- background-attachment: fixed;
-}
-
-*/
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7{
-}
-
-/*
-Example of how to stick an image as part of the title.
-
-div.article .titlepage .title
-{
- background-image: url("figures/white-on-black.png");
- background-position: center;
- background-repeat: repeat-x;
-}
-*/
-
-div.preface .titlepage .title,
-div.colophon .title,
-div.chapter .titlepage .title,
-div.article .titlepage .title
-{
-}
-
-div.section div.section .titlepage .title,
-div.sect2 .titlepage .title {
- background: none;
-}
-
-
-h1.title {
- background-color: transparent;
- background-repeat: no-repeat;
- height: 256px;
- text-indent: -9000px;
- overflow:hidden;
-}
-
-h2.subtitle {
- background-color: transparent;
- text-indent: -9000px;
- overflow:hidden;
- width: 0px;
- display: none;
-}
-
- /*************************************** /
- / pippin.gimp.org specific alterations /
-/ ***************************************/
-
-/*
-div.heading, div.navheader {
- color: #777;
- font-size: 80%;
- padding: 0;
- margin: 0;
- text-align: left;
- position: absolute;
- top: 0px;
- left: 0px;
- width: 100%;
- height: 50px;
- background: url('/gfx/heading_bg.png') transparent;
- background-repeat: repeat-x;
- background-attachment: fixed;
- border: none;
-}
-
-div.heading a {
- color: #444;
-}
-
-div.footing, div.navfooter {
- border: none;
- color: #ddd;
- font-size: 80%;
- text-align:right;
-
- width: 100%;
- padding-top: 10px;
- position: absolute;
- bottom: 0px;
- left: 0px;
-
- background: url('/gfx/footing_bg.png') transparent;
-}
-*/
-
-
-
- /****************** /
- / nasty ie tweaks /
-/ ******************/
-
-/*
-div.heading, div.navheader {
- width:expression(document.body.clientWidth + "px");
-}
-
-div.footing, div.navfooter {
- width:expression(document.body.clientWidth + "px");
- margin-left:expression("-5em");
-}
-body {
- padding:expression("4em 5em 0em 5em");
-}
-*/
-
- /**************************************** /
- / mozilla vendor specific css extensions /
-/ ****************************************/
-/*
-div.navfooter, div.footing{
- -moz-opacity: 0.8em;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example,
-.tip,
-.warning,
-.caution,
-.note {
- -moz-border-radius: 0.5em;
-}
-
-b.keycap,
-.keycap {
- -moz-border-radius: 0.3em;
-}
-*/
-
-table tr td table tr td {
- display: none;
-}
-
-
-hr {
- display: none;
-}
-
-table {
- border: 0em;
-}
-
- .photo {
- float: right;
- margin-left: 1.5em;
- margin-bottom: 1.5em;
- margin-top: 0em;
- max-width: 17em;
- border: 1px solid gray;
- padding: 3px;
- background: white;
-}
- .seperator {
- padding-top: 2em;
- clear: both;
- }
-
- #validators {
- margin-top: 5em;
- text-align: right;
- color: #777;
- }
- @media print {
- body {
- font-size: 8pt;
- }
- .noprint {
- display: none;
- }
- }
-
-
-.tip,
-.note {
- background: #f0f0f2;
- color: #333;
- padding: 20px;
- margin: 20px;
-}
-
-.tip h3,
-.note h3 {
- padding: 0em;
- margin: 0em;
- font-size: 2em;
- font-weight: bold;
- color: #333;
-}
-
-.tip a,
-.note a {
- color: #333;
- text-decoration: underline;
-}
-
-.footnote {
- font-size: small;
- color: #333;
-}
-
-/* Changes the announcement text */
-.tip h3,
-.warning h3,
-.caution h3,
-.note h3 {
- font-size:large;
- color: #00557D;
-}
diff --git a/doc/bitbake-user-manual/bitbake-user-manual.xml b/doc/bitbake-user-manual/bitbake-user-manual.xml
deleted file mode 100644
index d793265c9..000000000
--- a/doc/bitbake-user-manual/bitbake-user-manual.xml
+++ /dev/null
@@ -1,88 +0,0 @@
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<book id='bitbake-user-manual' lang='en'
- xmlns:xi="http://www.w3.org/2003/XInclude"
- xmlns="http://docbook.org/ns/docbook"
- >
- <bookinfo>
-
- <mediaobject>
- <imageobject>
- <imagedata fileref='figures/bitbake-title.png'
- format='SVG'
- align='left' scalefit='1' width='100%'/>
- </imageobject>
- </mediaobject>
-
- <title>
- BitBake User Manual
- </title>
-
- <authorgroup>
- <author>
- <firstname>Richard Purdie, Chris Larson, and </firstname> <surname>Phil Blundell</surname>
- <affiliation>
- <orgname>BitBake Community</orgname>
- </affiliation>
- <email>bitbake-devel@lists.openembedded.org</email>
- </author>
- </authorgroup>
-
-<!--
-# Add in some revision history if we want it here.
- <revhistory>
- <revision>
- <revnumber>x.x</revnumber>
- <date>dd month year</date>
- <revremark>Some relevent comment</revremark>
- </revision>
- <revision>
- <revnumber>x.x</revnumber>
- <date>dd month year</date>
- <revremark>Some relevent comment</revremark>
- </revision>
- <revision>
- <revnumber>x.x</revnumber>
- <date>dd month year</date>
- <revremark>Some relevent comment</revremark>
- </revision>
- <revision>
- <revnumber>x.x</revnumber>
- <date>dd month year</date>
- <revremark>Some relevent comment</revremark>
- </revision>
- </revhistory>
--->
-
- <copyright>
- <year>2004-2018</year>
- <holder>Richard Purdie</holder>
- <holder>Chris Larson</holder>
- <holder>and Phil Blundell</holder>
- </copyright>
-
- <legalnotice>
- <para>
- This work is licensed under the Creative Commons Attribution License.
- To view a copy of this license, visit
- <ulink url="http://creativecommons.org/licenses/by/2.5/">http://creativecommons.org/licenses/by/2.5/</ulink>
- or send a letter to Creative Commons, 444 Castro Street,
- Suite 900, Mountain View, California 94041, USA.
- </para>
- </legalnotice>
- </bookinfo>
-
- <xi:include href="bitbake-user-manual-intro.xml"/>
-
- <xi:include href="bitbake-user-manual-execution.xml"/>
-
- <xi:include href="bitbake-user-manual-metadata.xml"/>
-
- <xi:include href="bitbake-user-manual-fetching.xml"/>
-
- <xi:include href="bitbake-user-manual-ref-variables.xml"/>
-
- <xi:include href="bitbake-user-manual-hello.xml"/>
-
-</book>
diff --git a/doc/bitbake-user-manual/html.css b/doc/bitbake-user-manual/html.css
deleted file mode 100644
index 6eedfd318..000000000
--- a/doc/bitbake-user-manual/html.css
+++ /dev/null
@@ -1,281 +0,0 @@
-/* Feuille de style DocBook du projet Traduc.org */
-/* DocBook CSS stylesheet of the Traduc.org project */
-
-/* (c) Jean-Philippe Gurard - 14 aot 2004 */
-/* (c) Jean-Philippe Gurard - 14 August 2004 */
-
-/* Cette feuille de style est libre, vous pouvez la */
-/* redistribuer et la modifier selon les termes de la Licence */
-/* Art Libre. Vous trouverez un exemplaire de cette Licence sur */
-/* http://tigreraye.org/Petit-guide-du-traducteur.html#licence-art-libre */
-
-/* This work of art is free, you can redistribute it and/or */
-/* modify it according to terms of the Free Art license. You */
-/* will find a specimen of this license on the Copyleft */
-/* Attitude web site: http://artlibre.org as well as on other */
-/* sites. */
-/* Please note that the French version of this licence as shown */
-/* on http://tigreraye.org/Petit-guide-du-traducteur.html#licence-art-libre */
-/* is only official licence of this document. The English */
-/* is only provided to help you understand this licence. */
-
-/* La dernire version de cette feuille de style est toujours */
-/* disponible sur: http://tigreraye.org/style.css */
-/* Elle est galement disponible sur: */
-/* http://www.traduc.org/docs/HOWTO/lecture/style.css */
-
-/* The latest version of this stylesheet is available from: */
-/* http://tigreraye.org/style.css */
-/* It is also available on: */
-/* http://www.traduc.org/docs/HOWTO/lecture/style.css */
-
-/* N'hsitez pas envoyer vos commentaires et corrections */
-/* Jean-Philippe Gurard <jean-philippe.guerard@tigreraye.org> */
-
-/* Please send feedback and bug reports to */
-/* Jean-Philippe Gurard <jean-philippe.guerard@tigreraye.org> */
-
-/* $Id: style.css,v 1.14 2004/09/10 20:12:09 fevrier Exp fevrier $ */
-
-/* Prsentation gnrale du document */
-/* Overall document presentation */
-
-body {
- /*
- font-family: Apolline, "URW Palladio L", Garamond, jGaramond,
- "Bitstream Cyberbit", "Palatino Linotype", serif;
- */
- margin: 7%;
- background-color: white;
-}
-
-/* Taille du texte */
-/* Text size */
-
-* { font-size: 100%; }
-
-/* Gestion des textes mis en relief imbriqus */
-/* Embedded emphasis */
-
-em { font-style: italic; }
-em em { font-style: normal; }
-em em em { font-style: italic; }
-
-/* Titres */
-/* Titles */
-
-h1 { font-size: 200%; font-weight: 900; }
-h2 { font-size: 160%; font-weight: 900; }
-h3 { font-size: 130%; font-weight: bold; }
-h4 { font-size: 115%; font-weight: bold; }
-h5 { font-size: 108%; font-weight: bold; }
-h6 { font-weight: bold; }
-
-/* Nom de famille en petites majuscules (uniquement en franais) */
-/* Last names in small caps (for French only) */
-
-*[class~="surname"]:lang(fr) { font-variant: small-caps; }
-
-/* Blocs de citation */
-/* Quotation blocs */
-
-div[class~="blockquote"] {
- border: solid 2px #AAA;
- padding: 5px;
- margin: 5px;
-}
-
-div[class~="blockquote"] > table {
- border: none;
-}
-
-/* Blocs litraux: fond gris clair */
-/* Literal blocs: light gray background */
-
-*[class~="literallayout"] {
- background: #f0f0f0;
- padding: 5px;
- margin: 5px;
-}
-
-/* Programmes et captures texte: fond bleu clair */
-/* Listing and text screen snapshots: light blue background */
-
-*[class~="programlisting"], *[class~="screen"] {
- background: #f0f0ff;
- padding: 5px;
- margin: 5px;
-}
-
-/* Les textes remplacer sont surligns en vert ple */
-/* Replaceable text in highlighted in pale green */
-
-*[class~="replaceable"] {
- background-color: #98fb98;
- font-style: normal; }
-
-/* Tables: fonds gris clair & bords simples */
-/* Tables: light gray background and solid borders */
-
-*[class~="table"] *[class~="title"] { width:100%; border: 0px; }
-
-table {
- border: 1px solid #aaa;
- border-collapse: collapse;
- padding: 2px;
- margin: 5px;
-}
-
-/* Listes simples en style table */
-/* Simples lists in table presentation */
-
-table[class~="simplelist"] {
- background-color: #F0F0F0;
- margin: 5px;
- border: solid 1px #AAA;
-}
-
-table[class~="simplelist"] td {
- border: solid 1px #AAA;
-}
-
-/* Les tables */
-/* Tables */
-
-*[class~="table"] table {
- background-color: #F0F0F0;
- border: solid 1px #AAA;
-}
-*[class~="informaltable"] table { background-color: #F0F0F0; }
-
-th,td {
- vertical-align: baseline;
- text-align: left;
- padding: 0.1em 0.3em;
- empty-cells: show;
-}
-
-/* Alignement des colonnes */
-/* Colunms alignment */
-
-td[align=center] , th[align=center] { text-align: center; }
-td[align=right] , th[align=right] { text-align: right; }
-td[align=left] , th[align=left] { text-align: left; }
-td[align=justify] , th[align=justify] { text-align: justify; }
-
-/* Pas de marge autour des images */
-/* No inside margins for images */
-
-img { border: 0; }
-
-/* Les liens ne sont pas souligns */
-/* No underlines for links */
-
-:link , :visited , :active { text-decoration: none; }
-
-/* Prudence: cadre jaune et fond jaune clair */
-/* Caution: yellow border and light yellow background */
-
-*[class~="caution"] {
- border: solid 2px yellow;
- background-color: #ffffe0;
- padding: 1em 6px 1em ;
- margin: 5px;
-}
-
-*[class~="caution"] th {
- vertical-align: middle
-}
-
-*[class~="caution"] table {
- background-color: #ffffe0;
- border: none;
-}
-
-/* Note importante: cadre jaune et fond jaune clair */
-/* Important: yellow border and light yellow background */
-
-*[class~="important"] {
- border: solid 2px yellow;
- background-color: #ffffe0;
- padding: 1em 6px 1em;
- margin: 5px;
-}
-
-*[class~="important"] th {
- vertical-align: middle
-}
-
-*[class~="important"] table {
- background-color: #ffffe0;
- border: none;
-}
-
-/* Mise en vidence: texte lgrement plus grand */
-/* Highlights: slightly larger texts */
-
-*[class~="highlights"] {
- font-size: 110%;
-}
-
-/* Note: cadre bleu et fond bleu clair */
-/* Notes: blue border and light blue background */
-
-*[class~="note"] {
- border: solid 2px #7099C5;
- background-color: #f0f0ff;
- padding: 1em 6px 1em ;
- margin: 5px;
-}
-
-*[class~="note"] th {
- vertical-align: middle
-}
-
-*[class~="note"] table {
- background-color: #f0f0ff;
- border: none;
-}
-
-/* Astuce: cadre vert et fond vert clair */
-/* Tip: green border and light green background */
-
-*[class~="tip"] {
- border: solid 2px #00ff00;
- background-color: #f0ffff;
- padding: 1em 6px 1em ;
- margin: 5px;
-}
-
-*[class~="tip"] th {
- vertical-align: middle;
-}
-
-*[class~="tip"] table {
- background-color: #f0ffff;
- border: none;
-}
-
-/* Avertissement: cadre rouge et fond rouge clair */
-/* Warning: red border and light red background */
-
-*[class~="warning"] {
- border: solid 2px #ff0000;
- background-color: #fff0f0;
- padding: 1em 6px 1em ;
- margin: 5px;
-}
-
-*[class~="warning"] th {
- vertical-align: middle;
-}
-
-
-*[class~="warning"] table {
- background-color: #fff0f0;
- border: none;
-}
-
-/* Fin */
-/* The End */
-
diff --git a/doc/poky.ent b/doc/poky.ent
deleted file mode 100644
index 85d9c83bf..000000000
--- a/doc/poky.ent
+++ /dev/null
@@ -1,51 +0,0 @@
-<!ENTITY DISTRO "1.4">
-<!ENTITY DISTRO_NAME "tbd">
-<!ENTITY YOCTO_DOC_VERSION "1.4">
-<!ENTITY POKYVERSION "8.0">
-<!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2013">
-<!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
-<!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
-<!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
-<!ENTITY YOCTO_BUGZILLA_URL "http://bugzilla.yoctoproject.org">
-<!ENTITY YOCTO_WIKI_URL "https://wiki.yoctoproject.org">
-<!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
-<!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
-<!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
-<!ENTITY OE_HOME_URL "http://www.openembedded.org">
-<!ENTITY OE_LISTS_URL "http://lists.linuxtogo.org/cgi-bin/mailman">
-<!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
-<!ENTITY OH_HOME_URL "http://o-hand.com">
-<!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/">
-<!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs">
-<!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/">
-<!ENTITY YOCTO_AB_PORT_URL "&YOCTO_AB_URL;:8010">
-<!ENTITY YOCTO_AB_NIGHTLY_URL "&YOCTO_AB_URL;/nightly/">
-<!ENTITY YOCTO_POKY_URL "&YOCTO_DL_URL;/releases/poky/">
-<!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;">
-<!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/">
-<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt_installer">
-<!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2">
-<!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines">
-<!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu">
-<!ENTITY YOCTO_PYTHON-i686_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2">
-<!ENTITY YOCTO_PYTHON-x86_64_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2">
-<!ENTITY YOCTO_DOCS_QS_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/yocto-project-qs/yocto-project-qs.html">
-<!ENTITY YOCTO_DOCS_ADT_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/adt-manual/adt-manual.html">
-<!ENTITY YOCTO_DOCS_REF_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/ref-manual/ref-manual.html">
-<!ENTITY YOCTO_DOCS_BSP_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bsp-guide/bsp-guide.html">
-<!ENTITY YOCTO_DOCS_DEV_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/dev-manual/dev-manual.html">
-<!ENTITY YOCTO_DOCS_KERNEL_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-manual/kernel-manual.html">
-<!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;">
-<!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
-<!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
-<!ENTITY OE_INIT_FILE "oe-init-build-env">
-<!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo \
- build-essential chrpath">
-<!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
- diffutils diffstat git cpp gcc gcc-c++ eglibc-devel texinfo chrpath \
- ccache">
-<!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
- diffstat texinfo python-curses">
-<!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
- diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath">
diff --git a/doc/template/Vera.xml b/doc/template/Vera.xml
deleted file mode 100644
index 3c82043e3..000000000
--- a/doc/template/Vera.xml
+++ /dev/null
@@ -1 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?><font-metrics type="TYPE0"><font-name>BitstreamVeraSans</font-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>928</ascender><descender>-235</descender><bbox><left>-183</left><bottom>-235</bottom><right>1287</right><top>928</top></bbox><flags>32</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="600"/><wx w="0"/><wx w="317"/><wx w="317"/><wx w="400"/><wx w="459"/><wx w="837"/><wx w="636"/><wx w="950"/><wx w="779"/><wx w="274"/><wx w="390"/><wx w="390"/><wx w="500"/><wx w="837"/><wx w="317"/><wx w="360"/><wx w="317"/><wx w="336"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="336"/><wx w="336"/><wx w="837"/><wx w="837"/><wx w="837"/><wx w="530"/><wx w="1000"/><wx w="684"/><wx w="686"/><wx w="698"/><wx w="770"/><wx w="631"/><wx w="575"/><wx w="774"/><wx w="751"/><wx w="294"/><wx w="294"/><wx w="655"/><wx w="557"/><wx w="862"/><wx w="748"/><wx w="787"/><wx w="603"/><wx w="787"/><wx w="694"/><wx w="634"/><wx w="610"/><wx w="731"/><wx w="684"/><wx w="988"/><wx w="685"/><wx w="610"/><wx w="685"/><wx w="390"/><wx w="336"/><wx w="390"/><wx w="837"/><wx w="500"/><wx w="500"/><wx w="612"/><wx w="634"/><wx w="549"/><wx w="634"/><wx w="615"/><wx w="352"/><wx w="634"/><wx w="633"/><wx w="277"/><wx w="277"/><wx w="579"/><wx w="277"/><wx w="974"/><wx w="633"/><wx w="611"/><wx w="634"/><wx w="634"/><wx w="411"/><wx w="520"/><wx w="392"/><wx w="633"/><wx w="591"/><wx w="817"/><wx w="591"/><wx w="591"/><wx w="524"/><wx w="636"/><wx w="336"/><wx w="636"/><wx w="837"/><wx w="684"/><wx w="684"/><wx w="698"/><wx w="631"/><wx w="748"/><wx w="787"/><wx w="731"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="549"/><wx w="615"/><wx w="615"/><wx w="615"/><wx w="615"/><wx w="277"/><wx w="277"/><wx w="277"/><wx w="277"/><wx w="633"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="633"/><wx w="633"/><wx w="633"/><wx w="633"/><wx w="500"/><wx w="500"/><wx w="636"/><wx w="636"/><wx w="500"/><wx w="589"/><wx w="636"/><wx w="629"/><wx w="1000"/><wx w="1000"/><wx w="1000"/><wx w="500"/><wx w="500"/><wx w="837"/><wx w="974"/><wx w="787"/><wx w="833"/><wx w="837"/><wx w="837"/><wx w="837"/><wx w="636"/><wx w="636"/><wx w="517"/><wx w="673"/><wx w="756"/><wx w="588"/><wx w="520"/><wx w="471"/><wx w="471"/><wx w="764"/><wx w="981"/><wx w="611"/><wx w="530"/><wx w="400"/><wx w="837"/><wx w="637"/><wx w="636"/><wx w="837"/><wx w="668"/><wx w="611"/><wx w="611"/><wx w="1000"/><wx w="636"/><wx w="684"/><wx w="684"/><wx w="787"/><wx w="1069"/><wx w="1022"/><wx w="500"/><wx w="1000"/><wx w="518"/><wx w="518"/><wx w="317"/><wx w="317"/><wx w="837"/><wx w="494"/><wx w="591"/><wx w="610"/><wx w="166"/><wx w="636"/><wx w="399"/><wx w="399"/><wx w="629"/><wx w="629"/><wx w="500"/><wx w="317"/><wx w="317"/><wx w="518"/><wx w="1341"/><wx w="684"/><wx w="631"/><wx w="684"/><wx w="631"/><wx w="631"/><wx w="294"/><wx w="294"/><wx w="294"/><wx w="294"/><wx w="787"/><wx w="787"/><wx w="787"/><wx w="731"/><wx w="731"/><wx w="731"/><wx w="277"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="562"/><wx w="284"/><wx w="634"/><wx w="520"/><wx w="685"/><wx w="524"/><wx w="336"/><wx w="774"/><wx w="611"/><wx w="610"/><wx w="591"/><wx w="604"/><wx w="634"/><wx w="837"/><wx w="837"/><wx w="400"/><wx w="400"/><wx w="400"/><wx w="969"/><wx w="969"/><wx w="969"/><wx w="774"/><wx w="634"/><wx w="294"/><wx w="634"/><wx w="520"/><wx w="698"/><wx w="549"/><wx w="698"/><wx w="549"/><wx w="634"/><wx w="360"/><wx w="317"/><wx w="636"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="400"/><wx w="500"/><wx w="500"/></cid-widths></multibyte-extras><kerning kpx1="246"><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="169"/><pair kern="-26" kpx2="197"/><pair kern="-35" kpx2="55"/><pair kern="-49" kpx2="60"/><pair kern="-49" kpx2="187"/><pair kern="-21" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-49" kpx2="234"/></kerning><kerning kpx1="235"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="43"><pair kern="-35" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-35" kpx2="197"/><pair kern="-30" kpx2="181"/></kerning><kerning kpx1="16"><pair kern="36" kpx2="246"/><pair kern="-17" kpx2="235"/><pair kern="-21" kpx2="199"/><pair kern="18" kpx2="123"/><pair kern="27" kpx2="208"/><pair kern="-118" kpx2="187"/><pair kern="-49" kpx2="59"/><pair kern="18" kpx2="124"/><pair kern="-21" kpx2="201"/><pair kern="-118" kpx2="60"/><pair kern="36" kpx2="52"/><pair kern="18" kpx2="125"/><pair kern="36" kpx2="42"/><pair kern="-118" kpx2="234"/><pair kern="18" kpx2="122"/><pair kern="27" kpx2="210"/><pair kern="-21" kpx2="36"/><pair kern="18" kpx2="82"/><pair kern="-40" kpx2="58"/><pair kern="-91" kpx2="55"/><pair kern="-17" kpx2="186"/><pair kern="27" kpx2="175"/><pair kern="27" kpx2="50"/><pair kern="27" kpx2="209"/><pair kern="27" kpx2="103"/><pair kern="-21" kpx2="98"/><pair kern="55" kpx2="45"/><pair kern="-21" kpx2="173"/><pair kern="-17" kpx2="92"/><pair kern="-26" kpx2="89"/><pair kern="18" kpx2="121"/><pair kern="-58" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-21" kpx2="174"/></kerning><kerning kpx1="112"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="123"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="251"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="213"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="208"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="187"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="113"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="144"><pair kern="-40" kpx2="180"/><pair kern="-54" kpx2="197"/><pair kern="-44" kpx2="181"/></kerning><kerning kpx1="59"><pair kern="-72" kpx2="100"/><pair kern="-63" kpx2="210"/><pair kern="-17" kpx2="55"/><pair kern="-44" kpx2="114"/><pair kern="-44" kpx2="72"/><pair kern="-63" kpx2="175"/><pair kern="-49" kpx2="16"/><pair kern="-63" kpx2="50"/><pair kern="-63" kpx2="209"/><pair kern="-44" kpx2="112"/><pair kern="-72" kpx2="251"/><pair kern="-63" kpx2="103"/><pair kern="-63" kpx2="208"/><pair kern="-44" kpx2="113"/><pair kern="-40" kpx2="181"/><pair kern="-77" kpx2="180"/><pair kern="-54" kpx2="169"/><pair kern="-21" kpx2="197"/><pair kern="-72" kpx2="38"/><pair kern="-72" kpx2="253"/><pair kern="-44" kpx2="115"/></kerning><kerning kpx1="73"><pair kern="31" kpx2="180"/><pair kern="-17" kpx2="90"/><pair kern="-72" kpx2="17"/><pair kern="-17" kpx2="235"/><pair kern="-35" kpx2="169"/><pair kern="-114" kpx2="197"/><pair kern="-17" kpx2="186"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="87"/><pair kern="-54" kpx2="16"/><pair kern="-35" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="41"><pair kern="-17" kpx2="227"/><pair kern="-54" kpx2="126"/><pair kern="-91" kpx2="107"/><pair kern="-91" kpx2="235"/><pair kern="-54" kpx2="72"/><pair kern="-91" kpx2="199"/><pair kern="-35" kpx2="123"/><pair kern="-54" kpx2="112"/><pair kern="-54" kpx2="113"/><pair kern="-17" kpx2="54"/><pair kern="-21" kpx2="180"/><pair kern="-91" kpx2="105"/><pair kern="-54" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-91" kpx2="201"/><pair kern="-72" kpx2="85"/><pair kern="-91" kpx2="106"/><pair kern="-77" kpx2="29"/><pair kern="-35" kpx2="125"/><pair kern="-54" kpx2="115"/><pair kern="-54" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-91" kpx2="68"/><pair kern="-91" kpx2="36"/><pair kern="-35" kpx2="82"/><pair kern="-91" kpx2="186"/><pair kern="-17" kpx2="55"/><pair kern="-54" kpx2="114"/><pair kern="-54" kpx2="127"/><pair kern="-91" kpx2="108"/><pair kern="-91" kpx2="98"/><pair kern="-72" kpx2="76"/><pair kern="-160" kpx2="17"/><pair kern="-54" kpx2="128"/><pair kern="-91" kpx2="173"/><pair kern="-91" kpx2="109"/><pair kern="-183" kpx2="197"/><pair kern="-91" kpx2="92"/><pair kern="-35" kpx2="121"/><pair kern="-91" kpx2="110"/><pair kern="-91" kpx2="174"/><pair kern="-17" kpx2="249"/></kerning><kerning kpx1="124"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="169"><pair kern="-17" kpx2="90"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="246"/><pair kern="-17" kpx2="235"/><pair kern="-17" kpx2="58"/><pair kern="-17" kpx2="186"/><pair kern="-54" kpx2="55"/><pair kern="-17" kpx2="251"/><pair kern="-72" kpx2="187"/><pair kern="-17" kpx2="39"/><pair kern="73" kpx2="144"/><pair kern="-17" kpx2="45"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="38"/><pair kern="-72" kpx2="60"/><pair kern="-17" kpx2="89"/><pair kern="-17" kpx2="253"/><pair kern="-54" kpx2="57"/><pair kern="-17" kpx2="37"/><pair kern="-17" kpx2="42"/><pair kern="-72" kpx2="234"/></kerning><kerning kpx1="201"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="60"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="85"><pair kern="-21" kpx2="254"/><pair kern="-21" kpx2="72"/><pair kern="-63" kpx2="16"/><pair kern="-21" kpx2="112"/><pair kern="-21" kpx2="123"/><pair kern="-17" kpx2="80"/><pair kern="-21" kpx2="113"/><pair kern="-17" kpx2="71"/><pair kern="-21" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-21" kpx2="252"/><pair kern="-21" kpx2="70"/><pair kern="-17" kpx2="85"/><pair kern="-17" kpx2="29"/><pair kern="-21" kpx2="125"/><pair kern="-21" kpx2="115"/><pair kern="-21" kpx2="111"/><pair kern="-21" kpx2="122"/><pair kern="-21" kpx2="82"/><pair kern="-17" kpx2="75"/><pair kern="-21" kpx2="114"/><pair kern="-26" kpx2="91"/><pair kern="-17" kpx2="81"/><pair kern="41" kpx2="181"/><pair kern="-91" kpx2="17"/><pair kern="-151" kpx2="197"/><pair kern="-17" kpx2="74"/><pair kern="-17" kpx2="84"/><pair kern="-21" kpx2="121"/><pair kern="-17" kpx2="247"/><pair kern="-17" kpx2="120"/></kerning><kerning kpx1="61"><pair kern="-17" kpx2="180"/><pair kern="-17" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="234"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="100"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="122"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="47"><pair kern="-17" kpx2="126"/><pair kern="-91" kpx2="235"/><pair kern="-49" kpx2="104"/><pair kern="-17" kpx2="72"/><pair kern="22" kpx2="199"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-49" kpx2="213"/><pair kern="-35" kpx2="208"/><pair kern="-132" kpx2="187"/><pair kern="-17" kpx2="113"/><pair kern="-202" kpx2="180"/><pair kern="-17" kpx2="129"/><pair kern="-17" kpx2="124"/><pair kern="22" kpx2="201"/><pair kern="-132" kpx2="60"/><pair kern="-49" kpx2="211"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="115"/><pair kern="-132" kpx2="234"/><pair kern="-17" kpx2="88"/><pair kern="-17" kpx2="122"/><pair kern="-35" kpx2="210"/><pair kern="22" kpx2="36"/><pair kern="-17" kpx2="82"/><pair kern="-91" kpx2="58"/><pair kern="-91" kpx2="186"/><pair kern="-137" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-35" kpx2="175"/><pair kern="-17" kpx2="127"/><pair kern="-35" kpx2="50"/><pair kern="-35" kpx2="209"/><pair kern="-35" kpx2="103"/><pair kern="22" kpx2="98"/><pair kern="-262" kpx2="181"/><pair kern="-17" kpx2="128"/><pair kern="22" kpx2="173"/><pair kern="-49" kpx2="212"/><pair kern="-91" kpx2="92"/><pair kern="-17" kpx2="121"/><pair kern="-109" kpx2="57"/><pair kern="22" kpx2="174"/><pair kern="-49" kpx2="56"/></kerning><kerning kpx1="210"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="58"><pair kern="-35" kpx2="126"/><pair kern="-63" kpx2="107"/><pair kern="-17" kpx2="235"/><pair kern="-58" kpx2="72"/><pair kern="-54" kpx2="199"/><pair kern="-40" kpx2="16"/><pair kern="-58" kpx2="112"/><pair kern="-58" kpx2="123"/><pair kern="-58" kpx2="113"/><pair kern="-17" kpx2="180"/><pair kern="-63" kpx2="105"/><pair kern="-35" kpx2="129"/><pair kern="-58" kpx2="124"/><pair kern="-54" kpx2="169"/><pair kern="-54" kpx2="201"/><pair kern="-44" kpx2="85"/><pair kern="-63" kpx2="106"/><pair kern="-58" kpx2="29"/><pair kern="-58" kpx2="125"/><pair kern="-17" kpx2="170"/><pair kern="-58" kpx2="115"/><pair kern="-35" kpx2="88"/><pair kern="-58" kpx2="122"/><pair kern="-63" kpx2="68"/><pair kern="-54" kpx2="36"/><pair kern="-58" kpx2="82"/><pair kern="-17" kpx2="186"/><pair kern="-58" kpx2="114"/><pair kern="-35" kpx2="127"/><pair kern="-63" kpx2="108"/><pair kern="-54" kpx2="98"/><pair kern="-21" kpx2="76"/><pair kern="-114" kpx2="17"/><pair kern="-35" kpx2="128"/><pair kern="-54" kpx2="173"/><pair kern="-63" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-17" kpx2="92"/><pair kern="-58" kpx2="121"/><pair kern="-63" kpx2="110"/><pair kern="-54" kpx2="174"/></kerning><kerning kpx1="82"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="186"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="175"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="209"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="103"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="81"><pair kern="-72" kpx2="180"/><pair kern="-44" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="98"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="212"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="229"><pair kern="-17" kpx2="180"/><pair kern="-17" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="38"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="121"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="57"><pair kern="-67" kpx2="126"/><pair kern="-77" kpx2="107"/><pair kern="-26" kpx2="235"/><pair kern="-77" kpx2="72"/><pair kern="-63" kpx2="199"/><pair kern="-58" kpx2="16"/><pair kern="-77" kpx2="123"/><pair kern="-77" kpx2="112"/><pair kern="-17" kpx2="208"/><pair kern="-77" kpx2="113"/><pair kern="-77" kpx2="105"/><pair kern="-67" kpx2="129"/><pair kern="-77" kpx2="124"/><pair kern="-86" kpx2="169"/><pair kern="-63" kpx2="201"/><pair kern="-77" kpx2="106"/><pair kern="-81" kpx2="29"/><pair kern="-77" kpx2="125"/><pair kern="-54" kpx2="170"/><pair kern="-77" kpx2="115"/><pair kern="-67" kpx2="88"/><pair kern="-77" kpx2="122"/><pair kern="-77" kpx2="68"/><pair kern="-17" kpx2="210"/><pair kern="-63" kpx2="36"/><pair kern="-77" kpx2="82"/><pair kern="-26" kpx2="186"/><pair kern="-77" kpx2="114"/><pair kern="-17" kpx2="175"/><pair kern="-67" kpx2="127"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-77" kpx2="108"/><pair kern="-63" kpx2="98"/><pair kern="-21" kpx2="76"/><pair kern="-128" kpx2="17"/><pair kern="-67" kpx2="128"/><pair kern="-63" kpx2="173"/><pair kern="-77" kpx2="109"/><pair kern="-137" kpx2="197"/><pair kern="-26" kpx2="92"/><pair kern="-77" kpx2="121"/><pair kern="-77" kpx2="110"/><pair kern="-63" kpx2="174"/></kerning><kerning kpx1="37"><pair kern="-17" kpx2="227"/><pair kern="-17" kpx2="246"/><pair kern="-17" kpx2="251"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-17" kpx2="54"/><pair kern="-54" kpx2="180"/><pair kern="-30" kpx2="169"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="170"/><pair kern="-54" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="210"/><pair kern="-35" kpx2="58"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-54" kpx2="181"/><pair kern="-40" kpx2="197"/><pair kern="-17" kpx2="38"/><pair kern="-30" kpx2="57"/><pair kern="-17" kpx2="249"/></kerning><kerning kpx1="120"><pair kern="-72" kpx2="180"/><pair kern="-44" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="249"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="227"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="51"><pair kern="-17" kpx2="126"/><pair kern="-44" kpx2="107"/><pair kern="-35" kpx2="72"/><pair kern="-63" kpx2="199"/><pair kern="-21" kpx2="16"/><pair kern="-35" kpx2="123"/><pair kern="-35" kpx2="112"/><pair kern="-21" kpx2="187"/><pair kern="-35" kpx2="113"/><pair kern="-17" kpx2="86"/><pair kern="18" kpx2="180"/><pair kern="-44" kpx2="105"/><pair kern="-17" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-17" kpx2="169"/><pair kern="-63" kpx2="201"/><pair kern="-17" kpx2="85"/><pair kern="-21" kpx2="60"/><pair kern="-44" kpx2="106"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="115"/><pair kern="-21" kpx2="234"/><pair kern="-17" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-44" kpx2="68"/><pair kern="-63" kpx2="36"/><pair kern="-35" kpx2="82"/><pair kern="-35" kpx2="114"/><pair kern="-17" kpx2="250"/><pair kern="-17" kpx2="127"/><pair kern="-44" kpx2="108"/><pair kern="-63" kpx2="98"/><pair kern="-17" kpx2="81"/><pair kern="-21" kpx2="76"/><pair kern="18" kpx2="181"/><pair kern="-155" kpx2="17"/><pair kern="-17" kpx2="128"/><pair kern="-63" kpx2="173"/><pair kern="-44" kpx2="109"/><pair kern="-160" kpx2="197"/><pair kern="-35" kpx2="121"/><pair kern="-17" kpx2="228"/><pair kern="-44" kpx2="110"/><pair kern="-63" kpx2="174"/><pair kern="-17" kpx2="120"/></kerning><kerning kpx1="104"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="72"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="199"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="54"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="180"><pair kern="-35" kpx2="235"/><pair kern="-35" kpx2="246"/><pair kern="-30" kpx2="43"/><pair kern="-72" kpx2="123"/><pair kern="-35" kpx2="251"/><pair kern="-35" kpx2="208"/><pair kern="-188" kpx2="144"/><pair kern="-58" kpx2="59"/><pair kern="-35" kpx2="73"/><pair kern="-30" kpx2="41"/><pair kern="-72" kpx2="124"/><pair kern="-54" kpx2="85"/><pair kern="-128" kpx2="201"/><pair kern="-17" kpx2="61"/><pair kern="-35" kpx2="100"/><pair kern="-72" kpx2="122"/><pair kern="-30" kpx2="47"/><pair kern="-35" kpx2="210"/><pair kern="-72" kpx2="82"/><pair kern="-35" kpx2="186"/><pair kern="-35" kpx2="175"/><pair kern="-35" kpx2="209"/><pair kern="-35" kpx2="103"/><pair kern="-128" kpx2="98"/><pair kern="-54" kpx2="81"/><pair kern="-17" kpx2="229"/><pair kern="-35" kpx2="38"/><pair kern="-72" kpx2="121"/><pair kern="-30" kpx2="37"/><pair kern="-54" kpx2="120"/><pair kern="-30" kpx2="51"/><pair kern="-128" kpx2="199"/><pair kern="-30" kpx2="53"/><pair kern="-30" kpx2="137"/><pair kern="-35" kpx2="233"/><pair kern="-35" kpx2="253"/><pair kern="-35" kpx2="52"/><pair kern="-72" kpx2="125"/><pair kern="-35" kpx2="42"/><pair kern="-35" kpx2="90"/><pair kern="-128" kpx2="36"/><pair kern="-35" kpx2="50"/><pair kern="-30" kpx2="39"/><pair kern="-30" kpx2="236"/><pair kern="-30" kpx2="45"/><pair kern="-128" kpx2="173"/><pair kern="-35" kpx2="92"/><pair kern="-35" kpx2="89"/><pair kern="-30" kpx2="46"/><pair kern="-128" kpx2="174"/></kerning><kerning kpx1="53"><pair kern="-21" kpx2="107"/><pair kern="-54" kpx2="235"/><pair kern="-40" kpx2="16"/><pair kern="-44" kpx2="112"/><pair kern="-44" kpx2="123"/><pair kern="-49" kpx2="251"/><pair kern="-44" kpx2="113"/><pair kern="-63" kpx2="187"/><pair kern="-44" kpx2="129"/><pair kern="-44" kpx2="124"/><pair kern="-54" kpx2="169"/><pair kern="-63" kpx2="60"/><pair kern="-40" kpx2="201"/><pair kern="-21" kpx2="106"/><pair kern="-30" kpx2="29"/><pair kern="-63" kpx2="234"/><pair kern="-49" kpx2="100"/><pair kern="-44" kpx2="122"/><pair kern="-21" kpx2="68"/><pair kern="-40" kpx2="58"/><pair kern="-44" kpx2="82"/><pair kern="-54" kpx2="186"/><pair kern="-40" kpx2="98"/><pair kern="-63" kpx2="181"/><pair kern="-35" kpx2="17"/><pair kern="-49" kpx2="38"/><pair kern="-44" kpx2="121"/><pair kern="-54" kpx2="57"/><pair kern="-44" kpx2="126"/><pair kern="-44" kpx2="72"/><pair kern="-40" kpx2="199"/><pair kern="-72" kpx2="180"/><pair kern="-21" kpx2="105"/><pair kern="-49" kpx2="253"/><pair kern="-44" kpx2="125"/><pair kern="-44" kpx2="115"/><pair kern="-17" kpx2="170"/><pair kern="-44" kpx2="88"/><pair kern="-40" kpx2="36"/><pair kern="-44" kpx2="114"/><pair kern="-72" kpx2="55"/><pair kern="-44" kpx2="127"/><pair kern="-21" kpx2="108"/><pair kern="-44" kpx2="128"/><pair kern="-40" kpx2="173"/><pair kern="-21" kpx2="109"/><pair kern="-54" kpx2="92"/><pair kern="-17" kpx2="197"/><pair kern="-21" kpx2="110"/><pair kern="-40" kpx2="174"/></kerning><kerning kpx1="137"><pair kern="-54" kpx2="180"/><pair kern="-40" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="233"><pair kern="-44" kpx2="180"/><pair kern="-35" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="253"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="211"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="78"><pair kern="-17" kpx2="107"/><pair kern="-30" kpx2="126"/><pair kern="-35" kpx2="235"/><pair kern="-35" kpx2="72"/><pair kern="-35" kpx2="112"/><pair kern="-35" kpx2="123"/><pair kern="-35" kpx2="113"/><pair kern="-17" kpx2="105"/><pair kern="-30" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-17" kpx2="106"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="115"/><pair kern="-30" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-17" kpx2="68"/><pair kern="-35" kpx2="82"/><pair kern="-35" kpx2="114"/><pair kern="-35" kpx2="186"/><pair kern="-30" kpx2="127"/><pair kern="-17" kpx2="108"/><pair kern="-30" kpx2="128"/><pair kern="-17" kpx2="109"/><pair kern="-35" kpx2="92"/><pair kern="-35" kpx2="121"/><pair kern="-17" kpx2="110"/></kerning><kerning kpx1="52"><pair kern="-21" kpx2="180"/><pair kern="-63" kpx2="197"/><pair kern="27" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="125"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="42"><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="169"/><pair kern="-26" kpx2="197"/><pair kern="-35" kpx2="55"/><pair kern="-49" kpx2="60"/><pair kern="-49" kpx2="187"/><pair kern="-21" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-49" kpx2="234"/></kerning><kerning kpx1="170"><pair kern="-17" kpx2="235"/><pair kern="-35" kpx2="199"/><pair kern="-17" kpx2="251"/><pair kern="-109" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-54" kpx2="59"/><pair kern="-109" kpx2="60"/><pair kern="-35" kpx2="201"/><pair kern="-17" kpx2="253"/><pair kern="-109" kpx2="234"/><pair kern="-17" kpx2="90"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="210"/><pair kern="-35" kpx2="36"/><pair kern="-54" kpx2="58"/><pair kern="-91" kpx2="55"/><pair kern="-17" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-17" kpx2="39"/><pair kern="-35" kpx2="98"/><pair kern="-17" kpx2="45"/><pair kern="-35" kpx2="173"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="89"/><pair kern="-86" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-35" kpx2="174"/></kerning><kerning kpx1="115"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="90"><pair kern="-91" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-104" kpx2="197"/><pair kern="-54" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="36"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="55"><pair kern="-165" kpx2="107"/><pair kern="-155" kpx2="235"/><pair kern="-91" kpx2="16"/><pair kern="-169" kpx2="112"/><pair kern="-169" kpx2="123"/><pair kern="-58" kpx2="251"/><pair kern="-169" kpx2="113"/><pair kern="-165" kpx2="86"/><pair kern="-151" kpx2="129"/><pair kern="-169" kpx2="124"/><pair kern="-91" kpx2="169"/><pair kern="-169" kpx2="252"/><pair kern="-169" kpx2="70"/><pair kern="-146" kpx2="85"/><pair kern="-77" kpx2="201"/><pair kern="-165" kpx2="106"/><pair kern="-109" kpx2="29"/><pair kern="-58" kpx2="100"/><pair kern="-169" kpx2="122"/><pair kern="-165" kpx2="68"/><pair kern="-169" kpx2="82"/><pair kern="-155" kpx2="186"/><pair kern="-165" kpx2="250"/><pair kern="-77" kpx2="98"/><pair kern="-21" kpx2="181"/><pair kern="-118" kpx2="17"/><pair kern="-58" kpx2="38"/><pair kern="-169" kpx2="121"/><pair kern="-165" kpx2="228"/><pair kern="-169" kpx2="254"/><pair kern="-151" kpx2="126"/><pair kern="-169" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-165" kpx2="105"/><pair kern="-58" kpx2="253"/><pair kern="-169" kpx2="125"/><pair kern="-169" kpx2="115"/><pair kern="-54" kpx2="170"/><pair kern="-151" kpx2="88"/><pair kern="-169" kpx2="111"/><pair kern="-165" kpx2="90"/><pair kern="-77" kpx2="36"/><pair kern="-17" kpx2="55"/><pair kern="-169" kpx2="114"/><pair kern="-151" kpx2="127"/><pair kern="-165" kpx2="108"/><pair kern="-30" kpx2="76"/><pair kern="-151" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-165" kpx2="109"/><pair kern="-155" kpx2="92"/><pair kern="-128" kpx2="197"/><pair kern="-165" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="114"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="50"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="91"><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="111"/><pair kern="-30" kpx2="122"/><pair kern="-30" kpx2="82"/><pair kern="-30" kpx2="114"/><pair kern="-30" kpx2="72"/><pair kern="-30" kpx2="112"/><pair kern="-30" kpx2="123"/><pair kern="-30" kpx2="113"/><pair kern="-30" kpx2="124"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-30" kpx2="121"/><pair kern="-30" kpx2="125"/><pair kern="-30" kpx2="115"/></kerning><kerning kpx1="39"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="-17" kpx2="98"/><pair kern="-54" kpx2="187"/><pair kern="-26" kpx2="181"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-17" kpx2="170"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="236"><pair kern="-17" kpx2="180"/><pair kern="-72" kpx2="17"/><pair kern="-91" kpx2="197"/><pair kern="-35" kpx2="29"/></kerning><kerning kpx1="45"><pair kern="-35" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="169"/><pair kern="-54" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-17" kpx2="199"/><pair kern="-35" kpx2="16"/><pair kern="-17" kpx2="174"/><pair kern="-17" kpx2="98"/><pair kern="-30" kpx2="181"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="173"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="197"><pair kern="-35" kpx2="246"/><pair kern="-54" kpx2="235"/><pair kern="-35" kpx2="43"/><pair kern="-35" kpx2="123"/><pair kern="-54" kpx2="251"/><pair kern="-183" kpx2="187"/><pair kern="-54" kpx2="208"/><pair kern="18" kpx2="144"/><pair kern="-35" kpx2="59"/><pair kern="-17" kpx2="73"/><pair kern="-35" kpx2="41"/><pair kern="-35" kpx2="124"/><pair kern="-35" kpx2="85"/><pair kern="-183" kpx2="60"/><pair kern="18" kpx2="201"/><pair kern="-183" kpx2="234"/><pair kern="-54" kpx2="100"/><pair kern="-35" kpx2="122"/><pair kern="-35" kpx2="47"/><pair kern="-54" kpx2="210"/><pair kern="-35" kpx2="82"/><pair kern="-123" kpx2="58"/><pair kern="-54" kpx2="186"/><pair kern="-54" kpx2="175"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-35" kpx2="81"/><pair kern="18" kpx2="98"/><pair kern="-54" kpx2="38"/><pair kern="-35" kpx2="121"/><pair kern="-183" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-35" kpx2="120"/><pair kern="-35" kpx2="51"/><pair kern="18" kpx2="199"/><pair kern="-35" kpx2="53"/><pair kern="-35" kpx2="137"/><pair kern="-35" kpx2="233"/><pair kern="-54" kpx2="253"/><pair kern="-54" kpx2="52"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="42"/><pair kern="-95" kpx2="90"/><pair kern="18" kpx2="36"/><pair kern="-137" kpx2="55"/><pair kern="-54" kpx2="50"/><pair kern="-35" kpx2="39"/><pair kern="-35" kpx2="236"/><pair kern="22" kpx2="45"/><pair kern="18" kpx2="173"/><pair kern="-54" kpx2="92"/><pair kern="-114" kpx2="89"/><pair kern="-35" kpx2="46"/><pair kern="18" kpx2="174"/></kerning><kerning kpx1="92"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="89"><pair kern="-77" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-132" kpx2="197"/><pair kern="-26" kpx2="16"/><pair kern="-54" kpx2="29"/><pair kern="-17" kpx2="181"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="46"><pair kern="-17" kpx2="107"/><pair kern="-72" kpx2="235"/><pair kern="-104" kpx2="16"/><pair kern="-49" kpx2="112"/><pair kern="-49" kpx2="123"/><pair kern="-54" kpx2="251"/><pair kern="-26" kpx2="213"/><pair kern="-49" kpx2="113"/><pair kern="-35" kpx2="187"/><pair kern="-54" kpx2="208"/><pair kern="-49" kpx2="129"/><pair kern="-49" kpx2="124"/><pair kern="-63" kpx2="169"/><pair kern="-35" kpx2="60"/><pair kern="-17" kpx2="201"/><pair kern="-17" kpx2="106"/><pair kern="-35" kpx2="234"/><pair kern="-54" kpx2="100"/><pair kern="-49" kpx2="122"/><pair kern="-17" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-35" kpx2="58"/><pair kern="-49" kpx2="82"/><pair kern="-72" kpx2="186"/><pair kern="-54" kpx2="175"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-17" kpx2="98"/><pair kern="-30" kpx2="181"/><pair kern="-26" kpx2="212"/><pair kern="-54" kpx2="38"/><pair kern="-49" kpx2="121"/><pair kern="-49" kpx2="126"/><pair kern="-26" kpx2="104"/><pair kern="-49" kpx2="72"/><pair kern="-17" kpx2="199"/><pair kern="-30" kpx2="180"/><pair kern="-17" kpx2="105"/><pair kern="-54" kpx2="253"/><pair kern="-26" kpx2="211"/><pair kern="-49" kpx2="125"/><pair kern="-49" kpx2="115"/><pair kern="-49" kpx2="88"/><pair kern="-17" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-49" kpx2="114"/><pair kern="-54" kpx2="50"/><pair kern="-49" kpx2="127"/><pair kern="-17" kpx2="108"/><pair kern="-49" kpx2="128"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="109"/><pair kern="-72" kpx2="92"/><pair kern="-17" kpx2="110"/><pair kern="-17" kpx2="174"/><pair kern="-26" kpx2="56"/></kerning><kerning kpx1="174"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="56"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning></font-metrics> \ No newline at end of file
diff --git a/doc/template/VeraMoBd.xml b/doc/template/VeraMoBd.xml
deleted file mode 100644
index 9b33107a4..000000000
--- a/doc/template/VeraMoBd.xml
+++ /dev/null
@@ -1 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?><font-metrics metrics-version="2" type="TYPE0"><font-name>BitstreamVeraSansMono-Bold</font-name><full-name>Bitstream Vera Sans Mono Bold</full-name><family-name>Bitstream Vera Sans Mono</family-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>759</ascender><descender>-240</descender><bbox><left>-19</left><bottom>-235</bottom><right>605</right><top>928</top></bbox><flags>34</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="602"/><wx w="0"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/></cid-widths></multibyte-extras></font-metrics> \ No newline at end of file
diff --git a/doc/template/VeraMono.xml b/doc/template/VeraMono.xml
deleted file mode 100644
index 3a0a86659..000000000
--- a/doc/template/VeraMono.xml
+++ /dev/null
@@ -1 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?><font-metrics metrics-version="2" type="TYPE0"><font-name>BitstreamVeraSansMono-Roman</font-name><full-name>Bitstream Vera Sans Mono</full-name><family-name>Bitstream Vera Sans Mono</family-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>759</ascender><descender>-240</descender><bbox><left>-4</left><bottom>-235</bottom><right>605</right><top>928</top></bbox><flags>34</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="602"/><wx w="0"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/></cid-widths></multibyte-extras></font-metrics> \ No newline at end of file
diff --git a/doc/template/component.title.xsl b/doc/template/component.title.xsl
deleted file mode 100644
index faef04326..000000000
--- a/doc/template/component.title.xsl
+++ /dev/null
@@ -1,39 +0,0 @@
-<xsl:stylesheet version="1.0"
- xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
- xmlns:d="http://docbook.org/ns/docbook"
- xmlns="http://www.w3.org/1999/xhtml"
- exclude-result-prefixes="d">
-
- <xsl:template name="component.title">
- <xsl:param name="node" select="."/>
-
- <xsl:variable name="level">
- <xsl:choose>
- <xsl:when test="ancestor::d:section">
- <xsl:value-of select="count(ancestor::d:section)+1"/>
- </xsl:when>
- <xsl:when test="ancestor::d:sect5">6</xsl:when>
- <xsl:when test="ancestor::d:sect4">5</xsl:when>
- <xsl:when test="ancestor::d:sect3">4</xsl:when>
- <xsl:when test="ancestor::d:sect2">3</xsl:when>
- <xsl:when test="ancestor::d:sect1">2</xsl:when>
- <xsl:otherwise>1</xsl:otherwise>
- </xsl:choose>
- </xsl:variable>
- <xsl:element name="h{$level+1}" namespace="http://www.w3.org/1999/xhtml">
- <xsl:attribute name="class">title</xsl:attribute>
- <xsl:if test="$generate.id.attributes = 0">
- <xsl:call-template name="anchor">
- <xsl:with-param name="node" select="$node"/>
- <xsl:with-param name="conditional" select="0"/>
- </xsl:call-template>
- </xsl:if>
- <xsl:apply-templates select="$node" mode="object.title.markup">
- <xsl:with-param name="allow-anchors" select="1"/>
- </xsl:apply-templates>
- <xsl:call-template name="permalink">
- <xsl:with-param name="node" select="$node"/>
- </xsl:call-template>
- </xsl:element>
- </xsl:template>
-</xsl:stylesheet>
diff --git a/doc/template/db-pdf.xsl b/doc/template/db-pdf.xsl
deleted file mode 100644
index 3dd065a57..000000000
--- a/doc/template/db-pdf.xsl
+++ /dev/null
@@ -1,64 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
-
- <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl" />
-
- <!-- check project-plan.sh for how this is generated, needed to tweak
- the cover page
- -->
- <xsl:include href="/tmp/titlepage.xsl"/>
-
- <!-- To force a page break in document, i.e per section add a
- <?hard-pagebreak?> tag.
- -->
- <xsl:template match="processing-instruction('hard-pagebreak')">
- <fo:block break-before='page' />
- </xsl:template>
-
- <!--Fix for defualt indent getting TOC all wierd..
- See http://sources.redhat.com/ml/docbook-apps/2005-q1/msg00455.html
- FIXME: must be a better fix
- -->
- <xsl:param name="body.start.indent" select="'0'"/>
- <!--<xsl:param name="title.margin.left" select="'0'"/>-->
-
- <!-- stop long-ish header titles getting wrapped -->
- <xsl:param name="header.column.widths">1 10 1</xsl:param>
-
- <!-- customise headers and footers a little -->
-
- <xsl:template name="head.sep.rule">
- <xsl:if test="$header.rule != 0">
- <xsl:attribute name="border-bottom-width">0.5pt</xsl:attribute>
- <xsl:attribute name="border-bottom-style">solid</xsl:attribute>
- <xsl:attribute name="border-bottom-color">#cccccc</xsl:attribute>
- </xsl:if>
- </xsl:template>
-
- <xsl:template name="foot.sep.rule">
- <xsl:if test="$footer.rule != 0">
- <xsl:attribute name="border-top-width">0.5pt</xsl:attribute>
- <xsl:attribute name="border-top-style">solid</xsl:attribute>
- <xsl:attribute name="border-top-color">#cccccc</xsl:attribute>
- </xsl:if>
- </xsl:template>
-
- <xsl:attribute-set name="header.content.properties">
- <xsl:attribute name="color">#cccccc</xsl:attribute>
- </xsl:attribute-set>
-
- <xsl:attribute-set name="footer.content.properties">
- <xsl:attribute name="color">#cccccc</xsl:attribute>
- </xsl:attribute-set>
-
-
- <!-- general settings -->
-
- <xsl:param name="fop1.extensions" select="1"></xsl:param>
- <xsl:param name="paper.type" select="'A4'"></xsl:param>
- <xsl:param name="section.autolabel" select="1"></xsl:param>
- <xsl:param name="body.font.family" select="'verasans'"></xsl:param>
- <xsl:param name="title.font.family" select="'verasans'"></xsl:param>
- <xsl:param name="monospace.font.family" select="'veramono'"></xsl:param>
-
-</xsl:stylesheet>
diff --git a/doc/template/division.title.xsl b/doc/template/division.title.xsl
deleted file mode 100644
index 9c843bc7c..000000000
--- a/doc/template/division.title.xsl
+++ /dev/null
@@ -1,25 +0,0 @@
-<xsl:stylesheet version="1.0"
- xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
- xmlns:d="http://docbook.org/ns/docbook"
- xmlns="http://www.w3.org/1999/xhtml"
- exclude-result-prefixes="d">
-
- <xsl:template name="division.title">
- <xsl:param name="node" select="."/>
-
- <h1>
- <xsl:attribute name="class">title</xsl:attribute>
- <xsl:call-template name="anchor">
- <xsl:with-param name="node" select="$node"/>
- <xsl:with-param name="conditional" select="0"/>
- </xsl:call-template>
- <xsl:apply-templates select="$node" mode="object.title.markup">
- <xsl:with-param name="allow-anchors" select="1"/>
- </xsl:apply-templates>
- <xsl:call-template name="permalink">
- <xsl:with-param name="node" select="$node"/>
- </xsl:call-template>
- </h1>
- </xsl:template>
-</xsl:stylesheet>
-
diff --git a/doc/template/fop-config.xml b/doc/template/fop-config.xml
deleted file mode 100644
index 09cc5ca0f..000000000
--- a/doc/template/fop-config.xml
+++ /dev/null
@@ -1,58 +0,0 @@
-<fop version="1.0">
-
- <!-- Strict user configuration -->
- <strict-configuration>true</strict-configuration>
-
- <!-- Strict FO validation -->
- <strict-validation>true</strict-validation>
-
- <!--
- Set the baseDir so common/openedhand.svg references in plans still
- work ok. Note, relative file references to current dir should still work.
- -->
- <base>../template</base>
- <font-base>../template</font-base>
-
- <!-- Source resolution in dpi (dots/pixels per inch) for determining the
- size of pixels in SVG and bitmap images, default: 72dpi -->
- <!-- <source-resolution>72</source-resolution> -->
- <!-- Target resolution in dpi (dots/pixels per inch) for specifying the
- target resolution for generated bitmaps, default: 72dpi -->
- <!-- <target-resolution>72</target-resolution> -->
-
- <!-- default page-height and page-width, in case
- value is specified as auto -->
- <default-page-settings height="11in" width="8.26in"/>
-
- <!-- <use-cache>false</use-cache> -->
-
- <renderers>
- <renderer mime="application/pdf">
- <fonts>
- <font metrics-file="VeraMono.xml"
- kerning="yes"
- embed-url="VeraMono.ttf">
- <font-triplet name="veramono" style="normal" weight="normal"/>
- </font>
-
- <font metrics-file="VeraMoBd.xml"
- kerning="yes"
- embed-url="VeraMoBd.ttf">
- <font-triplet name="veramono" style="normal" weight="bold"/>
- </font>
-
- <font metrics-file="Vera.xml"
- kerning="yes"
- embed-url="Vera.ttf">
- <font-triplet name="verasans" style="normal" weight="normal"/>
- <font-triplet name="verasans" style="normal" weight="bold"/>
- <font-triplet name="verasans" style="italic" weight="normal"/>
- <font-triplet name="verasans" style="italic" weight="bold"/>
- </font>
-
- <auto-detect/>
- </fonts>
- </renderer>
- </renderers>
-</fop>
-
diff --git a/doc/template/formal.object.heading.xsl b/doc/template/formal.object.heading.xsl
deleted file mode 100644
index 4f3900d16..000000000
--- a/doc/template/formal.object.heading.xsl
+++ /dev/null
@@ -1,21 +0,0 @@
-<xsl:stylesheet version="1.0"
- xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
- xmlns:d="http://docbook.org/ns/docbook"
- xmlns="http://www.w3.org/1999/xhtml"
- exclude-result-prefixes="d">
-
- <xsl:template name="formal.object.heading">
- <xsl:param name="object" select="."/>
- <xsl:param name="title">
- <xsl:apply-templates select="$object" mode="object.title.markup">
- <xsl:with-param name="allow-anchors" select="1"/>
- </xsl:apply-templates>
- </xsl:param>
- <p class="title">
- <b><xsl:copy-of select="$title"/></b>
- <xsl:call-template name="permalink">
- <xsl:with-param name="node" select="$object"/>
- </xsl:call-template>
- </p>
- </xsl:template>
-</xsl:stylesheet> \ No newline at end of file
diff --git a/doc/template/gloss-permalinks.xsl b/doc/template/gloss-permalinks.xsl
deleted file mode 100644
index 6bf58116f..000000000
--- a/doc/template/gloss-permalinks.xsl
+++ /dev/null
@@ -1,14 +0,0 @@
-<xsl:stylesheet version="1.0"
- xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
- xmlns:d="http://docbook.org/ns/docbook"
- xmlns="http://www.w3.org/1999/xhtml">
-
- <xsl:template match="glossentry/glossterm">
- <xsl:apply-imports/>
- <xsl:if test="$generate.permalink != 0">
- <xsl:call-template name="permalink">
- <xsl:with-param name="node" select=".."/>
- </xsl:call-template>
- </xsl:if>
- </xsl:template>
-</xsl:stylesheet>
diff --git a/doc/template/permalinks.xsl b/doc/template/permalinks.xsl
deleted file mode 100644
index d2a1c1452..000000000
--- a/doc/template/permalinks.xsl
+++ /dev/null
@@ -1,25 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<xsl:stylesheet version="1.0"
- xmlns="http://www.w3.org/1999/xhtml"
- xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
-
- <xsl:param name="generate.permalink" select="1"/>
- <xsl:param name="permalink.text">¶</xsl:param>
-
- <xsl:template name="permalink">
- <xsl:param name="node"/>
-
- <xsl:if test="$generate.permalink != '0'">
- <span class="permalink">
- <a alt="Permalink" title="Permalink">
- <xsl:attribute name="href">
- <xsl:call-template name="href.target">
- <xsl:with-param name="object" select="$node"/>
- </xsl:call-template>
- </xsl:attribute>
- <xsl:copy-of select="$permalink.text"/>
- </a>
- </span>
- </xsl:if>
- </xsl:template>
-</xsl:stylesheet>
diff --git a/doc/template/section.title.xsl b/doc/template/section.title.xsl
deleted file mode 100644
index 5c6ff9a96..000000000
--- a/doc/template/section.title.xsl
+++ /dev/null
@@ -1,55 +0,0 @@
-<xsl:stylesheet version="1.0"
- xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
- xmlns:d="http://docbook.org/ns/docbook"
- xmlns="http://www.w3.org/1999/xhtml" exclude-result-prefixes="d">
-
- <xsl:template name="section.title">
- <xsl:variable name="section"
- select="(ancestor::section |
- ancestor::simplesect|
- ancestor::sect1|
- ancestor::sect2|
- ancestor::sect3|
- ancestor::sect4|
- ancestor::sect5)[last()]"/>
-
- <xsl:variable name="renderas">
- <xsl:choose>
- <xsl:when test="$section/@renderas = 'sect1'">1</xsl:when>
- <xsl:when test="$section/@renderas = 'sect2'">2</xsl:when>
- <xsl:when test="$section/@renderas = 'sect3'">3</xsl:when>
- <xsl:when test="$section/@renderas = 'sect4'">4</xsl:when>
- <xsl:when test="$section/@renderas = 'sect5'">5</xsl:when>
- <xsl:otherwise><xsl:value-of select="''"/></xsl:otherwise>
- </xsl:choose>
- </xsl:variable>
-
- <xsl:variable name="level">
- <xsl:choose>
- <xsl:when test="$renderas != ''">
- <xsl:value-of select="$renderas"/>
- </xsl:when>
- <xsl:otherwise>
- <xsl:call-template name="section.level">
- <xsl:with-param name="node" select="$section"/>
- </xsl:call-template>
- </xsl:otherwise>
- </xsl:choose>
- </xsl:variable>
-
- <xsl:call-template name="section.heading">
- <xsl:with-param name="section" select="$section"/>
- <xsl:with-param name="level" select="$level"/>
- <xsl:with-param name="title">
- <xsl:apply-templates select="$section" mode="object.title.markup">
- <xsl:with-param name="allow-anchors" select="1"/>
- </xsl:apply-templates>
- <xsl:if test="$level &gt; 0">
- <xsl:call-template name="permalink">
- <xsl:with-param name="node" select="$section"/>
- </xsl:call-template>
- </xsl:if>
- </xsl:with-param>
- </xsl:call-template>
- </xsl:template>
-</xsl:stylesheet>
diff --git a/doc/template/titlepage.templates.xml b/doc/template/titlepage.templates.xml
deleted file mode 100644
index 38ec11a4c..000000000
--- a/doc/template/titlepage.templates.xml
+++ /dev/null
@@ -1,1259 +0,0 @@
-<!DOCTYPE t:templates [
-<!ENTITY hsize0 "10pt">
-<!ENTITY hsize1 "12pt">
-<!ENTITY hsize2 "14.4pt">
-<!ENTITY hsize3 "17.28pt">
-<!ENTITY hsize4 "20.736pt">
-<!ENTITY hsize5 "24.8832pt">
-<!ENTITY hsize0space "7.5pt"> <!-- 0.75 * hsize0 -->
-<!ENTITY hsize1space "9pt"> <!-- 0.75 * hsize1 -->
-<!ENTITY hsize2space "10.8pt"> <!-- 0.75 * hsize2 -->
-<!ENTITY hsize3space "12.96pt"> <!-- 0.75 * hsize3 -->
-<!ENTITY hsize4space "15.552pt"> <!-- 0.75 * hsize4 -->
-<!ENTITY hsize5space "18.6624pt"> <!-- 0.75 * hsize5 -->
-]>
-<t:templates xmlns:t="http://nwalsh.com/docbook/xsl/template/1.0"
- xmlns:param="http://nwalsh.com/docbook/xsl/template/1.0/param"
- xmlns:fo="http://www.w3.org/1999/XSL/Format"
- xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
-
-<!-- ********************************************************************
- $Id: titlepage.templates.xml,v 1.23 2003/12/16 00:30:49 bobstayton Exp $
- ********************************************************************
-
- This file is part of the DocBook XSL Stylesheet distribution.
- See ../README or http://docbook.sf.net/ for copyright
- and other information.
-
- ******************************************************************** -->
-
-<!-- ==================================================================== -->
-
-<t:titlepage t:element="article" t:wrapper="fo:block"
- font-family="{$title.fontset}">
-
- <t:titlepage-content t:side="recto"
- text-align="center">
-
- <mediaobject/>
-
- <title t:named-template="component.title"
- param:node="ancestor-or-self::article[1]"
- keep-with-next="always"
- font-size="&hsize5;"
- font-weight="bold"/>
-
- <subtitle param:node="ancestor-or-self::article[1]"
- keep-with-next="always"
- font-size="&hsize3;"
- font-weight="bold"
- space-after="0.8em"/>
-
- <corpauthor space-before="0.5em"
- font-size="&hsize3;"/>
- <authorgroup space-before="0.5em"
- font-size="&hsize2;"/>
- <author space-before="0.5em"
- font-size="&hsize2;"
- space-after="0.8em"/>
-
- <email font-size="&hsize2;"/>
-
- <othercredit space-before="0.5em"/>
- <releaseinfo space-before="0.5em"/>
- <copyright space-before="0.5em"/>
- <legalnotice text-align="start"
- margin-left="0.5in"
- margin-right="0.5in"
- font-family="{$body.fontset}"/>
- <pubdate space-before="0.5em"/>
- <para></para>
- <revision space-before="0.5em"/>
- <revhistory space-before="0.5em"/>
- <abstract space-before="0.5em"
- text-align="start"
- margin-left="0.5in"
- margin-right="0.5in"
- font-family="{$body.fontset}"/>
-
- <para></para>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
-<t:titlepage t:element="set" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:named-template="division.title"
- param:node="ancestor-or-self::set[1]"
- text-align="center"
- font-size="&hsize5;"
- space-before="&hsize5space;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- <subtitle
- font-family="{$title.fontset}"
- text-align="center"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="book" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
-
- <mediaobject/>
-
-<!--
-
-# If you leave this block of code in then the text title in the
-# <title>BitBake User Manual</title> statement of the
-# bitbake-user-manual.xml file is rendered on the title page below the
-# image. Commenting it out gets it out of there yet allows it
-# to be retained in the tab text for the HTML version of the
-# manual.
-
- <title
- t:named-template="division.title"
- param:node="ancestor-or-self::book[1]"
- text-align="center"
- font-size="&hsize5;"
- space-before="&hsize5space;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
--->
- <subtitle
- text-align="center"
- font-size="&hsize4;"
- space-before="&hsize4space;"
- font-family="{$title.fontset}"/>
- <corpauthor font-size="&hsize3;"
- keep-with-next="always"
- space-before="2in"/>
- <authorgroup space-before="2in"/>
- <author font-size="&hsize3;"
- space-before="&hsize2space;"
- keep-with-next="always"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
-<!--
-# If you leave this block of code in then the text title in the
-# <title>BitBake User Manual</title> statement of the
-# bitbake-user-manual.xml file is rendered on the title page below the
-# image. Commenting it out gets it out of there yet allows it
-# to be retained in the tab text for the HTML version of the
-# manual.
-
- <title
- t:named-template="book.verso.title"
- font-size="&hsize2;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
--->
- <corpauthor/>
- <authorgroup t:named-template="verso.authorgroup"/>
- <author/>
- <othercredit/>
- <pubdate space-before="1em"/>
- <copyright/>
- <abstract/>
- <legalnotice font-size="8pt"/>
- </t:titlepage-content>
-
- <t:titlepage-separator>
- <fo:block break-after="page"/>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- <fo:block break-after="page"/>
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
-<t:titlepage t:element="part" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:named-template="division.title"
- param:node="ancestor-or-self::part[1]"
- text-align="center"
- font-size="&hsize5;"
- space-before="&hsize5space;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- <subtitle
- text-align="center"
- font-size="&hsize4;"
- space-before="&hsize4space;"
- font-weight='bold'
- font-style='italic'
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<t:titlepage t:element="partintro" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- text-align="center"
- font-size="&hsize5;"
- font-weight="bold"
- space-before="1em"
- font-family="{$title.fontset}"/>
- <subtitle
- text-align="center"
- font-size="&hsize2;"
- font-weight="bold"
- font-style="italic"
- font-family="{$title.fontset}"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
-<t:titlepage t:element="reference" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:named-template="division.title"
- param:node="ancestor-or-self::reference[1]"
- text-align="center"
- font-size="&hsize5;"
- space-before="&hsize5space;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- <subtitle
- font-family="{$title.fontset}"
- text-align="center"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
-<t:titlepage t:element="refsynopsisdiv" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
-<t:titlepage t:element="refsection" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
-<t:titlepage t:element="refsect1" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
-<t:titlepage t:element="refsect2" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
-<t:titlepage t:element="refsect3" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="dedication" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="component.title"
- param:node="ancestor-or-self::dedication[1]"
- margin-left="{$title.margin.left}"
- font-size="&hsize5;"
- font-family="{$title.fontset}"
- font-weight="bold"/>
- <subtitle
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="preface" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="component.title"
- param:node="ancestor-or-self::preface[1]"
- margin-left="{$title.margin.left}"
- font-size="&hsize5;"
- font-family="{$title.fontset}"
- font-weight="bold"/>
- <subtitle
- font-family="{$title.fontset}"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="chapter" t:wrapper="fo:block"
- font-family="{$title.fontset}">
- <t:titlepage-content t:side="recto" margin-left="{$title.margin.left}">
- <title t:named-template="component.title"
- param:node="ancestor-or-self::chapter[1]"
- font-size="&hsize5;"
- font-weight="bold"/>
-
- <subtitle space-before="0.5em"
- font-style="italic"
- font-size="&hsize2;"
- font-weight="bold"/>
-
- <corpauthor space-before="0.5em"
- space-after="0.5em"
- font-size="&hsize2;"/>
-
- <authorgroup space-before="0.5em"
- space-after="0.5em"
- font-size="&hsize2;"/>
-
- <author space-before="0.5em"
- space-after="0.5em"
- font-size="&hsize2;"/>
-
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="appendix" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:named-template="component.title"
- param:node="ancestor-or-self::appendix[1]"
- margin-left="{$title.margin.left}"
- font-size="&hsize5;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- <subtitle
- font-family="{$title.fontset}"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
-<t:titlepage t:element="section" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- margin-left="{$title.margin.left}"
- font-family="{$title.fontset}"/>
- <subtitle
- font-family="{$title.fontset}"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<t:titlepage t:element="sect1" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- margin-left="{$title.margin.left}"
- font-family="{$title.fontset}"/>
- <subtitle
- font-family="{$title.fontset}"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<t:titlepage t:element="sect2" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- margin-left="{$title.margin.left}"
- font-family="{$title.fontset}"/>
- <subtitle
- font-family="{$title.fontset}"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<t:titlepage t:element="sect3" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- margin-left="{$title.margin.left}"
- font-family="{$title.fontset}"/>
- <subtitle
- font-family="{$title.fontset}"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<t:titlepage t:element="sect4" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- margin-left="{$title.margin.left}"
- font-family="{$title.fontset}"/>
- <subtitle
- font-family="{$title.fontset}"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<t:titlepage t:element="sect5" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- margin-left="{$title.margin.left}"
- font-family="{$title.fontset}"/>
- <subtitle
- font-family="{$title.fontset}"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<t:titlepage t:element="simplesect" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- margin-left="{$title.margin.left}"
- font-family="{$title.fontset}"/>
- <subtitle
- font-family="{$title.fontset}"/>
- <corpauthor/>
- <authorgroup/>
- <author/>
- <othercredit/>
- <releaseinfo/>
- <copyright/>
- <legalnotice/>
- <pubdate/>
- <revision/>
- <revhistory/>
- <abstract/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="bibliography" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="component.title"
- param:node="ancestor-or-self::bibliography[1]"
- margin-left="{$title.margin.left}"
- font-size="&hsize5;"
- font-family="{$title.fontset}"
- font-weight="bold"/>
- <subtitle
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="bibliodiv" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title t:named-template="component.title"
- param:node="ancestor-or-self::bibliodiv[1]"
- margin-left="{$title.margin.left}"
- font-size="&hsize4;"
- font-family="{$title.fontset}"
- font-weight="bold"/>
- <subtitle
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="glossary" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="component.title"
- param:node="ancestor-or-self::glossary[1]"
- margin-left="{$title.margin.left}"
- font-size="&hsize5;"
- font-family="{$title.fontset}"
- font-weight="bold"/>
- <subtitle
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="glossdiv" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title t:named-template="component.title"
- param:node="ancestor-or-self::glossdiv[1]"
- margin-left="{$title.margin.left}"
- font-size="&hsize4;"
- font-family="{$title.fontset}"
- font-weight="bold"/>
- <subtitle
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="index" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="component.title"
- param:node="ancestor-or-self::index[1]"
- param:pagewide="1"
- margin-left="0pt"
- font-size="&hsize5;"
- font-family="{$title.fontset}"
- font-weight="bold"/>
- <subtitle
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
-<!-- ==================================================================== -->
-
- <!-- The indexdiv.title template is used so that manual and -->
- <!-- automatically generated indexdiv titles get the same -->
- <!-- formatting. -->
-
- <t:titlepage t:element="indexdiv" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title t:force="1"
- t:named-template="indexdiv.title"
- param:title="title"/>
- <subtitle
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="setindex" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="component.title"
- param:node="ancestor-or-self::setindex[1]"
- param:pagewide="1"
- margin-left="0pt"
- font-size="&hsize5;"
- font-family="{$title.fontset}"
- font-weight="bold"/>
- <subtitle
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="colophon" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="component.title"
- param:node="ancestor-or-self::colophon[1]"
- margin-left="{$title.margin.left}"
- font-size="&hsize5;"
- font-family="{$title.fontset}"
- font-weight="bold"/>
- <subtitle
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
-</t:titlepage>
-
-<!-- ==================================================================== -->
-
- <t:titlepage t:element="table.of.contents" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="gentext"
- param:key="'TableofContents'"
- space-before.minimum="1em"
- space-before.optimum="1.5em"
- space-before.maximum="2em"
- space-after="0.5em"
- margin-left="{$title.margin.left}"
- font-size="&hsize3;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
- <t:titlepage t:element="list.of.tables" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="gentext"
- param:key="'ListofTables'"
- space-before.minimum="1em"
- space-before.optimum="1.5em"
- space-before.maximum="2em"
- space-after="0.5em"
- margin-left="{$title.margin.left}"
- font-size="&hsize3;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
- <t:titlepage t:element="list.of.figures" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="gentext"
- param:key="'ListofFigures'"
- space-before.minimum="1em"
- space-before.optimum="1.5em"
- space-before.maximum="2em"
- space-after="0.5em"
- margin-left="{$title.margin.left}"
- font-size="&hsize3;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
- <t:titlepage t:element="list.of.examples" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="gentext"
- param:key="'ListofExamples'"
- space-before.minimum="1em"
- space-before.optimum="1.5em"
- space-before.maximum="2em"
- space-after="0.5em"
- margin-left="{$title.margin.left}"
- font-size="&hsize3;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
- <t:titlepage t:element="list.of.equations" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="gentext"
- param:key="'ListofEquations'"
- space-before.minimum="1em"
- space-before.optimum="1.5em"
- space-before.maximum="2em"
- space-after="0.5em"
- margin-left="{$title.margin.left}"
- font-size="&hsize3;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
- <t:titlepage t:element="list.of.procedures" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="gentext"
- param:key="'ListofProcedures'"
- space-before.minimum="1em"
- space-before.optimum="1.5em"
- space-before.maximum="2em"
- space-after="0.5em"
- margin-left="{$title.margin.left}"
- font-size="&hsize3;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
- <t:titlepage t:element="list.of.unknowns" t:wrapper="fo:block">
- <t:titlepage-content t:side="recto">
- <title
- t:force="1"
- t:named-template="gentext"
- param:key="'ListofUnknown'"
- space-before.minimum="1em"
- space-before.optimum="1.5em"
- space-before.maximum="2em"
- space-after="0.5em"
- margin-left="{$title.margin.left}"
- font-size="&hsize3;"
- font-weight="bold"
- font-family="{$title.fontset}"/>
- </t:titlepage-content>
-
- <t:titlepage-content t:side="verso">
- </t:titlepage-content>
-
- <t:titlepage-separator>
- </t:titlepage-separator>
-
- <t:titlepage-before t:side="recto">
- </t:titlepage-before>
-
- <t:titlepage-before t:side="verso">
- </t:titlepage-before>
- </t:titlepage>
-
-<!-- ==================================================================== -->
-
-</t:templates>
diff --git a/doc/tools/docbook-to-pdf b/doc/tools/docbook-to-pdf
deleted file mode 100755
index 558ded9e0..000000000
--- a/doc/tools/docbook-to-pdf
+++ /dev/null
@@ -1,51 +0,0 @@
-#!/bin/sh
-
-if [ -z "$1" -o -z "$2" ]; then
- echo "usage: [-v] $0 <docbook file> <templatedir>"
- echo
- echo "*NOTE* you need xsltproc, fop and nwalsh docbook stylesheets"
- echo " installed for this to work!"
- echo
- exit 0
-fi
-
-FO=`echo $1 | sed s/.xml/.fo/` || exit 1
-PDF=`echo $1 | sed s/.xml/.pdf/` || exit 1
-TEMPLATEDIR=$2
-
-##
-# These URI should be rewritten by your distribution's xml catalog to
-# match your localy installed XSL stylesheets.
-XSL_BASE_URI="http://docbook.sourceforge.net/release/xsl/current"
-
-# Creates a temporary XSL stylesheet based on titlepage.xsl
-xsltproc -o /tmp/titlepage.xsl \
- --xinclude \
- $XSL_BASE_URI/template/titlepage.xsl \
- $TEMPLATEDIR/titlepage.templates.xml || exit 1
-
-# Creates the file needed for FOP
-xsltproc --xinclude \
- --stringparam hyphenate false \
- --stringparam formal.title.placement "figure after" \
- --stringparam ulink.show 1 \
- --stringparam body.font.master 9 \
- --stringparam title.font.master 11 \
- --stringparam draft.watermark.image "$TEMPLATEDIR/draft.png" \
- --stringparam chapter.autolabel 1 \
- --stringparam appendix.autolabel A \
- --stringparam section.autolabel 1 \
- --stringparam section.label.includes.component.label 1 \
- --output $FO \
- $TEMPLATEDIR/db-pdf.xsl \
- $1 || exit 1
-
-# Invokes the Java version of FOP. Uses the additional configuration file common/fop-config.xml
-fop -c $TEMPLATEDIR/fop-config.xml -fo $FO -pdf $PDF || exit 1
-
-rm -f $FO
-rm -f /tmp/titlepage.xsl
-
-echo
-echo " #### Success! $PDF ready. ####"
-echo