mirror of
git://git.yoctoproject.org/poky.git
synced 2025-07-19 21:09:03 +02:00
bitbake: sphinx: remove DocBook files
The BitBake documentation was migrated to Sphinx. Let's remove the deprecated DocBook files. (Bitbake rev: 427721d8ff2c8e1db8cb490074f2eed88d03852a) Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Nicolas Dechesne
Richard Purdie
parent
d4a59548be
commit
dd50ad9173
|
|
@ -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;
|
|
||||||
|
|
@ -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>
|
|
||||||
File diff suppressed because it is too large
Load Diff
|
|
@ -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 '&' characters:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47"
|
|
||||||
</literallayout>
|
|
||||||
In most cases this should work. Treating semi-colons and '&' 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&a=snapshot&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>
|
|
||||||
|
|
@ -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/<you>/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>
|
|
||||||
|
|
@ -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_<task>).
|
|
||||||
-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>
|
|
||||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -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;
|
|
||||||
}
|
|
||||||
|
|
@ -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>
|
|
||||||
|
|
@ -1,281 +0,0 @@
|
||||||
/* Feuille de style DocBook du projet Traduc.org */
|
|
||||||
/* DocBook CSS stylesheet of the Traduc.org project */
|
|
||||||
|
|
||||||
/* (c) Jean-Philippe Guérard - 14 août 2004 */
|
|
||||||
/* (c) Jean-Philippe Guérard - 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 dernière 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'hésitez pas à envoyer vos commentaires et corrections à */
|
|
||||||
/* Jean-Philippe Guérard <jean-philippe.guerard@tigreraye.org> */
|
|
||||||
|
|
||||||
/* Please send feedback and bug reports to */
|
|
||||||
/* Jean-Philippe Guérard <jean-philippe.guerard@tigreraye.org> */
|
|
||||||
|
|
||||||
/* $Id: style.css,v 1.14 2004/09/10 20:12:09 fevrier Exp fevrier $ */
|
|
||||||
|
|
||||||
/* Présentation générale 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 imbriqués */
|
|
||||||
/* 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 français) */
|
|
||||||
/* 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 litéraux : 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 surlignés en vert pâle */
|
|
||||||
/* 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 soulignés */
|
|
||||||
/* 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 légèrement 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 */
|
|
||||||
|
|
||||||
|
|
@ -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">
|
|
||||||
1
bitbake/doc/template/Vera.xml
vendored
1
bitbake/doc/template/Vera.xml
vendored
File diff suppressed because one or more lines are too long
1
bitbake/doc/template/VeraMoBd.xml
vendored
1
bitbake/doc/template/VeraMoBd.xml
vendored
File diff suppressed because one or more lines are too long
1
bitbake/doc/template/VeraMono.xml
vendored
1
bitbake/doc/template/VeraMono.xml
vendored
File diff suppressed because one or more lines are too long
39
bitbake/doc/template/component.title.xsl
vendored
39
bitbake/doc/template/component.title.xsl
vendored
|
|
@ -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>
|
|
||||||
64
bitbake/doc/template/db-pdf.xsl
vendored
64
bitbake/doc/template/db-pdf.xsl
vendored
|
|
@ -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>
|
|
||||||
25
bitbake/doc/template/division.title.xsl
vendored
25
bitbake/doc/template/division.title.xsl
vendored
|
|
@ -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>
|
|
||||||
|
|
||||||
58
bitbake/doc/template/fop-config.xml
vendored
58
bitbake/doc/template/fop-config.xml
vendored
|
|
@ -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>
|
|
||||||
|
|
||||||
21
bitbake/doc/template/formal.object.heading.xsl
vendored
21
bitbake/doc/template/formal.object.heading.xsl
vendored
|
|
@ -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>
|
|
||||||
14
bitbake/doc/template/gloss-permalinks.xsl
vendored
14
bitbake/doc/template/gloss-permalinks.xsl
vendored
|
|
@ -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>
|
|
||||||
25
bitbake/doc/template/permalinks.xsl
vendored
25
bitbake/doc/template/permalinks.xsl
vendored
|
|
@ -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>
|
|
||||||
55
bitbake/doc/template/section.title.xsl
vendored
55
bitbake/doc/template/section.title.xsl
vendored
|
|
@ -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 > 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>
|
|
||||||
1259
bitbake/doc/template/titlepage.templates.xml
vendored
1259
bitbake/doc/template/titlepage.templates.xml
vendored
File diff suppressed because it is too large
Load Diff
|
|
@ -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
|
|
||||||
Loading…
Reference in New Issue
Block a user