diff options
Diffstat (limited to 'bitbake/doc')
25 files changed, 0 insertions, 11898 deletions
diff --git a/bitbake/doc/Makefile b/bitbake/doc/Makefile deleted file mode 100644 index 3c28f4b222..0000000000 --- a/bitbake/doc/Makefile +++ /dev/null | |||
@@ -1,91 +0,0 @@ | |||
1 | # This is a single Makefile to handle all generated BitBake documents. | ||
2 | # The Makefile needs to live in the documentation directory and all figures used | ||
3 | # in any manuals must be .PNG files and live in the individual book's figures | ||
4 | # directory. | ||
5 | # | ||
6 | # The Makefile has these targets: | ||
7 | # | ||
8 | # pdf: generates a PDF version of a manual. | ||
9 | # html: generates an HTML version of a manual. | ||
10 | # tarball: creates a tarball for the doc files. | ||
11 | # validate: validates | ||
12 | # clean: removes files | ||
13 | # | ||
14 | # The Makefile generates an HTML version of every document. The | ||
15 | # variable DOC indicates the folder name for a given manual. | ||
16 | # | ||
17 | # To build a manual, you must invoke 'make' with the DOC argument. | ||
18 | # | ||
19 | # Examples: | ||
20 | # | ||
21 | # make DOC=bitbake-user-manual | ||
22 | # make pdf DOC=bitbake-user-manual | ||
23 | # | ||
24 | # The first example generates the HTML version of the User Manual. | ||
25 | # The second example generates the PDF version of the User Manual. | ||
26 | # | ||
27 | |||
28 | ifeq ($(DOC),bitbake-user-manual) | ||
29 | XSLTOPTS = --stringparam html.stylesheet bitbake-user-manual-style.css \ | ||
30 | --stringparam chapter.autolabel 1 \ | ||
31 | --stringparam section.autolabel 1 \ | ||
32 | --stringparam section.label.includes.component.label 1 \ | ||
33 | --xinclude | ||
34 | ALLPREQ = html tarball | ||
35 | TARFILES = bitbake-user-manual-style.css bitbake-user-manual.html figures/bitbake-title.png | ||
36 | MANUALS = $(DOC)/$(DOC).html | ||
37 | FIGURES = figures | ||
38 | STYLESHEET = $(DOC)/*.css | ||
39 | |||
40 | endif | ||
41 | |||
42 | ## | ||
43 | # These URI should be rewritten by your distribution's xml catalog to | ||
44 | # match your localy installed XSL stylesheets. | ||
45 | XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current | ||
46 | XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl | ||
47 | |||
48 | all: $(ALLPREQ) | ||
49 | |||
50 | pdf: | ||
51 | ifeq ($(DOC),bitbake-user-manual) | ||
52 | @echo " " | ||
53 | @echo "********** Building."$(DOC) | ||
54 | @echo " " | ||
55 | cd $(DOC); ../tools/docbook-to-pdf $(DOC).xml ../template; cd .. | ||
56 | endif | ||
57 | |||
58 | html: | ||
59 | ifeq ($(DOC),bitbake-user-manual) | ||
60 | # See http://www.sagehill.net/docbookxsl/HtmlOutput.html | ||
61 | @echo " " | ||
62 | @echo "******** Building "$(DOC) | ||
63 | @echo " " | ||
64 | cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd .. | ||
65 | endif | ||
66 | |||
67 | tarball: html | ||
68 | @echo " " | ||
69 | @echo "******** Creating Tarball of document files" | ||
70 | @echo " " | ||
71 | cd $(DOC); tar -cvzf $(DOC).tgz $(TARFILES); cd .. | ||
72 | |||
73 | validate: | ||
74 | cd $(DOC); xmllint --postvalid --xinclude --noout $(DOC).xml; cd .. | ||
75 | |||
76 | publish: | ||
77 | @if test -f $(DOC)/$(DOC).html; \ | ||
78 | then \ | ||
79 | echo " "; \ | ||
80 | echo "******** Publishing "$(DOC)".html"; \ | ||
81 | echo " "; \ | ||
82 | scp -r $(MANUALS) $(STYLESHEET) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \ | ||
83 | cd $(DOC); scp -r $(FIGURES) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \ | ||
84 | else \ | ||
85 | echo " "; \ | ||
86 | echo $(DOC)".html missing. Generate the file first then try again."; \ | ||
87 | echo " "; \ | ||
88 | fi | ||
89 | |||
90 | clean: | ||
91 | rm -rf $(MANUALS); rm $(DOC)/$(DOC).tgz; | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-customization.xsl b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-customization.xsl deleted file mode 100644 index 5985ea783f..0000000000 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-customization.xsl +++ /dev/null | |||
@@ -1,29 +0,0 @@ | |||
1 | <?xml version='1.0'?> | ||
2 | <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"> | ||
3 | |||
4 | <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" /> | ||
5 | |||
6 | <!-- | ||
7 | |||
8 | <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" /> | ||
9 | |||
10 | <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" /> | ||
11 | |||
12 | --> | ||
13 | |||
14 | <xsl:include href="../template/permalinks.xsl"/> | ||
15 | <xsl:include href="../template/section.title.xsl"/> | ||
16 | <xsl:include href="../template/component.title.xsl"/> | ||
17 | <xsl:include href="../template/division.title.xsl"/> | ||
18 | <xsl:include href="../template/formal.object.heading.xsl"/> | ||
19 | <xsl:include href="../template/gloss-permalinks.xsl"/> | ||
20 | |||
21 | <xsl:param name="html.stylesheet" select="'user-manual-style.css'" /> | ||
22 | <xsl:param name="chapter.autolabel" select="1" /> | ||
23 | <xsl:param name="section.autolabel" select="1" /> | ||
24 | <xsl:param name="section.label.includes.component.label" select="1" /> | ||
25 | <xsl:param name="appendix.autolabel">A</xsl:param> | ||
26 | |||
27 | <!-- <xsl:param name="generate.toc" select="'article nop'"></xsl:param> --> | ||
28 | |||
29 | </xsl:stylesheet> | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml deleted file mode 100644 index 04c5a26b99..0000000000 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml +++ /dev/null | |||
@@ -1,1029 +0,0 @@ | |||
1 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" | ||
2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> | ||
3 | |||
4 | <chapter id="bitbake-user-manual-execution"> | ||
5 | <title>Execution</title> | ||
6 | |||
7 | <para> | ||
8 | The primary purpose for running BitBake is to produce some kind | ||
9 | of output such as a single installable package, a kernel, a software | ||
10 | development kit, or even a full, board-specific bootable Linux image, | ||
11 | complete with bootloader, kernel, and root filesystem. | ||
12 | Of course, you can execute the <filename>bitbake</filename> | ||
13 | command with options that cause it to execute single tasks, | ||
14 | compile single recipe files, capture or clear data, or simply | ||
15 | return information about the execution environment. | ||
16 | </para> | ||
17 | |||
18 | <para> | ||
19 | This chapter describes BitBake's execution process from start | ||
20 | to finish when you use it to create an image. | ||
21 | The execution process is launched using the following command | ||
22 | form: | ||
23 | <literallayout class='monospaced'> | ||
24 | $ bitbake <replaceable>target</replaceable> | ||
25 | </literallayout> | ||
26 | For information on the BitBake command and its options, | ||
27 | see | ||
28 | "<link linkend='bitbake-user-manual-command'>The BitBake Command</link>" | ||
29 | section. | ||
30 | <note> | ||
31 | <para> | ||
32 | Prior to executing BitBake, you should take advantage of available | ||
33 | parallel thread execution on your build host by setting the | ||
34 | <link linkend='var-bb-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> | ||
35 | variable in your project's <filename>local.conf</filename> | ||
36 | configuration file. | ||
37 | </para> | ||
38 | |||
39 | <para> | ||
40 | A common method to determine this value for your build host is to run | ||
41 | the following: | ||
42 | <literallayout class='monospaced'> | ||
43 | $ grep processor /proc/cpuinfo | ||
44 | </literallayout> | ||
45 | This command returns the number of processors, which takes into | ||
46 | account hyper-threading. | ||
47 | Thus, a quad-core build host with hyper-threading most likely | ||
48 | shows eight processors, which is the value you would then assign to | ||
49 | <filename>BB_NUMBER_THREADS</filename>. | ||
50 | </para> | ||
51 | |||
52 | <para> | ||
53 | A possibly simpler solution is that some Linux distributions | ||
54 | (e.g. Debian and Ubuntu) provide the <filename>ncpus</filename> command. | ||
55 | </para> | ||
56 | </note> | ||
57 | </para> | ||
58 | |||
59 | <section id='parsing-the-base-configuration-metadata'> | ||
60 | <title>Parsing the Base Configuration Metadata</title> | ||
61 | |||
62 | <para> | ||
63 | The first thing BitBake does is parse base configuration | ||
64 | metadata. | ||
65 | Base configuration metadata consists of your project's | ||
66 | <filename>bblayers.conf</filename> file to determine what | ||
67 | layers BitBake needs to recognize, all necessary | ||
68 | <filename>layer.conf</filename> files (one from each layer), | ||
69 | and <filename>bitbake.conf</filename>. | ||
70 | The data itself is of various types: | ||
71 | <itemizedlist> | ||
72 | <listitem><para><emphasis>Recipes:</emphasis> | ||
73 | Details about particular pieces of software. | ||
74 | </para></listitem> | ||
75 | <listitem><para><emphasis>Class Data:</emphasis> | ||
76 | An abstraction of common build information | ||
77 | (e.g. how to build a Linux kernel). | ||
78 | </para></listitem> | ||
79 | <listitem><para><emphasis>Configuration Data:</emphasis> | ||
80 | Machine-specific settings, policy decisions, | ||
81 | and so forth. | ||
82 | Configuration data acts as the glue to bind everything | ||
83 | together.</para></listitem> | ||
84 | </itemizedlist> | ||
85 | </para> | ||
86 | |||
87 | <para> | ||
88 | The <filename>layer.conf</filename> files are used to | ||
89 | construct key variables such as | ||
90 | <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link> | ||
91 | and | ||
92 | <link linkend='var-bb-BBFILES'><filename>BBFILES</filename></link>. | ||
93 | <filename>BBPATH</filename> is used to search for | ||
94 | configuration and class files under the | ||
95 | <filename>conf</filename> and <filename>classes</filename> | ||
96 | directories, respectively. | ||
97 | <filename>BBFILES</filename> is used to locate both recipe | ||
98 | and recipe append files | ||
99 | (<filename>.bb</filename> and <filename>.bbappend</filename>). | ||
100 | If there is no <filename>bblayers.conf</filename> file, | ||
101 | it is assumed the user has set the <filename>BBPATH</filename> | ||
102 | and <filename>BBFILES</filename> directly in the environment. | ||
103 | </para> | ||
104 | |||
105 | <para> | ||
106 | Next, the <filename>bitbake.conf</filename> file is located | ||
107 | using the <filename>BBPATH</filename> variable that was | ||
108 | just constructed. | ||
109 | The <filename>bitbake.conf</filename> file may also include other | ||
110 | configuration files using the | ||
111 | <filename>include</filename> or | ||
112 | <filename>require</filename> directives. | ||
113 | </para> | ||
114 | |||
115 | <para> | ||
116 | Prior to parsing configuration files, BitBake looks | ||
117 | at certain variables, including: | ||
118 | <itemizedlist> | ||
119 | <listitem><para> | ||
120 | <link linkend='var-bb-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link> | ||
121 | </para></listitem> | ||
122 | <listitem><para> | ||
123 | <link linkend='var-bb-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link> | ||
124 | </para></listitem> | ||
125 | <listitem><para> | ||
126 | <link linkend='var-bb-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link> | ||
127 | </para></listitem> | ||
128 | <listitem><para> | ||
129 | <link linkend='var-bb-BB_ORIGENV'><filename>BB_ORIGENV</filename></link> | ||
130 | </para></listitem> | ||
131 | <listitem><para> | ||
132 | <link linkend='var-bb-BITBAKE_UI'><filename>BITBAKE_UI</filename></link> | ||
133 | </para></listitem> | ||
134 | </itemizedlist> | ||
135 | The first four variables in this list relate to how BitBake treats shell | ||
136 | environment variables during task execution. | ||
137 | By default, BitBake cleans the environment variables and provides tight | ||
138 | control over the shell execution environment. | ||
139 | However, through the use of these first four variables, you can | ||
140 | apply your control regarding the | ||
141 | environment variables allowed to be used by BitBake in the shell | ||
142 | during execution of tasks. | ||
143 | See the | ||
144 | "<link linkend='passing-information-into-the-build-task-environment'>Passing Information Into the Build Task Environment</link>" | ||
145 | section and the information about these variables in the | ||
146 | variable glossary for more information on how they work and | ||
147 | on how to use them. | ||
148 | </para> | ||
149 | |||
150 | <para> | ||
151 | The base configuration metadata is global | ||
152 | and therefore affects all recipes and tasks that are executed. | ||
153 | </para> | ||
154 | |||
155 | <para> | ||
156 | BitBake first searches the current working directory for an | ||
157 | optional <filename>conf/bblayers.conf</filename> configuration file. | ||
158 | This file is expected to contain a | ||
159 | <link linkend='var-bb-BBLAYERS'><filename>BBLAYERS</filename></link> | ||
160 | variable that is a space-delimited list of 'layer' directories. | ||
161 | Recall that if BitBake cannot find a <filename>bblayers.conf</filename> | ||
162 | file, then it is assumed the user has set the <filename>BBPATH</filename> | ||
163 | and <filename>BBFILES</filename> variables directly in the environment. | ||
164 | </para> | ||
165 | |||
166 | <para> | ||
167 | For each directory (layer) in this list, a <filename>conf/layer.conf</filename> | ||
168 | file is located and parsed with the | ||
169 | <link linkend='var-bb-LAYERDIR'><filename>LAYERDIR</filename></link> | ||
170 | variable being set to the directory where the layer was found. | ||
171 | The idea is these files automatically set up | ||
172 | <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link> | ||
173 | and other variables correctly for a given build directory. | ||
174 | </para> | ||
175 | |||
176 | <para> | ||
177 | BitBake then expects to find the <filename>conf/bitbake.conf</filename> | ||
178 | file somewhere in the user-specified <filename>BBPATH</filename>. | ||
179 | That configuration file generally has include directives to pull | ||
180 | in any other metadata such as files specific to the architecture, | ||
181 | the machine, the local environment, and so forth. | ||
182 | </para> | ||
183 | |||
184 | <para> | ||
185 | Only variable definitions and include directives are allowed | ||
186 | in BitBake <filename>.conf</filename> files. | ||
187 | Some variables directly influence BitBake's behavior. | ||
188 | These variables might have been set from the environment | ||
189 | depending on the environment variables previously | ||
190 | mentioned or set in the configuration files. | ||
191 | The | ||
192 | "<link linkend='ref-bb-variables-glos'>Variables Glossary</link>" | ||
193 | chapter presents a full list of variables. | ||
194 | </para> | ||
195 | |||
196 | <para> | ||
197 | After parsing configuration files, BitBake uses its rudimentary | ||
198 | inheritance mechanism, which is through class files, to inherit | ||
199 | some standard classes. | ||
200 | BitBake parses a class when the inherit directive responsible | ||
201 | for getting that class is encountered. | ||
202 | </para> | ||
203 | |||
204 | <para> | ||
205 | The <filename>base.bbclass</filename> file is always included. | ||
206 | Other classes that are specified in the configuration using the | ||
207 | <link linkend='var-bb-INHERIT'><filename>INHERIT</filename></link> | ||
208 | variable are also included. | ||
209 | BitBake searches for class files in a | ||
210 | <filename>classes</filename> subdirectory under | ||
211 | the paths in <filename>BBPATH</filename> in the same way as | ||
212 | configuration files. | ||
213 | </para> | ||
214 | |||
215 | <para> | ||
216 | A good way to get an idea of the configuration files and | ||
217 | the class files used in your execution environment is to | ||
218 | run the following BitBake command: | ||
219 | <literallayout class='monospaced'> | ||
220 | $ bitbake -e > mybb.log | ||
221 | </literallayout> | ||
222 | Examining the top of the <filename>mybb.log</filename> | ||
223 | shows you the many configuration files and class files | ||
224 | used in your execution environment. | ||
225 | </para> | ||
226 | |||
227 | <note> | ||
228 | <para> | ||
229 | You need to be aware of how BitBake parses curly braces. | ||
230 | If a recipe uses a closing curly brace within the function and | ||
231 | the character has no leading spaces, BitBake produces a parsing | ||
232 | error. | ||
233 | If you use a pair of curly braces in a shell function, the | ||
234 | closing curly brace must not be located at the start of the line | ||
235 | without leading spaces. | ||
236 | </para> | ||
237 | |||
238 | <para> | ||
239 | Here is an example that causes BitBake to produce a parsing | ||
240 | error: | ||
241 | <literallayout class='monospaced'> | ||
242 | fakeroot create_shar() { | ||
243 | cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh | ||
244 | usage() | ||
245 | { | ||
246 | echo "test" | ||
247 | ###### The following "}" at the start of the line causes a parsing error ###### | ||
248 | } | ||
249 | EOF | ||
250 | } | ||
251 | </literallayout> | ||
252 | Writing the recipe this way avoids the error: | ||
253 | <literallayout class='monospaced'> | ||
254 | fakeroot create_shar() { | ||
255 | cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh | ||
256 | usage() | ||
257 | { | ||
258 | echo "test" | ||
259 | ######The following "}" with a leading space at the start of the line avoids the error ###### | ||
260 | } | ||
261 | EOF | ||
262 | } | ||
263 | </literallayout> | ||
264 | </para> | ||
265 | </note> | ||
266 | </section> | ||
267 | |||
268 | <section id='locating-and-parsing-recipes'> | ||
269 | <title>Locating and Parsing Recipes</title> | ||
270 | |||
271 | <para> | ||
272 | During the configuration phase, BitBake will have set | ||
273 | <link linkend='var-bb-BBFILES'><filename>BBFILES</filename></link>. | ||
274 | BitBake now uses it to construct a list of recipes to parse, | ||
275 | along with any append files (<filename>.bbappend</filename>) | ||
276 | to apply. | ||
277 | <filename>BBFILES</filename> is a space-separated list of | ||
278 | available files and supports wildcards. | ||
279 | An example would be: | ||
280 | <literallayout class='monospaced'> | ||
281 | BBFILES = "/path/to/bbfiles/*.bb /path/to/appends/*.bbappend" | ||
282 | </literallayout> | ||
283 | BitBake parses each recipe and append file located | ||
284 | with <filename>BBFILES</filename> and stores the values of | ||
285 | various variables into the datastore. | ||
286 | <note> | ||
287 | Append files are applied in the order they are encountered in | ||
288 | <filename>BBFILES</filename>. | ||
289 | </note> | ||
290 | For each file, a fresh copy of the base configuration is | ||
291 | made, then the recipe is parsed line by line. | ||
292 | Any inherit statements cause BitBake to find and | ||
293 | then parse class files (<filename>.bbclass</filename>) | ||
294 | using | ||
295 | <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link> | ||
296 | as the search path. | ||
297 | Finally, BitBake parses in order any append files found in | ||
298 | <filename>BBFILES</filename>. | ||
299 | </para> | ||
300 | |||
301 | <para> | ||
302 | One common convention is to use the recipe filename to define | ||
303 | pieces of metadata. | ||
304 | For example, in <filename>bitbake.conf</filename> the recipe | ||
305 | name and version are used to set the variables | ||
306 | <link linkend='var-bb-PN'><filename>PN</filename></link> and | ||
307 | <link linkend='var-bb-PV'><filename>PV</filename></link>: | ||
308 | <literallayout class='monospaced'> | ||
309 | PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" | ||
310 | PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" | ||
311 | </literallayout> | ||
312 | In this example, a recipe called "something_1.2.3.bb" would set | ||
313 | <filename>PN</filename> to "something" and | ||
314 | <filename>PV</filename> to "1.2.3". | ||
315 | </para> | ||
316 | |||
317 | <para> | ||
318 | By the time parsing is complete for a recipe, BitBake | ||
319 | has a list of tasks that the recipe defines and a set of | ||
320 | data consisting of keys and values as well as | ||
321 | dependency information about the tasks. | ||
322 | </para> | ||
323 | |||
324 | <para> | ||
325 | BitBake does not need all of this information. | ||
326 | It only needs a small subset of the information to make | ||
327 | decisions about the recipe. | ||
328 | Consequently, BitBake caches the values in which it is | ||
329 | interested and does not store the rest of the information. | ||
330 | Experience has shown it is faster to re-parse the metadata than to | ||
331 | try and write it out to the disk and then reload it. | ||
332 | </para> | ||
333 | |||
334 | <para> | ||
335 | Where possible, subsequent BitBake commands reuse this cache of | ||
336 | recipe information. | ||
337 | The validity of this cache is determined by first computing a | ||
338 | checksum of the base configuration data (see | ||
339 | <link linkend='var-bb-BB_HASHCONFIG_WHITELIST'><filename>BB_HASHCONFIG_WHITELIST</filename></link>) | ||
340 | and then checking if the checksum matches. | ||
341 | If that checksum matches what is in the cache and the recipe | ||
342 | and class files have not changed, BitBake is able to use | ||
343 | the cache. | ||
344 | BitBake then reloads the cached information about the recipe | ||
345 | instead of reparsing it from scratch. | ||
346 | </para> | ||
347 | |||
348 | <para> | ||
349 | Recipe file collections exist to allow the user to | ||
350 | have multiple repositories of | ||
351 | <filename>.bb</filename> files that contain the same | ||
352 | exact package. | ||
353 | For example, one could easily use them to make one's | ||
354 | own local copy of an upstream repository, but with | ||
355 | custom modifications that one does not want upstream. | ||
356 | Here is an example: | ||
357 | <literallayout class='monospaced'> | ||
358 | BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb" | ||
359 | BBFILE_COLLECTIONS = "upstream local" | ||
360 | BBFILE_PATTERN_upstream = "^/stuff/openembedded/" | ||
361 | BBFILE_PATTERN_local = "^/stuff/openembedded.modified/" | ||
362 | BBFILE_PRIORITY_upstream = "5" | ||
363 | BBFILE_PRIORITY_local = "10" | ||
364 | </literallayout> | ||
365 | <note> | ||
366 | The layers mechanism is now the preferred method of collecting | ||
367 | code. | ||
368 | While the collections code remains, its main use is to set layer | ||
369 | priorities and to deal with overlap (conflicts) between layers. | ||
370 | </note> | ||
371 | </para> | ||
372 | </section> | ||
373 | |||
374 | <section id='bb-bitbake-providers'> | ||
375 | <title>Providers</title> | ||
376 | |||
377 | <para> | ||
378 | Assuming BitBake has been instructed to execute a target | ||
379 | and that all the recipe files have been parsed, BitBake | ||
380 | starts to figure out how to build the target. | ||
381 | BitBake looks through the <filename>PROVIDES</filename> list | ||
382 | for each of the recipes. | ||
383 | A <filename>PROVIDES</filename> list is the list of names by which | ||
384 | the recipe can be known. | ||
385 | Each recipe's <filename>PROVIDES</filename> list is created | ||
386 | implicitly through the recipe's | ||
387 | <link linkend='var-bb-PN'><filename>PN</filename></link> variable | ||
388 | and explicitly through the recipe's | ||
389 | <link linkend='var-bb-PROVIDES'><filename>PROVIDES</filename></link> | ||
390 | variable, which is optional. | ||
391 | </para> | ||
392 | |||
393 | <para> | ||
394 | When a recipe uses <filename>PROVIDES</filename>, that recipe's | ||
395 | functionality can be found under an alternative name or names other | ||
396 | than the implicit <filename>PN</filename> name. | ||
397 | As an example, suppose a recipe named <filename>keyboard_1.0.bb</filename> | ||
398 | contained the following: | ||
399 | <literallayout class='monospaced'> | ||
400 | PROVIDES += "fullkeyboard" | ||
401 | </literallayout> | ||
402 | The <filename>PROVIDES</filename> list for this recipe becomes | ||
403 | "keyboard", which is implicit, and "fullkeyboard", which is explicit. | ||
404 | Consequently, the functionality found in | ||
405 | <filename>keyboard_1.0.bb</filename> can be found under two | ||
406 | different names. | ||
407 | </para> | ||
408 | </section> | ||
409 | |||
410 | <section id='bb-bitbake-preferences'> | ||
411 | <title>Preferences</title> | ||
412 | |||
413 | <para> | ||
414 | The <filename>PROVIDES</filename> list is only part of the solution | ||
415 | for figuring out a target's recipes. | ||
416 | Because targets might have multiple providers, BitBake needs | ||
417 | to prioritize providers by determining provider preferences. | ||
418 | </para> | ||
419 | |||
420 | <para> | ||
421 | A common example in which a target has multiple providers | ||
422 | is "virtual/kernel", which is on the | ||
423 | <filename>PROVIDES</filename> list for each kernel recipe. | ||
424 | Each machine often selects the best kernel provider by using a | ||
425 | line similar to the following in the machine configuration file: | ||
426 | <literallayout class='monospaced'> | ||
427 | PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" | ||
428 | </literallayout> | ||
429 | The default | ||
430 | <link linkend='var-bb-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link> | ||
431 | is the provider with the same name as the target. | ||
432 | BitBake iterates through each target it needs to build and | ||
433 | resolves them and their dependencies using this process. | ||
434 | </para> | ||
435 | |||
436 | <para> | ||
437 | Understanding how providers are chosen is made complicated by the fact | ||
438 | that multiple versions might exist for a given provider. | ||
439 | BitBake defaults to the highest version of a provider. | ||
440 | Version comparisons are made using the same method as Debian. | ||
441 | You can use the | ||
442 | <link linkend='var-bb-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></link> | ||
443 | variable to specify a particular version. | ||
444 | You can influence the order by using the | ||
445 | <link linkend='var-bb-DEFAULT_PREFERENCE'><filename>DEFAULT_PREFERENCE</filename></link> | ||
446 | variable. | ||
447 | </para> | ||
448 | |||
449 | <para> | ||
450 | By default, files have a preference of "0". | ||
451 | Setting <filename>DEFAULT_PREFERENCE</filename> to "-1" makes the | ||
452 | recipe unlikely to be used unless it is explicitly referenced. | ||
453 | Setting <filename>DEFAULT_PREFERENCE</filename> to "1" makes it | ||
454 | likely the recipe is used. | ||
455 | <filename>PREFERRED_VERSION</filename> overrides any | ||
456 | <filename>DEFAULT_PREFERENCE</filename> setting. | ||
457 | <filename>DEFAULT_PREFERENCE</filename> is often used to mark newer | ||
458 | and more experimental recipe versions until they have undergone | ||
459 | sufficient testing to be considered stable. | ||
460 | </para> | ||
461 | |||
462 | <para> | ||
463 | When there are multiple “versions†of a given recipe, | ||
464 | BitBake defaults to selecting the most recent | ||
465 | version, unless otherwise specified. | ||
466 | If the recipe in question has a | ||
467 | <link linkend='var-bb-DEFAULT_PREFERENCE'><filename>DEFAULT_PREFERENCE</filename></link> | ||
468 | set lower than the other recipes (default is 0), then | ||
469 | it will not be selected. | ||
470 | This allows the person or persons maintaining | ||
471 | the repository of recipe files to specify | ||
472 | their preference for the default selected version. | ||
473 | Additionally, the user can specify their preferred version. | ||
474 | </para> | ||
475 | |||
476 | <para> | ||
477 | If the first recipe is named <filename>a_1.1.bb</filename>, then the | ||
478 | <link linkend='var-bb-PN'><filename>PN</filename></link> variable | ||
479 | will be set to “aâ€, and the | ||
480 | <link linkend='var-bb-PV'><filename>PV</filename></link> | ||
481 | variable will be set to 1.1. | ||
482 | </para> | ||
483 | |||
484 | <para> | ||
485 | Thus, if a recipe named <filename>a_1.2.bb</filename> exists, BitBake | ||
486 | will choose 1.2 by default. | ||
487 | However, if you define the following variable in a | ||
488 | <filename>.conf</filename> file that BitBake parses, you | ||
489 | can change that preference: | ||
490 | <literallayout class='monospaced'> | ||
491 | PREFERRED_VERSION_a = "1.1" | ||
492 | </literallayout> | ||
493 | </para> | ||
494 | |||
495 | <note> | ||
496 | <para> | ||
497 | It is common for a recipe to provide two versions -- a stable, | ||
498 | numbered (and preferred) version, and a version that is | ||
499 | automatically checked out from a source code repository that | ||
500 | is considered more "bleeding edge" but can be selected only | ||
501 | explicitly. | ||
502 | </para> | ||
503 | |||
504 | <para> | ||
505 | For example, in the OpenEmbedded codebase, there is a standard, | ||
506 | versioned recipe file for BusyBox, | ||
507 | <filename>busybox_1.22.1.bb</filename>, | ||
508 | but there is also a Git-based version, | ||
509 | <filename>busybox_git.bb</filename>, which explicitly contains the line | ||
510 | <literallayout class='monospaced'> | ||
511 | DEFAULT_PREFERENCE = "-1" | ||
512 | </literallayout> | ||
513 | to ensure that the numbered, stable version is always preferred | ||
514 | unless the developer selects otherwise. | ||
515 | </para> | ||
516 | </note> | ||
517 | </section> | ||
518 | |||
519 | <section id='bb-bitbake-dependencies'> | ||
520 | <title>Dependencies</title> | ||
521 | |||
522 | <para> | ||
523 | Each target BitBake builds consists of multiple tasks such as | ||
524 | <filename>fetch</filename>, <filename>unpack</filename>, | ||
525 | <filename>patch</filename>, <filename>configure</filename>, | ||
526 | and <filename>compile</filename>. | ||
527 | For best performance on multi-core systems, BitBake considers each | ||
528 | task as an independent | ||
529 | entity with its own set of dependencies. | ||
530 | </para> | ||
531 | |||
532 | <para> | ||
533 | Dependencies are defined through several variables. | ||
534 | You can find information about variables BitBake uses in | ||
535 | the <link linkend='ref-bb-variables-glos'>Variables Glossary</link> | ||
536 | near the end of this manual. | ||
537 | At a basic level, it is sufficient to know that BitBake uses the | ||
538 | <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> and | ||
539 | <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> variables when | ||
540 | calculating dependencies. | ||
541 | </para> | ||
542 | |||
543 | <para> | ||
544 | For more information on how BitBake handles dependencies, see the | ||
545 | "<link linkend='dependencies'>Dependencies</link>" section. | ||
546 | </para> | ||
547 | </section> | ||
548 | |||
549 | <section id='ref-bitbake-tasklist'> | ||
550 | <title>The Task List</title> | ||
551 | |||
552 | <para> | ||
553 | Based on the generated list of providers and the dependency information, | ||
554 | BitBake can now calculate exactly what tasks it needs to run and in what | ||
555 | order it needs to run them. | ||
556 | The | ||
557 | "<link linkend='executing-tasks'>Executing Tasks</link>" section has more | ||
558 | information on how BitBake chooses which task to execute next. | ||
559 | </para> | ||
560 | |||
561 | <para> | ||
562 | The build now starts with BitBake forking off threads up to the limit set in the | ||
563 | <link linkend='var-bb-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> | ||
564 | variable. | ||
565 | BitBake continues to fork threads as long as there are tasks ready to run, | ||
566 | those tasks have all their dependencies met, and the thread threshold has not been | ||
567 | exceeded. | ||
568 | </para> | ||
569 | |||
570 | <para> | ||
571 | It is worth noting that you can greatly speed up the build time by properly setting | ||
572 | the <filename>BB_NUMBER_THREADS</filename> variable. | ||
573 | </para> | ||
574 | |||
575 | <para> | ||
576 | As each task completes, a timestamp is written to the directory specified by the | ||
577 | <link linkend='var-bb-STAMP'><filename>STAMP</filename></link> variable. | ||
578 | On subsequent runs, BitBake looks in the build directory within | ||
579 | <filename>tmp/stamps</filename> and does not rerun | ||
580 | tasks that are already completed unless a timestamp is found to be invalid. | ||
581 | Currently, invalid timestamps are only considered on a per | ||
582 | recipe file basis. | ||
583 | So, for example, if the configure stamp has a timestamp greater than the | ||
584 | compile timestamp for a given target, then the compile task would rerun. | ||
585 | Running the compile task again, however, has no effect on other providers | ||
586 | that depend on that target. | ||
587 | </para> | ||
588 | |||
589 | <para> | ||
590 | The exact format of the stamps is partly configurable. | ||
591 | In modern versions of BitBake, a hash is appended to the | ||
592 | stamp so that if the configuration changes, the stamp becomes | ||
593 | invalid and the task is automatically rerun. | ||
594 | This hash, or signature used, is governed by the signature policy | ||
595 | that is configured (see the | ||
596 | "<link linkend='checksums'>Checksums (Signatures)</link>" | ||
597 | section for information). | ||
598 | It is also possible to append extra metadata to the stamp using | ||
599 | the <filename>[stamp-extra-info]</filename> task flag. | ||
600 | For example, OpenEmbedded uses this flag to make some tasks machine-specific. | ||
601 | </para> | ||
602 | |||
603 | <note> | ||
604 | Some tasks are marked as "nostamp" tasks. | ||
605 | No timestamp file is created when these tasks are run. | ||
606 | Consequently, "nostamp" tasks are always rerun. | ||
607 | </note> | ||
608 | |||
609 | <para> | ||
610 | For more information on tasks, see the | ||
611 | "<link linkend='tasks'>Tasks</link>" section. | ||
612 | </para> | ||
613 | </section> | ||
614 | |||
615 | <section id='executing-tasks'> | ||
616 | <title>Executing Tasks</title> | ||
617 | |||
618 | <para> | ||
619 | Tasks can be either a shell task or a Python task. | ||
620 | For shell tasks, BitBake writes a shell script to | ||
621 | <filename>${</filename><link linkend='var-bb-T'><filename>T</filename></link><filename>}/run.do_taskname.<replaceable>pid</replaceable></filename> | ||
622 | and then executes the script. | ||
623 | The generated shell script contains all the exported variables, | ||
624 | and the shell functions with all variables expanded. | ||
625 | Output from the shell script goes to the file | ||
626 | <filename>${T}/log.do_taskname.<replaceable>pid</replaceable></filename>. | ||
627 | Looking at the expanded shell functions in the run file and | ||
628 | the output in the log files is a useful debugging technique. | ||
629 | </para> | ||
630 | |||
631 | <para> | ||
632 | For Python tasks, BitBake executes the task internally and logs | ||
633 | information to the controlling terminal. | ||
634 | Future versions of BitBake will write the functions to files | ||
635 | similar to the way shell tasks are handled. | ||
636 | Logging will be handled in a way similar to shell tasks as well. | ||
637 | </para> | ||
638 | |||
639 | <para> | ||
640 | The order in which BitBake runs the tasks is controlled by its | ||
641 | task scheduler. | ||
642 | It is possible to configure the scheduler and define custom | ||
643 | implementations for specific use cases. | ||
644 | For more information, see these variables that control the | ||
645 | behavior: | ||
646 | <itemizedlist> | ||
647 | <listitem><para> | ||
648 | <link linkend='var-bb-BB_SCHEDULER'><filename>BB_SCHEDULER</filename></link> | ||
649 | </para></listitem> | ||
650 | <listitem><para> | ||
651 | <link linkend='var-bb-BB_SCHEDULERS'><filename>BB_SCHEDULERS</filename></link> | ||
652 | </para></listitem> | ||
653 | </itemizedlist> | ||
654 | It is possible to have functions run before and after a task's main | ||
655 | function. | ||
656 | This is done using the <filename>[prefuncs]</filename> | ||
657 | and <filename>[postfuncs]</filename> flags of the task | ||
658 | that lists the functions to run. | ||
659 | </para> | ||
660 | </section> | ||
661 | |||
662 | <section id='checksums'> | ||
663 | <title>Checksums (Signatures)</title> | ||
664 | |||
665 | <para> | ||
666 | A checksum is a unique signature of a task's inputs. | ||
667 | The signature of a task can be used to determine if a task | ||
668 | needs to be run. | ||
669 | Because it is a change in a task's inputs that triggers running | ||
670 | the task, BitBake needs to detect all the inputs to a given task. | ||
671 | For shell tasks, this turns out to be fairly easy because | ||
672 | BitBake generates a "run" shell script for each task and | ||
673 | it is possible to create a checksum that gives you a good idea of when | ||
674 | the task's data changes. | ||
675 | </para> | ||
676 | |||
677 | <para> | ||
678 | To complicate the problem, some things should not be included in | ||
679 | the checksum. | ||
680 | First, there is the actual specific build path of a given task - | ||
681 | the working directory. | ||
682 | It does not matter if the working directory changes because it should not | ||
683 | affect the output for target packages. | ||
684 | The simplistic approach for excluding the working directory is to set | ||
685 | it to some fixed value and create the checksum for the "run" script. | ||
686 | BitBake goes one step better and uses the | ||
687 | <link linkend='var-bb-BB_HASHBASE_WHITELIST'><filename>BB_HASHBASE_WHITELIST</filename></link> | ||
688 | variable to define a list of variables that should never be included | ||
689 | when generating the signatures. | ||
690 | </para> | ||
691 | |||
692 | <para> | ||
693 | Another problem results from the "run" scripts containing functions that | ||
694 | might or might not get called. | ||
695 | The incremental build solution contains code that figures out dependencies | ||
696 | between shell functions. | ||
697 | This code is used to prune the "run" scripts down to the minimum set, | ||
698 | thereby alleviating this problem and making the "run" scripts much more | ||
699 | readable as a bonus. | ||
700 | </para> | ||
701 | |||
702 | <para> | ||
703 | So far we have solutions for shell scripts. | ||
704 | What about Python tasks? | ||
705 | The same approach applies even though these tasks are more difficult. | ||
706 | The process needs to figure out what variables a Python function accesses | ||
707 | and what functions it calls. | ||
708 | Again, the incremental build solution contains code that first figures out | ||
709 | the variable and function dependencies, and then creates a checksum for the data | ||
710 | used as the input to the task. | ||
711 | </para> | ||
712 | |||
713 | <para> | ||
714 | Like the working directory case, situations exist where dependencies | ||
715 | should be ignored. | ||
716 | For these cases, you can instruct the build process to ignore a dependency | ||
717 | by using a line like the following: | ||
718 | <literallayout class='monospaced'> | ||
719 | PACKAGE_ARCHS[vardepsexclude] = "MACHINE" | ||
720 | </literallayout> | ||
721 | This example ensures that the <filename>PACKAGE_ARCHS</filename> variable does not | ||
722 | depend on the value of <filename>MACHINE</filename>, even if it does reference it. | ||
723 | </para> | ||
724 | |||
725 | <para> | ||
726 | Equally, there are cases where we need to add dependencies BitBake | ||
727 | is not able to find. | ||
728 | You can accomplish this by using a line like the following: | ||
729 | <literallayout class='monospaced'> | ||
730 | PACKAGE_ARCHS[vardeps] = "MACHINE" | ||
731 | </literallayout> | ||
732 | This example explicitly adds the <filename>MACHINE</filename> variable as a | ||
733 | dependency for <filename>PACKAGE_ARCHS</filename>. | ||
734 | </para> | ||
735 | |||
736 | <para> | ||
737 | Consider a case with in-line Python, for example, where BitBake is not | ||
738 | able to figure out dependencies. | ||
739 | When running in debug mode (i.e. using <filename>-DDD</filename>), BitBake | ||
740 | produces output when it discovers something for which it cannot figure out | ||
741 | dependencies. | ||
742 | </para> | ||
743 | |||
744 | <para> | ||
745 | Thus far, this section has limited discussion to the direct inputs into a task. | ||
746 | Information based on direct inputs is referred to as the "basehash" in the | ||
747 | code. | ||
748 | However, there is still the question of a task's indirect inputs - the | ||
749 | things that were already built and present in the build directory. | ||
750 | The checksum (or signature) for a particular task needs to add the hashes | ||
751 | of all the tasks on which the particular task depends. | ||
752 | Choosing which dependencies to add is a policy decision. | ||
753 | However, the effect is to generate a master checksum that combines the basehash | ||
754 | and the hashes of the task's dependencies. | ||
755 | </para> | ||
756 | |||
757 | <para> | ||
758 | At the code level, there are a variety of ways both the basehash and the | ||
759 | dependent task hashes can be influenced. | ||
760 | Within the BitBake configuration file, we can give BitBake some extra information | ||
761 | to help it construct the basehash. | ||
762 | The following statement effectively results in a list of global variable | ||
763 | dependency excludes - variables never included in any checksum. | ||
764 | This example uses variables from OpenEmbedded to help illustrate | ||
765 | the concept: | ||
766 | <literallayout class='monospaced'> | ||
767 | BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \ | ||
768 | SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL \ | ||
769 | USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \ | ||
770 | PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \ | ||
771 | CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX" | ||
772 | </literallayout> | ||
773 | The previous example excludes the work directory, which is part of | ||
774 | <filename>TMPDIR</filename>. | ||
775 | </para> | ||
776 | |||
777 | <para> | ||
778 | The rules for deciding which hashes of dependent tasks to include through | ||
779 | dependency chains are more complex and are generally accomplished with a | ||
780 | Python function. | ||
781 | The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples | ||
782 | of this and also illustrates how you can insert your own policy into the system | ||
783 | if so desired. | ||
784 | This file defines the two basic signature generators OpenEmbedded-Core | ||
785 | uses: "OEBasic" and "OEBasicHash". | ||
786 | By default, there is a dummy "noop" signature handler enabled in BitBake. | ||
787 | This means that behavior is unchanged from previous versions. | ||
788 | <filename>OE-Core</filename> uses the "OEBasicHash" signature handler by default | ||
789 | through this setting in the <filename>bitbake.conf</filename> file: | ||
790 | <literallayout class='monospaced'> | ||
791 | BB_SIGNATURE_HANDLER ?= "OEBasicHash" | ||
792 | </literallayout> | ||
793 | The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the | ||
794 | "OEBasic" version but adds the task hash to the stamp files. | ||
795 | This results in any metadata change that changes the task hash, automatically | ||
796 | causing the task to be run again. | ||
797 | This removes the need to bump | ||
798 | <link linkend='var-bb-PR'><filename>PR</filename></link> | ||
799 | values, and changes to metadata automatically ripple across the build. | ||
800 | </para> | ||
801 | |||
802 | <para> | ||
803 | It is also worth noting that the end result of these signature generators is to | ||
804 | make some dependency and hash information available to the build. | ||
805 | This information includes: | ||
806 | <itemizedlist> | ||
807 | <listitem><para><filename>BB_BASEHASH_task-</filename><replaceable>taskname</replaceable>: | ||
808 | The base hashes for each task in the recipe. | ||
809 | </para></listitem> | ||
810 | <listitem><para><filename>BB_BASEHASH_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>: | ||
811 | The base hashes for each dependent task. | ||
812 | </para></listitem> | ||
813 | <listitem><para><filename>BBHASHDEPS_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>: | ||
814 | The task dependencies for each task. | ||
815 | </para></listitem> | ||
816 | <listitem><para><filename>BB_TASKHASH</filename>: | ||
817 | The hash of the currently running task. | ||
818 | </para></listitem> | ||
819 | </itemizedlist> | ||
820 | </para> | ||
821 | |||
822 | <para> | ||
823 | It is worth noting that BitBake's "-S" option lets you | ||
824 | debug BitBake's processing of signatures. | ||
825 | The options passed to -S allow different debugging modes | ||
826 | to be used, either using BitBake's own debug functions | ||
827 | or possibly those defined in the metadata/signature handler | ||
828 | itself. | ||
829 | The simplest parameter to pass is "none", which causes a | ||
830 | set of signature information to be written out into | ||
831 | <filename>STAMPS_DIR</filename> | ||
832 | corresponding to the targets specified. | ||
833 | The other currently available parameter is "printdiff", | ||
834 | which causes BitBake to try to establish the closest | ||
835 | signature match it can (e.g. in the sstate cache) and then | ||
836 | run <filename>bitbake-diffsigs</filename> over the matches | ||
837 | to determine the stamps and delta where these two | ||
838 | stamp trees diverge. | ||
839 | <note> | ||
840 | It is likely that future versions of BitBake will | ||
841 | provide other signature handlers triggered through | ||
842 | additional "-S" parameters. | ||
843 | </note> | ||
844 | </para> | ||
845 | |||
846 | <para> | ||
847 | You can find more information on checksum metadata in the | ||
848 | "<link linkend='task-checksums-and-setscene'>Task Checksums and Setscene</link>" | ||
849 | section. | ||
850 | </para> | ||
851 | </section> | ||
852 | |||
853 | <section id='setscene'> | ||
854 | <title>Setscene</title> | ||
855 | |||
856 | <para> | ||
857 | The setscene process enables BitBake to handle "pre-built" artifacts. | ||
858 | The ability to handle and reuse these artifacts allows BitBake | ||
859 | the luxury of not having to build something from scratch every time. | ||
860 | Instead, BitBake can use, when possible, existing build artifacts. | ||
861 | </para> | ||
862 | |||
863 | <para> | ||
864 | BitBake needs to have reliable data indicating whether or not an | ||
865 | artifact is compatible. | ||
866 | Signatures, described in the previous section, provide an ideal | ||
867 | way of representing whether an artifact is compatible. | ||
868 | If a signature is the same, an object can be reused. | ||
869 | </para> | ||
870 | |||
871 | <para> | ||
872 | If an object can be reused, the problem then becomes how to | ||
873 | replace a given task or set of tasks with the pre-built artifact. | ||
874 | BitBake solves the problem with the "setscene" process. | ||
875 | </para> | ||
876 | |||
877 | <para> | ||
878 | When BitBake is asked to build a given target, before building anything, | ||
879 | it first asks whether cached information is available for any of the | ||
880 | targets it's building, or any of the intermediate targets. | ||
881 | If cached information is available, BitBake uses this information instead of | ||
882 | running the main tasks. | ||
883 | </para> | ||
884 | |||
885 | <para> | ||
886 | BitBake first calls the function defined by the | ||
887 | <link linkend='var-bb-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></link> | ||
888 | variable with a list of tasks and corresponding | ||
889 | hashes it wants to build. | ||
890 | This function is designed to be fast and returns a list | ||
891 | of the tasks for which it believes in can obtain artifacts. | ||
892 | </para> | ||
893 | |||
894 | <para> | ||
895 | Next, for each of the tasks that were returned as possibilities, | ||
896 | BitBake executes a setscene version of the task that the possible | ||
897 | artifact covers. | ||
898 | Setscene versions of a task have the string "_setscene" appended to the | ||
899 | task name. | ||
900 | So, for example, the task with the name <filename>xxx</filename> has | ||
901 | a setscene task named <filename>xxx_setscene</filename>. | ||
902 | The setscene version of the task executes and provides the necessary | ||
903 | artifacts returning either success or failure. | ||
904 | </para> | ||
905 | |||
906 | <para> | ||
907 | As previously mentioned, an artifact can cover more than one task. | ||
908 | For example, it is pointless to obtain a compiler if you | ||
909 | already have the compiled binary. | ||
910 | To handle this, BitBake calls the | ||
911 | <link linkend='var-bb-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></link> | ||
912 | function for each successful setscene task to know whether or not it needs | ||
913 | to obtain the dependencies of that task. | ||
914 | </para> | ||
915 | |||
916 | <para> | ||
917 | Finally, after all the setscene tasks have executed, BitBake calls the | ||
918 | function listed in | ||
919 | <link linkend='var-bb-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></link> | ||
920 | with the list of tasks BitBake thinks has been "covered". | ||
921 | The metadata can then ensure that this list is correct and can | ||
922 | inform BitBake that it wants specific tasks to be run regardless | ||
923 | of the setscene result. | ||
924 | </para> | ||
925 | |||
926 | <para> | ||
927 | You can find more information on setscene metadata in the | ||
928 | "<link linkend='task-checksums-and-setscene'>Task Checksums and Setscene</link>" | ||
929 | section. | ||
930 | </para> | ||
931 | </section> | ||
932 | |||
933 | <section id="logging"> | ||
934 | <title>Logging</title> | ||
935 | <para> | ||
936 | In addition to the standard command line option to control how | ||
937 | verbose builds are when execute, bitbake also supports user defined | ||
938 | configuration of the | ||
939 | <ulink url='https://docs.python.org/3/library/logging.html'>Python logging</ulink> | ||
940 | facilities through the | ||
941 | <link linkend="var-bb-BB_LOGCONFIG"><filename>BB_LOGCONFIG</filename></link> | ||
942 | variable. This variable defines a json or yaml | ||
943 | <ulink url='https://docs.python.org/3/library/logging.config.html'>logging configuration</ulink> | ||
944 | that will be intelligently merged into the default configuration. | ||
945 | The logging configuration is merged using the following rules: | ||
946 | <itemizedlist> | ||
947 | <listitem><para> | ||
948 | The user defined configuration will completely replace the default | ||
949 | configuration if top level key | ||
950 | <filename>bitbake_merge</filename> is set to the value | ||
951 | <filename>False</filename>. In this case, all other rules | ||
952 | are ignored. | ||
953 | </para></listitem> | ||
954 | <listitem><para> | ||
955 | The user configuration must have a top level | ||
956 | <filename>version</filename> which must match the value of | ||
957 | the default configuration. | ||
958 | </para></listitem> | ||
959 | <listitem><para> | ||
960 | Any keys defined in the <filename>handlers</filename>, | ||
961 | <filename>formatters</filename>, or <filename>filters</filename>, | ||
962 | will be merged into the same section in the default | ||
963 | configuration, with the user specified keys taking | ||
964 | replacing a default one if there is a conflict. In | ||
965 | practice, this means that if both the default configuration | ||
966 | and user configuration specify a handler named | ||
967 | <filename>myhandler</filename>, the user defined one will | ||
968 | replace the default. To prevent the user from inadvertently | ||
969 | replacing a default handler, formatter, or filter, all of | ||
970 | the default ones are named with a prefix of | ||
971 | "<filename>BitBake.</filename>" | ||
972 | </para></listitem> | ||
973 | <listitem><para> | ||
974 | If a logger is defined by the user with the key | ||
975 | <filename>bitbake_merge</filename> set to | ||
976 | <filename>False</filename>, that logger will be completely | ||
977 | replaced by user configuration. In this case, no other | ||
978 | rules will apply to that logger. | ||
979 | </para></listitem> | ||
980 | <listitem><para> | ||
981 | All user defined <filename>filter</filename> and | ||
982 | <filename>handlers</filename> properties for a given logger | ||
983 | will be merged with corresponding properties from the | ||
984 | default logger. For example, if the user configuration adds | ||
985 | a filter called <filename>myFilter</filename> to the | ||
986 | <filename>BitBake.SigGen</filename>, and the default | ||
987 | configuration adds a filter called | ||
988 | <filename>BitBake.defaultFilter</filename>, both filters | ||
989 | will be applied to the logger | ||
990 | </para></listitem> | ||
991 | </itemizedlist> | ||
992 | </para> | ||
993 | |||
994 | <para> | ||
995 | As an example, consider the following user logging configuration | ||
996 | file which logs all Hash Equivalence related messages of VERBOSE or | ||
997 | higher to a file called <filename>hashequiv.log</filename> | ||
998 | <literallayout class='monospaced'> | ||
999 | { | ||
1000 | "version": 1, | ||
1001 | "handlers": { | ||
1002 | "autobuilderlog": { | ||
1003 | "class": "logging.FileHandler", | ||
1004 | "formatter": "logfileFormatter", | ||
1005 | "level": "DEBUG", | ||
1006 | "filename": "hashequiv.log", | ||
1007 | "mode": "w" | ||
1008 | } | ||
1009 | }, | ||
1010 | "formatters": { | ||
1011 | "logfileFormatter": { | ||
1012 | "format": "%(name)s: %(levelname)s: %(message)s" | ||
1013 | } | ||
1014 | }, | ||
1015 | "loggers": { | ||
1016 | "BitBake.SigGen.HashEquiv": { | ||
1017 | "level": "VERBOSE", | ||
1018 | "handlers": ["autobuilderlog"] | ||
1019 | }, | ||
1020 | "BitBake.RunQueue.HashEquiv": { | ||
1021 | "level": "VERBOSE", | ||
1022 | "handlers": ["autobuilderlog"] | ||
1023 | } | ||
1024 | } | ||
1025 | } | ||
1026 | </literallayout> | ||
1027 | </para> | ||
1028 | </section> | ||
1029 | </chapter> | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml deleted file mode 100644 index fe4372adeb..0000000000 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml +++ /dev/null | |||
@@ -1,928 +0,0 @@ | |||
1 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" | ||
2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> | ||
3 | |||
4 | <chapter> | ||
5 | <title>File Download Support</title> | ||
6 | |||
7 | <para> | ||
8 | BitBake's fetch module is a standalone piece of library code | ||
9 | that deals with the intricacies of downloading source code | ||
10 | and files from remote systems. | ||
11 | Fetching source code is one of the cornerstones of building software. | ||
12 | As such, this module forms an important part of BitBake. | ||
13 | </para> | ||
14 | |||
15 | <para> | ||
16 | The current fetch module is called "fetch2" and refers to the | ||
17 | fact that it is the second major version of the API. | ||
18 | The original version is obsolete and has been removed from the codebase. | ||
19 | Thus, in all cases, "fetch" refers to "fetch2" in this | ||
20 | manual. | ||
21 | </para> | ||
22 | |||
23 | <section id='the-download-fetch'> | ||
24 | <title>The Download (Fetch)</title> | ||
25 | |||
26 | <para> | ||
27 | BitBake takes several steps when fetching source code or files. | ||
28 | The fetcher codebase deals with two distinct processes in order: | ||
29 | obtaining the files from somewhere (cached or otherwise) | ||
30 | and then unpacking those files into a specific location and | ||
31 | perhaps in a specific way. | ||
32 | Getting and unpacking the files is often optionally followed | ||
33 | by patching. | ||
34 | Patching, however, is not covered by this module. | ||
35 | </para> | ||
36 | |||
37 | <para> | ||
38 | The code to execute the first part of this process, a fetch, | ||
39 | looks something like the following: | ||
40 | <literallayout class='monospaced'> | ||
41 | src_uri = (d.getVar('SRC_URI') or "").split() | ||
42 | fetcher = bb.fetch2.Fetch(src_uri, d) | ||
43 | fetcher.download() | ||
44 | </literallayout> | ||
45 | This code sets up an instance of the fetch class. | ||
46 | The instance uses a space-separated list of URLs from the | ||
47 | <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link> | ||
48 | variable and then calls the <filename>download</filename> | ||
49 | method to download the files. | ||
50 | </para> | ||
51 | |||
52 | <para> | ||
53 | The instantiation of the fetch class is usually followed by: | ||
54 | <literallayout class='monospaced'> | ||
55 | rootdir = l.getVar('WORKDIR') | ||
56 | fetcher.unpack(rootdir) | ||
57 | </literallayout> | ||
58 | This code unpacks the downloaded files to the | ||
59 | specified by <filename>WORKDIR</filename>. | ||
60 | <note> | ||
61 | For convenience, the naming in these examples matches | ||
62 | the variables used by OpenEmbedded. | ||
63 | If you want to see the above code in action, examine | ||
64 | the OpenEmbedded class file <filename>base.bbclass</filename>. | ||
65 | </note> | ||
66 | The <filename>SRC_URI</filename> and <filename>WORKDIR</filename> | ||
67 | variables are not hardcoded into the fetcher, since those fetcher | ||
68 | methods can be (and are) called with different variable names. | ||
69 | In OpenEmbedded for example, the shared state (sstate) code uses | ||
70 | the fetch module to fetch the sstate files. | ||
71 | </para> | ||
72 | |||
73 | <para> | ||
74 | When the <filename>download()</filename> method is called, | ||
75 | BitBake tries to resolve the URLs by looking for source files | ||
76 | in a specific search order: | ||
77 | <itemizedlist> | ||
78 | <listitem><para><emphasis>Pre-mirror Sites:</emphasis> | ||
79 | BitBake first uses pre-mirrors to try and find source files. | ||
80 | These locations are defined using the | ||
81 | <link linkend='var-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link> | ||
82 | variable. | ||
83 | </para></listitem> | ||
84 | <listitem><para><emphasis>Source URI:</emphasis> | ||
85 | If pre-mirrors fail, BitBake uses the original URL (e.g from | ||
86 | <filename>SRC_URI</filename>). | ||
87 | </para></listitem> | ||
88 | <listitem><para><emphasis>Mirror Sites:</emphasis> | ||
89 | If fetch failures occur, BitBake next uses mirror locations as | ||
90 | defined by the | ||
91 | <link linkend='var-bb-MIRRORS'><filename>MIRRORS</filename></link> | ||
92 | variable. | ||
93 | </para></listitem> | ||
94 | </itemizedlist> | ||
95 | </para> | ||
96 | |||
97 | <para> | ||
98 | For each URL passed to the fetcher, the fetcher | ||
99 | calls the submodule that handles that particular URL type. | ||
100 | This behavior can be the source of some confusion when you | ||
101 | are providing URLs for the <filename>SRC_URI</filename> | ||
102 | variable. | ||
103 | Consider the following two URLs: | ||
104 | <literallayout class='monospaced'> | ||
105 | http://git.yoctoproject.org/git/poky;protocol=git | ||
106 | git://git.yoctoproject.org/git/poky;protocol=http | ||
107 | </literallayout> | ||
108 | In the former case, the URL is passed to the | ||
109 | <filename>wget</filename> fetcher, which does not | ||
110 | understand "git". | ||
111 | Therefore, the latter case is the correct form since the | ||
112 | Git fetcher does know how to use HTTP as a transport. | ||
113 | </para> | ||
114 | |||
115 | <para> | ||
116 | Here are some examples that show commonly used mirror | ||
117 | definitions: | ||
118 | <literallayout class='monospaced'> | ||
119 | PREMIRRORS ?= "\ | ||
120 | bzr://.*/.* http://somemirror.org/sources/ \n \ | ||
121 | cvs://.*/.* http://somemirror.org/sources/ \n \ | ||
122 | git://.*/.* http://somemirror.org/sources/ \n \ | ||
123 | hg://.*/.* http://somemirror.org/sources/ \n \ | ||
124 | osc://.*/.* http://somemirror.org/sources/ \n \ | ||
125 | p4://.*/.* http://somemirror.org/sources/ \n \ | ||
126 | svn://.*/.* http://somemirror.org/sources/ \n" | ||
127 | |||
128 | MIRRORS =+ "\ | ||
129 | ftp://.*/.* http://somemirror.org/sources/ \n \ | ||
130 | http://.*/.* http://somemirror.org/sources/ \n \ | ||
131 | https://.*/.* http://somemirror.org/sources/ \n" | ||
132 | </literallayout> | ||
133 | It is useful to note that BitBake supports | ||
134 | cross-URLs. | ||
135 | It is possible to mirror a Git repository on an HTTP | ||
136 | server as a tarball. | ||
137 | This is what the <filename>git://</filename> mapping in | ||
138 | the previous example does. | ||
139 | </para> | ||
140 | |||
141 | <para> | ||
142 | Since network accesses are slow, BitBake maintains a | ||
143 | cache of files downloaded from the network. | ||
144 | Any source files that are not local (i.e. | ||
145 | downloaded from the Internet) are placed into the download | ||
146 | directory, which is specified by the | ||
147 | <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> | ||
148 | variable. | ||
149 | </para> | ||
150 | |||
151 | <para> | ||
152 | File integrity is of key importance for reproducing builds. | ||
153 | For non-local archive downloads, the fetcher code can verify | ||
154 | SHA-256 and MD5 checksums to ensure the archives have been | ||
155 | downloaded correctly. | ||
156 | You can specify these checksums by using the | ||
157 | <filename>SRC_URI</filename> variable with the appropriate | ||
158 | varflags as follows: | ||
159 | <literallayout class='monospaced'> | ||
160 | SRC_URI[md5sum] = "<replaceable>value</replaceable>" | ||
161 | SRC_URI[sha256sum] = "<replaceable>value</replaceable>" | ||
162 | </literallayout> | ||
163 | You can also specify the checksums as parameters on the | ||
164 | <filename>SRC_URI</filename> as shown below: | ||
165 | <literallayout class='monospaced'> | ||
166 | SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d" | ||
167 | </literallayout> | ||
168 | If multiple URIs exist, you can specify the checksums either | ||
169 | directly as in the previous example, or you can name the URLs. | ||
170 | The following syntax shows how you name the URIs: | ||
171 | <literallayout class='monospaced'> | ||
172 | SRC_URI = "http://example.com/foobar.tar.bz2;name=foo" | ||
173 | SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d | ||
174 | </literallayout> | ||
175 | After a file has been downloaded and has had its checksum checked, | ||
176 | a ".done" stamp is placed in <filename>DL_DIR</filename>. | ||
177 | BitBake uses this stamp during subsequent builds to avoid | ||
178 | downloading or comparing a checksum for the file again. | ||
179 | <note> | ||
180 | It is assumed that local storage is safe from data corruption. | ||
181 | If this were not the case, there would be bigger issues to worry about. | ||
182 | </note> | ||
183 | </para> | ||
184 | |||
185 | <para> | ||
186 | If | ||
187 | <link linkend='var-bb-BB_STRICT_CHECKSUM'><filename>BB_STRICT_CHECKSUM</filename></link> | ||
188 | is set, any download without a checksum triggers an | ||
189 | error message. | ||
190 | The | ||
191 | <link linkend='var-bb-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></link> | ||
192 | variable can be used to make any attempted network access a fatal | ||
193 | error, which is useful for checking that mirrors are complete | ||
194 | as well as other things. | ||
195 | </para> | ||
196 | </section> | ||
197 | |||
198 | <section id='bb-the-unpack'> | ||
199 | <title>The Unpack</title> | ||
200 | |||
201 | <para> | ||
202 | The unpack process usually immediately follows the download. | ||
203 | For all URLs except Git URLs, BitBake uses the common | ||
204 | <filename>unpack</filename> method. | ||
205 | </para> | ||
206 | |||
207 | <para> | ||
208 | A number of parameters exist that you can specify within the | ||
209 | URL to govern the behavior of the unpack stage: | ||
210 | <itemizedlist> | ||
211 | <listitem><para><emphasis>unpack:</emphasis> | ||
212 | Controls whether the URL components are unpacked. | ||
213 | If set to "1", which is the default, the components | ||
214 | are unpacked. | ||
215 | If set to "0", the unpack stage leaves the file alone. | ||
216 | This parameter is useful when you want an archive to be | ||
217 | copied in and not be unpacked. | ||
218 | </para></listitem> | ||
219 | <listitem><para><emphasis>dos:</emphasis> | ||
220 | Applies to <filename>.zip</filename> and | ||
221 | <filename>.jar</filename> files and specifies whether to | ||
222 | use DOS line ending conversion on text files. | ||
223 | </para></listitem> | ||
224 | <listitem><para><emphasis>basepath:</emphasis> | ||
225 | Instructs the unpack stage to strip the specified | ||
226 | directories from the source path when unpacking. | ||
227 | </para></listitem> | ||
228 | <listitem><para><emphasis>subdir:</emphasis> | ||
229 | Unpacks the specific URL to the specified subdirectory | ||
230 | within the root directory. | ||
231 | </para></listitem> | ||
232 | </itemizedlist> | ||
233 | The unpack call automatically decompresses and extracts files | ||
234 | with ".Z", ".z", ".gz", ".xz", ".zip", ".jar", ".ipk", ".rpm". | ||
235 | ".srpm", ".deb" and ".bz2" extensions as well as various combinations | ||
236 | of tarball extensions. | ||
237 | </para> | ||
238 | |||
239 | <para> | ||
240 | As mentioned, the Git fetcher has its own unpack method that | ||
241 | is optimized to work with Git trees. | ||
242 | Basically, this method works by cloning the tree into the final | ||
243 | directory. | ||
244 | The process is completed using references so that there is | ||
245 | only one central copy of the Git metadata needed. | ||
246 | </para> | ||
247 | </section> | ||
248 | |||
249 | <section id='bb-fetchers'> | ||
250 | <title>Fetchers</title> | ||
251 | |||
252 | <para> | ||
253 | As mentioned earlier, the URL prefix determines which | ||
254 | fetcher submodule BitBake uses. | ||
255 | Each submodule can support different URL parameters, | ||
256 | which are described in the following sections. | ||
257 | </para> | ||
258 | |||
259 | <section id='local-file-fetcher'> | ||
260 | <title>Local file fetcher (<filename>file://</filename>)</title> | ||
261 | |||
262 | <para> | ||
263 | This submodule handles URLs that begin with | ||
264 | <filename>file://</filename>. | ||
265 | The filename you specify within the URL can be | ||
266 | either an absolute or relative path to a file. | ||
267 | If the filename is relative, the contents of the | ||
268 | <link linkend='var-bb-FILESPATH'><filename>FILESPATH</filename></link> | ||
269 | variable is used in the same way | ||
270 | <filename>PATH</filename> is used to find executables. | ||
271 | If the file cannot be found, it is assumed that it is available in | ||
272 | <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> | ||
273 | by the time the <filename>download()</filename> method is called. | ||
274 | </para> | ||
275 | |||
276 | <para> | ||
277 | If you specify a directory, the entire directory is | ||
278 | unpacked. | ||
279 | </para> | ||
280 | |||
281 | <para> | ||
282 | Here are a couple of example URLs, the first relative and | ||
283 | the second absolute: | ||
284 | <literallayout class='monospaced'> | ||
285 | SRC_URI = "file://relativefile.patch" | ||
286 | SRC_URI = "file:///Users/ich/very_important_software" | ||
287 | </literallayout> | ||
288 | </para> | ||
289 | </section> | ||
290 | |||
291 | <section id='http-ftp-fetcher'> | ||
292 | <title>HTTP/FTP wget fetcher (<filename>http://</filename>, <filename>ftp://</filename>, <filename>https://</filename>)</title> | ||
293 | |||
294 | <para> | ||
295 | This fetcher obtains files from web and FTP servers. | ||
296 | Internally, the fetcher uses the wget utility. | ||
297 | </para> | ||
298 | |||
299 | <para> | ||
300 | The executable and parameters used are specified by the | ||
301 | <filename>FETCHCMD_wget</filename> variable, which defaults | ||
302 | to sensible values. | ||
303 | The fetcher supports a parameter "downloadfilename" that | ||
304 | allows the name of the downloaded file to be specified. | ||
305 | Specifying the name of the downloaded file is useful | ||
306 | for avoiding collisions in | ||
307 | <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> | ||
308 | when dealing with multiple files that have the same name. | ||
309 | </para> | ||
310 | |||
311 | <para> | ||
312 | Some example URLs are as follows: | ||
313 | <literallayout class='monospaced'> | ||
314 | SRC_URI = "http://oe.handhelds.org/not_there.aac" | ||
315 | SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac" | ||
316 | SRC_URI = "ftp://you@oe.handhelds.org/home/you/secret.plan" | ||
317 | </literallayout> | ||
318 | </para> | ||
319 | <note> | ||
320 | Because URL parameters are delimited by semi-colons, this can | ||
321 | introduce ambiguity when parsing URLs that also contain semi-colons, | ||
322 | for example: | ||
323 | <literallayout class='monospaced'> | ||
324 | SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47" | ||
325 | </literallayout> | ||
326 | Such URLs should should be modified by replacing semi-colons with '&' characters: | ||
327 | <literallayout class='monospaced'> | ||
328 | SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47" | ||
329 | </literallayout> | ||
330 | In most cases this should work. Treating semi-colons and '&' in queries | ||
331 | identically is recommended by the World Wide Web Consortium (W3C). | ||
332 | Note that due to the nature of the URL, you may have to specify the name | ||
333 | of the downloaded file as well: | ||
334 | <literallayout class='monospaced'> | ||
335 | SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;downloadfilename=myfile.bz2" | ||
336 | </literallayout> | ||
337 | </note> | ||
338 | </section> | ||
339 | |||
340 | <section id='cvs-fetcher'> | ||
341 | <title>CVS fetcher (<filename>(cvs://</filename>)</title> | ||
342 | |||
343 | <para> | ||
344 | This submodule handles checking out files from the | ||
345 | CVS version control system. | ||
346 | You can configure it using a number of different variables: | ||
347 | <itemizedlist> | ||
348 | <listitem><para><emphasis><filename>FETCHCMD_cvs</filename>:</emphasis> | ||
349 | The name of the executable to use when running | ||
350 | the <filename>cvs</filename> command. | ||
351 | This name is usually "cvs". | ||
352 | </para></listitem> | ||
353 | <listitem><para><emphasis><filename>SRCDATE</filename>:</emphasis> | ||
354 | The date to use when fetching the CVS source code. | ||
355 | A special value of "now" causes the checkout to | ||
356 | be updated on every build. | ||
357 | </para></listitem> | ||
358 | <listitem><para><emphasis><link linkend='var-bb-CVSDIR'><filename>CVSDIR</filename></link>:</emphasis> | ||
359 | Specifies where a temporary checkout is saved. | ||
360 | The location is often <filename>DL_DIR/cvs</filename>. | ||
361 | </para></listitem> | ||
362 | <listitem><para><emphasis><filename>CVS_PROXY_HOST</filename>:</emphasis> | ||
363 | The name to use as a "proxy=" parameter to the | ||
364 | <filename>cvs</filename> command. | ||
365 | </para></listitem> | ||
366 | <listitem><para><emphasis><filename>CVS_PROXY_PORT</filename>:</emphasis> | ||
367 | The port number to use as a "proxyport=" parameter to | ||
368 | the <filename>cvs</filename> command. | ||
369 | </para></listitem> | ||
370 | </itemizedlist> | ||
371 | As well as the standard username and password URL syntax, | ||
372 | you can also configure the fetcher with various URL parameters: | ||
373 | </para> | ||
374 | |||
375 | <para> | ||
376 | The supported parameters are as follows: | ||
377 | <itemizedlist> | ||
378 | <listitem><para><emphasis>"method":</emphasis> | ||
379 | The protocol over which to communicate with the CVS | ||
380 | server. | ||
381 | By default, this protocol is "pserver". | ||
382 | If "method" is set to "ext", BitBake examines the | ||
383 | "rsh" parameter and sets <filename>CVS_RSH</filename>. | ||
384 | You can use "dir" for local directories. | ||
385 | </para></listitem> | ||
386 | <listitem><para><emphasis>"module":</emphasis> | ||
387 | Specifies the module to check out. | ||
388 | You must supply this parameter. | ||
389 | </para></listitem> | ||
390 | <listitem><para><emphasis>"tag":</emphasis> | ||
391 | Describes which CVS TAG should be used for | ||
392 | the checkout. | ||
393 | By default, the TAG is empty. | ||
394 | </para></listitem> | ||
395 | <listitem><para><emphasis>"date":</emphasis> | ||
396 | Specifies a date. | ||
397 | If no "date" is specified, the | ||
398 | <link linkend='var-bb-SRCDATE'><filename>SRCDATE</filename></link> | ||
399 | of the configuration is used to checkout a specific date. | ||
400 | The special value of "now" causes the checkout to be | ||
401 | updated on every build. | ||
402 | </para></listitem> | ||
403 | <listitem><para><emphasis>"localdir":</emphasis> | ||
404 | Used to rename the module. | ||
405 | Effectively, you are renaming the output directory | ||
406 | to which the module is unpacked. | ||
407 | You are forcing the module into a special | ||
408 | directory relative to | ||
409 | <link linkend='var-bb-CVSDIR'><filename>CVSDIR</filename></link>. | ||
410 | </para></listitem> | ||
411 | <listitem><para><emphasis>"rsh"</emphasis> | ||
412 | Used in conjunction with the "method" parameter. | ||
413 | </para></listitem> | ||
414 | <listitem><para><emphasis>"scmdata":</emphasis> | ||
415 | Causes the CVS metadata to be maintained in the tarball | ||
416 | the fetcher creates when set to "keep". | ||
417 | The tarball is expanded into the work directory. | ||
418 | By default, the CVS metadata is removed. | ||
419 | </para></listitem> | ||
420 | <listitem><para><emphasis>"fullpath":</emphasis> | ||
421 | Controls whether the resulting checkout is at the | ||
422 | module level, which is the default, or is at deeper | ||
423 | paths. | ||
424 | </para></listitem> | ||
425 | <listitem><para><emphasis>"norecurse":</emphasis> | ||
426 | Causes the fetcher to only checkout the specified | ||
427 | directory with no recurse into any subdirectories. | ||
428 | </para></listitem> | ||
429 | <listitem><para><emphasis>"port":</emphasis> | ||
430 | The port to which the CVS server connects. | ||
431 | </para></listitem> | ||
432 | </itemizedlist> | ||
433 | Some example URLs are as follows: | ||
434 | <literallayout class='monospaced'> | ||
435 | SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext" | ||
436 | SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat" | ||
437 | </literallayout> | ||
438 | </para> | ||
439 | </section> | ||
440 | |||
441 | <section id='svn-fetcher'> | ||
442 | <title>Subversion (SVN) Fetcher (<filename>svn://</filename>)</title> | ||
443 | |||
444 | <para> | ||
445 | This fetcher submodule fetches code from the | ||
446 | Subversion source control system. | ||
447 | The executable used is specified by | ||
448 | <filename>FETCHCMD_svn</filename>, which defaults | ||
449 | to "svn". | ||
450 | The fetcher's temporary working directory is set by | ||
451 | <link linkend='var-bb-SVNDIR'><filename>SVNDIR</filename></link>, | ||
452 | which is usually <filename>DL_DIR/svn</filename>. | ||
453 | </para> | ||
454 | |||
455 | <para> | ||
456 | The supported parameters are as follows: | ||
457 | <itemizedlist> | ||
458 | <listitem><para><emphasis>"module":</emphasis> | ||
459 | The name of the svn module to checkout. | ||
460 | You must provide this parameter. | ||
461 | You can think of this parameter as the top-level | ||
462 | directory of the repository data you want. | ||
463 | </para></listitem> | ||
464 | <listitem><para><emphasis>"path_spec":</emphasis> | ||
465 | A specific directory in which to checkout the | ||
466 | specified svn module. | ||
467 | </para></listitem> | ||
468 | <listitem><para><emphasis>"protocol":</emphasis> | ||
469 | The protocol to use, which defaults to "svn". | ||
470 | If "protocol" is set to "svn+ssh", the "ssh" | ||
471 | parameter is also used. | ||
472 | </para></listitem> | ||
473 | <listitem><para><emphasis>"rev":</emphasis> | ||
474 | The revision of the source code to checkout. | ||
475 | </para></listitem> | ||
476 | <listitem><para><emphasis>"scmdata":</emphasis> | ||
477 | Causes the “.svn†directories to be available during | ||
478 | compile-time when set to "keep". | ||
479 | By default, these directories are removed. | ||
480 | </para></listitem> | ||
481 | <listitem><para><emphasis>"ssh":</emphasis> | ||
482 | An optional parameter used when "protocol" is set | ||
483 | to "svn+ssh". | ||
484 | You can use this parameter to specify the ssh | ||
485 | program used by svn. | ||
486 | </para></listitem> | ||
487 | <listitem><para><emphasis>"transportuser":</emphasis> | ||
488 | When required, sets the username for the transport. | ||
489 | By default, this parameter is empty. | ||
490 | The transport username is different than the username | ||
491 | used in the main URL, which is passed to the subversion | ||
492 | command. | ||
493 | </para></listitem> | ||
494 | </itemizedlist> | ||
495 | Following are three examples using svn: | ||
496 | <literallayout class='monospaced'> | ||
497 | SRC_URI = "svn://myrepos/proj1;module=vip;protocol=http;rev=667" | ||
498 | SRC_URI = "svn://myrepos/proj1;module=opie;protocol=svn+ssh" | ||
499 | SRC_URI = "svn://myrepos/proj1;module=trunk;protocol=http;path_spec=${MY_DIR}/proj1" | ||
500 | </literallayout> | ||
501 | </para> | ||
502 | </section> | ||
503 | |||
504 | <section id='git-fetcher'> | ||
505 | <title>Git Fetcher (<filename>git://</filename>)</title> | ||
506 | |||
507 | <para> | ||
508 | This fetcher submodule fetches code from the Git | ||
509 | source control system. | ||
510 | The fetcher works by creating a bare clone of the | ||
511 | remote into | ||
512 | <link linkend='var-bb-GITDIR'><filename>GITDIR</filename></link>, | ||
513 | which is usually <filename>DL_DIR/git2</filename>. | ||
514 | This bare clone is then cloned into the work directory during the | ||
515 | unpack stage when a specific tree is checked out. | ||
516 | This is done using alternates and by reference to | ||
517 | minimize the amount of duplicate data on the disk and | ||
518 | make the unpack process fast. | ||
519 | The executable used can be set with | ||
520 | <filename>FETCHCMD_git</filename>. | ||
521 | </para> | ||
522 | |||
523 | <para> | ||
524 | This fetcher supports the following parameters: | ||
525 | <itemizedlist> | ||
526 | <listitem><para><emphasis>"protocol":</emphasis> | ||
527 | The protocol used to fetch the files. | ||
528 | The default is "git" when a hostname is set. | ||
529 | If a hostname is not set, the Git protocol is "file". | ||
530 | You can also use "http", "https", "ssh" and "rsync". | ||
531 | </para></listitem> | ||
532 | <listitem><para><emphasis>"nocheckout":</emphasis> | ||
533 | Tells the fetcher to not checkout source code when | ||
534 | unpacking when set to "1". | ||
535 | Set this option for the URL where there is a custom | ||
536 | routine to checkout code. | ||
537 | The default is "0". | ||
538 | </para></listitem> | ||
539 | <listitem><para><emphasis>"rebaseable":</emphasis> | ||
540 | Indicates that the upstream Git repository can be rebased. | ||
541 | You should set this parameter to "1" if | ||
542 | revisions can become detached from branches. | ||
543 | In this case, the source mirror tarball is done per | ||
544 | revision, which has a loss of efficiency. | ||
545 | Rebasing the upstream Git repository could cause the | ||
546 | current revision to disappear from the upstream repository. | ||
547 | This option reminds the fetcher to preserve the local cache | ||
548 | carefully for future use. | ||
549 | The default value for this parameter is "0". | ||
550 | </para></listitem> | ||
551 | <listitem><para><emphasis>"nobranch":</emphasis> | ||
552 | Tells the fetcher to not check the SHA validation | ||
553 | for the branch when set to "1". | ||
554 | The default is "0". | ||
555 | Set this option for the recipe that refers to | ||
556 | the commit that is valid for a tag instead of | ||
557 | the branch. | ||
558 | </para></listitem> | ||
559 | <listitem><para><emphasis>"bareclone":</emphasis> | ||
560 | Tells the fetcher to clone a bare clone into the | ||
561 | destination directory without checking out a working tree. | ||
562 | Only the raw Git metadata is provided. | ||
563 | This parameter implies the "nocheckout" parameter as well. | ||
564 | </para></listitem> | ||
565 | <listitem><para><emphasis>"branch":</emphasis> | ||
566 | The branch(es) of the Git tree to clone. | ||
567 | If unset, this is assumed to be "master". | ||
568 | The number of branch parameters much match the number of | ||
569 | name parameters. | ||
570 | </para></listitem> | ||
571 | <listitem><para><emphasis>"rev":</emphasis> | ||
572 | The revision to use for the checkout. | ||
573 | The default is "master". | ||
574 | </para></listitem> | ||
575 | <listitem><para><emphasis>"tag":</emphasis> | ||
576 | Specifies a tag to use for the checkout. | ||
577 | To correctly resolve tags, BitBake must access the | ||
578 | network. | ||
579 | For that reason, tags are often not used. | ||
580 | As far as Git is concerned, the "tag" parameter behaves | ||
581 | effectively the same as the "rev" parameter. | ||
582 | </para></listitem> | ||
583 | <listitem><para><emphasis>"subpath":</emphasis> | ||
584 | Limits the checkout to a specific subpath of the tree. | ||
585 | By default, the whole tree is checked out. | ||
586 | </para></listitem> | ||
587 | <listitem><para><emphasis>"destsuffix":</emphasis> | ||
588 | The name of the path in which to place the checkout. | ||
589 | By default, the path is <filename>git/</filename>. | ||
590 | </para></listitem> | ||
591 | <listitem><para><emphasis>"usehead":</emphasis> | ||
592 | Enables local <filename>git://</filename> URLs to use the | ||
593 | current branch HEAD as the revision for use with | ||
594 | <filename>AUTOREV</filename>. | ||
595 | The "usehead" parameter implies no branch and only works | ||
596 | when the transfer protocol is | ||
597 | <filename>file://</filename>. | ||
598 | </para></listitem> | ||
599 | </itemizedlist> | ||
600 | Here are some example URLs: | ||
601 | <literallayout class='monospaced'> | ||
602 | SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1" | ||
603 | SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http" | ||
604 | </literallayout> | ||
605 | </para> | ||
606 | </section> | ||
607 | |||
608 | <section id='gitsm-fetcher'> | ||
609 | <title>Git Submodule Fetcher (<filename>gitsm://</filename>)</title> | ||
610 | |||
611 | <para> | ||
612 | This fetcher submodule inherits from the | ||
613 | <link linkend='git-fetcher'>Git fetcher</link> and extends | ||
614 | that fetcher's behavior by fetching a repository's submodules. | ||
615 | <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link> | ||
616 | is passed to the Git fetcher as described in the | ||
617 | "<link linkend='git-fetcher'>Git Fetcher (<filename>git://</filename>)</link>" | ||
618 | section. | ||
619 | <note> | ||
620 | <title>Notes and Warnings</title> | ||
621 | <para> | ||
622 | You must clean a recipe when switching between | ||
623 | '<filename>git://</filename>' and | ||
624 | '<filename>gitsm://</filename>' URLs. | ||
625 | </para> | ||
626 | |||
627 | <para> | ||
628 | The Git Submodules fetcher is not a complete fetcher | ||
629 | implementation. | ||
630 | The fetcher has known issues where it does not use the | ||
631 | normal source mirroring infrastructure properly. Further, | ||
632 | the submodule sources it fetches are not visible to the | ||
633 | licensing and source archiving infrastructures. | ||
634 | </para> | ||
635 | </note> | ||
636 | </para> | ||
637 | </section> | ||
638 | |||
639 | <section id='clearcase-fetcher'> | ||
640 | <title>ClearCase Fetcher (<filename>ccrc://</filename>)</title> | ||
641 | |||
642 | <para> | ||
643 | This fetcher submodule fetches code from a | ||
644 | <ulink url='http://en.wikipedia.org/wiki/Rational_ClearCase'>ClearCase</ulink> | ||
645 | repository. | ||
646 | </para> | ||
647 | |||
648 | <para> | ||
649 | To use this fetcher, make sure your recipe has proper | ||
650 | <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>, | ||
651 | <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link>, and | ||
652 | <link linkend='var-bb-PV'><filename>PV</filename></link> settings. | ||
653 | Here is an example: | ||
654 | <literallayout class='monospaced'> | ||
655 | SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module" | ||
656 | SRCREV = "EXAMPLE_CLEARCASE_TAG" | ||
657 | PV = "${@d.getVar("SRCREV", False).replace("/", "+")}" | ||
658 | </literallayout> | ||
659 | The fetcher uses the <filename>rcleartool</filename> or | ||
660 | <filename>cleartool</filename> remote client, depending on | ||
661 | which one is available. | ||
662 | </para> | ||
663 | |||
664 | <para> | ||
665 | Following are options for the <filename>SRC_URI</filename> | ||
666 | statement: | ||
667 | <itemizedlist> | ||
668 | <listitem><para><emphasis><filename>vob</filename></emphasis>: | ||
669 | The name, which must include the | ||
670 | prepending "/" character, of the ClearCase VOB. | ||
671 | This option is required. | ||
672 | </para></listitem> | ||
673 | <listitem><para><emphasis><filename>module</filename></emphasis>: | ||
674 | The module, which must include the | ||
675 | prepending "/" character, in the selected VOB. | ||
676 | <note> | ||
677 | The <filename>module</filename> and <filename>vob</filename> | ||
678 | options are combined to create the <filename>load</filename> rule in | ||
679 | the view config spec. | ||
680 | As an example, consider the <filename>vob</filename> and | ||
681 | <filename>module</filename> values from the | ||
682 | <filename>SRC_URI</filename> statement at the start of this section. | ||
683 | Combining those values results in the following: | ||
684 | <literallayout class='monospaced'> | ||
685 | load /example_vob/example_module | ||
686 | </literallayout> | ||
687 | </note> | ||
688 | </para></listitem> | ||
689 | <listitem><para><emphasis><filename>proto</filename></emphasis>: | ||
690 | The protocol, which can be either <filename>http</filename> or | ||
691 | <filename>https</filename>. | ||
692 | </para></listitem> | ||
693 | </itemizedlist> | ||
694 | </para> | ||
695 | |||
696 | <para> | ||
697 | By default, the fetcher creates a configuration specification. | ||
698 | If you want this specification written to an area other than the default, | ||
699 | use the <filename>CCASE_CUSTOM_CONFIG_SPEC</filename> variable | ||
700 | in your recipe to define where the specification is written. | ||
701 | <note> | ||
702 | the <filename>SRCREV</filename> loses its functionality if you | ||
703 | specify this variable. | ||
704 | However, <filename>SRCREV</filename> is still used to label the | ||
705 | archive after a fetch even though it does not define what is | ||
706 | fetched. | ||
707 | </note> | ||
708 | </para> | ||
709 | |||
710 | <para> | ||
711 | Here are a couple of other behaviors worth mentioning: | ||
712 | <itemizedlist> | ||
713 | <listitem><para> | ||
714 | When using <filename>cleartool</filename>, the login of | ||
715 | <filename>cleartool</filename> is handled by the system. | ||
716 | The login require no special steps. | ||
717 | </para></listitem> | ||
718 | <listitem><para> | ||
719 | In order to use <filename>rcleartool</filename> with authenticated | ||
720 | users, an "rcleartool login" is necessary before using the fetcher. | ||
721 | </para></listitem> | ||
722 | </itemizedlist> | ||
723 | </para> | ||
724 | </section> | ||
725 | |||
726 | <section id='perforce-fetcher'> | ||
727 | <title>Perforce Fetcher (<filename>p4://</filename>)</title> | ||
728 | |||
729 | <para> | ||
730 | This fetcher submodule fetches code from the | ||
731 | <ulink url='https://www.perforce.com/'>Perforce</ulink> | ||
732 | source control system. | ||
733 | The executable used is specified by | ||
734 | <filename>FETCHCMD_p4</filename>, which defaults | ||
735 | to "p4". | ||
736 | The fetcher's temporary working directory is set by | ||
737 | <link linkend='var-bb-P4DIR'><filename>P4DIR</filename></link>, | ||
738 | which defaults to "DL_DIR/p4". | ||
739 | The fetcher does not make use of a perforce client, instead it | ||
740 | relies on <filename>p4 files</filename> to retrieve a list of | ||
741 | files and <filename>p4 print</filename> to transfer the content | ||
742 | of those files locally. | ||
743 | </para> | ||
744 | |||
745 | <para> | ||
746 | To use this fetcher, make sure your recipe has proper | ||
747 | <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>, | ||
748 | <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link>, and | ||
749 | <link linkend='var-bb-PV'><filename>PV</filename></link> values. | ||
750 | The p4 executable is able to use the config file defined by your | ||
751 | system's <filename>P4CONFIG</filename> environment variable in | ||
752 | order to define the Perforce server URL and port, username, and | ||
753 | password if you do not wish to keep those values in a recipe | ||
754 | itself. | ||
755 | If you choose not to use <filename>P4CONFIG</filename>, | ||
756 | or to explicitly set variables that <filename>P4CONFIG</filename> | ||
757 | can contain, you can specify the <filename>P4PORT</filename> value, | ||
758 | which is the server's URL and port number, and you can | ||
759 | specify a username and password directly in your recipe within | ||
760 | <filename>SRC_URI</filename>. | ||
761 | </para> | ||
762 | |||
763 | <para> | ||
764 | Here is an example that relies on <filename>P4CONFIG</filename> | ||
765 | to specify the server URL and port, username, and password, and | ||
766 | fetches the Head Revision: | ||
767 | <literallayout class='monospaced'> | ||
768 | SRC_URI = "p4://example-depot/main/source/..." | ||
769 | SRCREV = "${AUTOREV}" | ||
770 | PV = "p4-${SRCPV}" | ||
771 | S = "${WORKDIR}/p4" | ||
772 | </literallayout> | ||
773 | </para> | ||
774 | |||
775 | <para> | ||
776 | Here is an example that specifies the server URL and port, | ||
777 | username, and password, and fetches a Revision based on a Label: | ||
778 | <literallayout class='monospaced'> | ||
779 | P4PORT = "tcp:p4server.example.net:1666" | ||
780 | SRC_URI = "p4://user:passwd@example-depot/main/source/..." | ||
781 | SRCREV = "release-1.0" | ||
782 | PV = "p4-${SRCPV}" | ||
783 | S = "${WORKDIR}/p4" | ||
784 | </literallayout> | ||
785 | <note> | ||
786 | You should always set <filename>S</filename> | ||
787 | to <filename>"${WORKDIR}/p4"</filename> in your recipe. | ||
788 | </note> | ||
789 | </para> | ||
790 | |||
791 | <para> | ||
792 | By default, the fetcher strips the depot location from the | ||
793 | local file paths. In the above example, the content of | ||
794 | <filename>example-depot/main/source/</filename> | ||
795 | will be placed in <filename>${WORKDIR}/p4</filename>. | ||
796 | For situations where preserving parts of the remote depot paths | ||
797 | locally is desirable, the fetcher supports two parameters: | ||
798 | |||
799 | <itemizedlist> | ||
800 | <listitem><para> | ||
801 | <emphasis>"module":</emphasis> | ||
802 | The top-level depot location or directory to fetch. The | ||
803 | value of this parameter can also point to a single file | ||
804 | within the depot, in which case the local file path will | ||
805 | include the module path. | ||
806 | </para></listitem> | ||
807 | <listitem><para> | ||
808 | <emphasis>"remotepath":</emphasis> | ||
809 | When used with the value "<filename>keep</filename>", | ||
810 | the fetcher will mirror the full depot paths locally | ||
811 | for the specified location, even in combination with | ||
812 | the <filename>module</filename> parameter. | ||
813 | </para></listitem> | ||
814 | </itemizedlist> | ||
815 | </para> | ||
816 | |||
817 | <para> | ||
818 | Here is an example use of the the <filename>module</filename> | ||
819 | parameter: | ||
820 | |||
821 | <literallayout class='monospaced'> | ||
822 | SRC_URI = "p4://user:passwd@example-depot/main;module=source/..." | ||
823 | </literallayout> | ||
824 | |||
825 | In this case, the content of the top-level directory | ||
826 | <filename>source/</filename> will be fetched to | ||
827 | <filename>${P4DIR}</filename>, including the directory itself. | ||
828 | The top-level directory will be accesible at | ||
829 | <filename>${P4DIR}/source/</filename>. | ||
830 | </para> | ||
831 | |||
832 | <para> | ||
833 | Here is an example use of the the <filename>remotepath</filename> | ||
834 | parameter: | ||
835 | |||
836 | <literallayout class='monospaced'> | ||
837 | SRC_URI = "p4://user:passwd@example-depot/main;module=source/...;remotepath=keep" | ||
838 | </literallayout> | ||
839 | |||
840 | In this case, the content of the top-level directory | ||
841 | <filename>source/</filename> will be fetched to | ||
842 | <filename>${P4DIR}</filename>, but the complete depot paths will | ||
843 | be mirrored locally. The top-level directory will be accessible | ||
844 | at <filename>${P4DIR}/example-depot/main/source/</filename>. | ||
845 | </para> | ||
846 | </section> | ||
847 | |||
848 | <section id='repo-fetcher'> | ||
849 | <title>Repo Fetcher (<filename>repo://</filename>)</title> | ||
850 | |||
851 | <para> | ||
852 | This fetcher submodule fetches code from | ||
853 | <filename>google-repo</filename> source control system. | ||
854 | The fetcher works by initiating and syncing sources of the | ||
855 | repository into | ||
856 | <link linkend='var-bb-REPODIR'><filename>REPODIR</filename></link>, | ||
857 | which is usually | ||
858 | <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link><filename>/repo</filename>. | ||
859 | </para> | ||
860 | |||
861 | <para> | ||
862 | This fetcher supports the following parameters: | ||
863 | <itemizedlist> | ||
864 | <listitem><para> | ||
865 | <emphasis>"protocol":</emphasis> | ||
866 | Protocol to fetch the repository manifest (default: git). | ||
867 | </para></listitem> | ||
868 | <listitem><para> | ||
869 | <emphasis>"branch":</emphasis> | ||
870 | Branch or tag of repository to get (default: master). | ||
871 | </para></listitem> | ||
872 | <listitem><para> | ||
873 | <emphasis>"manifest":</emphasis> | ||
874 | Name of the manifest file (default: <filename>default.xml</filename>). | ||
875 | </para></listitem> | ||
876 | </itemizedlist> | ||
877 | Here are some example URLs: | ||
878 | <literallayout class='monospaced'> | ||
879 | SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml" | ||
880 | SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml" | ||
881 | </literallayout> | ||
882 | </para> | ||
883 | </section> | ||
884 | |||
885 | <section id='other-fetchers'> | ||
886 | <title>Other Fetchers</title> | ||
887 | |||
888 | <para> | ||
889 | Fetch submodules also exist for the following: | ||
890 | <itemizedlist> | ||
891 | <listitem><para> | ||
892 | Bazaar (<filename>bzr://</filename>) | ||
893 | </para></listitem> | ||
894 | <listitem><para> | ||
895 | Mercurial (<filename>hg://</filename>) | ||
896 | </para></listitem> | ||
897 | <listitem><para> | ||
898 | npm (<filename>npm://</filename>) | ||
899 | </para></listitem> | ||
900 | <listitem><para> | ||
901 | OSC (<filename>osc://</filename>) | ||
902 | </para></listitem> | ||
903 | <listitem><para> | ||
904 | Secure FTP (<filename>sftp://</filename>) | ||
905 | </para></listitem> | ||
906 | <listitem><para> | ||
907 | Secure Shell (<filename>ssh://</filename>) | ||
908 | </para></listitem> | ||
909 | <listitem><para> | ||
910 | Trees using Git Annex (<filename>gitannex://</filename>) | ||
911 | </para></listitem> | ||
912 | </itemizedlist> | ||
913 | No documentation currently exists for these lesser used | ||
914 | fetcher submodules. | ||
915 | However, you might find the code helpful and readable. | ||
916 | </para> | ||
917 | </section> | ||
918 | </section> | ||
919 | |||
920 | <section id='auto-revisions'> | ||
921 | <title>Auto Revisions</title> | ||
922 | |||
923 | <para> | ||
924 | We need to document <filename>AUTOREV</filename> and | ||
925 | <filename>SRCREV_FORMAT</filename> here. | ||
926 | </para> | ||
927 | </section> | ||
928 | </chapter> | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml deleted file mode 100644 index 11eb36aaf8..0000000000 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml +++ /dev/null | |||
@@ -1,513 +0,0 @@ | |||
1 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" | ||
2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> | ||
3 | |||
4 | <appendix id='hello-world-example'> | ||
5 | <title>Hello World Example</title> | ||
6 | |||
7 | <section id='bitbake-hello-world'> | ||
8 | <title>BitBake Hello World</title> | ||
9 | |||
10 | <para> | ||
11 | The simplest example commonly used to demonstrate any new | ||
12 | programming language or tool is the | ||
13 | "<ulink url="http://en.wikipedia.org/wiki/Hello_world_program">Hello World</ulink>" | ||
14 | example. | ||
15 | This appendix demonstrates, in tutorial form, Hello | ||
16 | World within the context of BitBake. | ||
17 | The tutorial describes how to create a new project | ||
18 | and the applicable metadata files necessary to allow | ||
19 | BitBake to build it. | ||
20 | </para> | ||
21 | </section> | ||
22 | |||
23 | <section id='example-obtaining-bitbake'> | ||
24 | <title>Obtaining BitBake</title> | ||
25 | |||
26 | <para> | ||
27 | See the | ||
28 | "<link linkend='obtaining-bitbake'>Obtaining BitBake</link>" | ||
29 | section for information on how to obtain BitBake. | ||
30 | Once you have the source code on your machine, the BitBake directory | ||
31 | appears as follows: | ||
32 | <literallayout class='monospaced'> | ||
33 | $ ls -al | ||
34 | total 100 | ||
35 | drwxrwxr-x. 9 wmat wmat 4096 Jan 31 13:44 . | ||
36 | drwxrwxr-x. 3 wmat wmat 4096 Feb 4 10:45 .. | ||
37 | -rw-rw-r--. 1 wmat wmat 365 Nov 26 04:55 AUTHORS | ||
38 | drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 bin | ||
39 | drwxrwxr-x. 4 wmat wmat 4096 Jan 31 13:44 build | ||
40 | -rw-rw-r--. 1 wmat wmat 16501 Nov 26 04:55 ChangeLog | ||
41 | drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 classes | ||
42 | drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 conf | ||
43 | drwxrwxr-x. 3 wmat wmat 4096 Nov 26 04:55 contrib | ||
44 | -rw-rw-r--. 1 wmat wmat 17987 Nov 26 04:55 COPYING | ||
45 | drwxrwxr-x. 3 wmat wmat 4096 Nov 26 04:55 doc | ||
46 | -rw-rw-r--. 1 wmat wmat 69 Nov 26 04:55 .gitignore | ||
47 | -rw-rw-r--. 1 wmat wmat 849 Nov 26 04:55 HEADER | ||
48 | drwxrwxr-x. 5 wmat wmat 4096 Jan 31 13:44 lib | ||
49 | -rw-rw-r--. 1 wmat wmat 195 Nov 26 04:55 MANIFEST.in | ||
50 | -rw-rw-r--. 1 wmat wmat 2887 Nov 26 04:55 TODO | ||
51 | </literallayout> | ||
52 | </para> | ||
53 | |||
54 | <para> | ||
55 | At this point, you should have BitBake cloned to | ||
56 | a directory that matches the previous listing except for | ||
57 | dates and user names. | ||
58 | </para> | ||
59 | </section> | ||
60 | |||
61 | <section id='setting-up-the-bitbake-environment'> | ||
62 | <title>Setting Up the BitBake Environment</title> | ||
63 | |||
64 | <para> | ||
65 | First, you need to be sure that you can run BitBake. | ||
66 | Set your working directory to where your local BitBake | ||
67 | files are and run the following command: | ||
68 | <literallayout class='monospaced'> | ||
69 | $ ./bin/bitbake --version | ||
70 | BitBake Build Tool Core version 1.23.0, bitbake version 1.23.0 | ||
71 | </literallayout> | ||
72 | The console output tells you what version you are running. | ||
73 | </para> | ||
74 | |||
75 | <para> | ||
76 | The recommended method to run BitBake is from a directory of your | ||
77 | choice. | ||
78 | To be able to run BitBake from any directory, you need to add the | ||
79 | executable binary to your binary to your shell's environment | ||
80 | <filename>PATH</filename> variable. | ||
81 | First, look at your current <filename>PATH</filename> variable | ||
82 | by entering the following: | ||
83 | <literallayout class='monospaced'> | ||
84 | $ echo $PATH | ||
85 | </literallayout> | ||
86 | Next, add the directory location for the BitBake binary to the | ||
87 | <filename>PATH</filename>. | ||
88 | Here is an example that adds the | ||
89 | <filename>/home/scott-lenovo/bitbake/bin</filename> directory | ||
90 | to the front of the <filename>PATH</filename> variable: | ||
91 | <literallayout class='monospaced'> | ||
92 | $ export PATH=/home/scott-lenovo/bitbake/bin:$PATH | ||
93 | </literallayout> | ||
94 | You should now be able to enter the <filename>bitbake</filename> | ||
95 | command from the command line while working from any directory. | ||
96 | </para> | ||
97 | </section> | ||
98 | |||
99 | <section id='the-hello-world-example'> | ||
100 | <title>The Hello World Example</title> | ||
101 | |||
102 | <para> | ||
103 | The overall goal of this exercise is to build a | ||
104 | complete "Hello World" example utilizing task and layer | ||
105 | concepts. | ||
106 | Because this is how modern projects such as OpenEmbedded and | ||
107 | the Yocto Project utilize BitBake, the example | ||
108 | provides an excellent starting point for understanding | ||
109 | BitBake. | ||
110 | </para> | ||
111 | |||
112 | <para> | ||
113 | To help you understand how to use BitBake to build targets, | ||
114 | the example starts with nothing but the <filename>bitbake</filename> | ||
115 | command, which causes BitBake to fail and report problems. | ||
116 | The example progresses by adding pieces to the build to | ||
117 | eventually conclude with a working, minimal "Hello World" | ||
118 | example. | ||
119 | </para> | ||
120 | |||
121 | <para> | ||
122 | While every attempt is made to explain what is happening during | ||
123 | the example, the descriptions cannot cover everything. | ||
124 | You can find further information throughout this manual. | ||
125 | Also, you can actively participate in the | ||
126 | <ulink url='http://lists.openembedded.org/mailman/listinfo/bitbake-devel'></ulink> | ||
127 | discussion mailing list about the BitBake build tool. | ||
128 | </para> | ||
129 | |||
130 | <note> | ||
131 | This example was inspired by and drew heavily from | ||
132 | <ulink url="http://www.mail-archive.com/yocto@yoctoproject.org/msg09379.html">Mailing List post - The BitBake equivalent of "Hello, World!"</ulink>. | ||
133 | </note> | ||
134 | |||
135 | <para> | ||
136 | As stated earlier, the goal of this example | ||
137 | is to eventually compile "Hello World". | ||
138 | However, it is unknown what BitBake needs and what you have | ||
139 | to provide in order to achieve that goal. | ||
140 | Recall that BitBake utilizes three types of metadata files: | ||
141 | <link linkend='configuration-files'>Configuration Files</link>, | ||
142 | <link linkend='classes'>Classes</link>, and | ||
143 | <link linkend='recipes'>Recipes</link>. | ||
144 | But where do they go? | ||
145 | How does BitBake find them? | ||
146 | BitBake's error messaging helps you answer these types of questions | ||
147 | and helps you better understand exactly what is going on. | ||
148 | </para> | ||
149 | |||
150 | <para> | ||
151 | Following is the complete "Hello World" example. | ||
152 | </para> | ||
153 | |||
154 | <orderedlist> | ||
155 | <listitem><para><emphasis>Create a Project Directory:</emphasis> | ||
156 | First, set up a directory for the "Hello World" project. | ||
157 | Here is how you can do so in your home directory: | ||
158 | <literallayout class='monospaced'> | ||
159 | $ mkdir ~/hello | ||
160 | $ cd ~/hello | ||
161 | </literallayout> | ||
162 | This is the directory that BitBake will use to do all of | ||
163 | its work. | ||
164 | You can use this directory to keep all the metafiles needed | ||
165 | by BitBake. | ||
166 | Having a project directory is a good way to isolate your | ||
167 | project. | ||
168 | </para></listitem> | ||
169 | <listitem><para><emphasis>Run BitBake:</emphasis> | ||
170 | At this point, you have nothing but a project directory. | ||
171 | Run the <filename>bitbake</filename> command and see what | ||
172 | it does: | ||
173 | <literallayout class='monospaced'> | ||
174 | $ bitbake | ||
175 | The BBPATH variable is not set and bitbake did not | ||
176 | find a conf/bblayers.conf file in the expected location. | ||
177 | Maybe you accidentally invoked bitbake from the wrong directory? | ||
178 | DEBUG: Removed the following variables from the environment: | ||
179 | GNOME_DESKTOP_SESSION_ID, XDG_CURRENT_DESKTOP, | ||
180 | GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG, no_proxy, | ||
181 | XDG_SESSION_PATH, XAUTHORITY, SESSION_MANAGER, SHLVL, | ||
182 | MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, WINDOWID, EDITOR, | ||
183 | GPG_AGENT_INFO, SSH_AUTH_SOCK, GDMSESSION, GNOME_KEYRING_PID, | ||
184 | XDG_SEAT_PATH, XDG_CONFIG_DIRS, LESSOPEN, DBUS_SESSION_BUS_ADDRESS, | ||
185 | _, XDG_SESSION_COOKIE, DESKTOP_SESSION, LESSCLOSE, DEFAULTS_PATH, | ||
186 | UBUNTU_MENUPROXY, OLDPWD, XDG_DATA_DIRS, COLORTERM, LS_COLORS | ||
187 | </literallayout> | ||
188 | The majority of this output is specific to environment variables | ||
189 | that are not directly relevant to BitBake. | ||
190 | However, the very first message regarding the | ||
191 | <filename>BBPATH</filename> variable and the | ||
192 | <filename>conf/bblayers.conf</filename> file | ||
193 | is relevant.</para> | ||
194 | <para> | ||
195 | When you run BitBake, it begins looking for metadata files. | ||
196 | The | ||
197 | <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link> | ||
198 | variable is what tells BitBake where to look for those files. | ||
199 | <filename>BBPATH</filename> is not set and you need to set it. | ||
200 | Without <filename>BBPATH</filename>, BitBake cannot | ||
201 | find any configuration files (<filename>.conf</filename>) | ||
202 | or recipe files (<filename>.bb</filename>) at all. | ||
203 | BitBake also cannot find the <filename>bitbake.conf</filename> | ||
204 | file. | ||
205 | </para></listitem> | ||
206 | <listitem><para><emphasis>Setting <filename>BBPATH</filename>:</emphasis> | ||
207 | For this example, you can set <filename>BBPATH</filename> | ||
208 | in the same manner that you set <filename>PATH</filename> | ||
209 | earlier in the appendix. | ||
210 | You should realize, though, that it is much more flexible to set the | ||
211 | <filename>BBPATH</filename> variable up in a configuration | ||
212 | file for each project.</para> | ||
213 | <para>From your shell, enter the following commands to set and | ||
214 | export the <filename>BBPATH</filename> variable: | ||
215 | <literallayout class='monospaced'> | ||
216 | $ BBPATH="<replaceable>projectdirectory</replaceable>" | ||
217 | $ export BBPATH | ||
218 | </literallayout> | ||
219 | Use your actual project directory in the command. | ||
220 | BitBake uses that directory to find the metadata it needs for | ||
221 | your project. | ||
222 | <note> | ||
223 | When specifying your project directory, do not use the | ||
224 | tilde ("~") character as BitBake does not expand that character | ||
225 | as the shell would. | ||
226 | </note> | ||
227 | </para></listitem> | ||
228 | <listitem><para><emphasis>Run BitBake:</emphasis> | ||
229 | Now that you have <filename>BBPATH</filename> defined, run | ||
230 | the <filename>bitbake</filename> command again: | ||
231 | <literallayout class='monospaced'> | ||
232 | $ bitbake | ||
233 | ERROR: Traceback (most recent call last): | ||
234 | File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped | ||
235 | return func(fn, *args) | ||
236 | File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 173, in parse_config_file | ||
237 | return bb.parse.handle(fn, data, include) | ||
238 | File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 99, in handle | ||
239 | return h['handle'](fn, data, include) | ||
240 | File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 120, in handle | ||
241 | abs_fn = resolve_file(fn, data) | ||
242 | File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 117, in resolve_file | ||
243 | raise IOError("file %s not found in %s" % (fn, bbpath)) | ||
244 | IOError: file conf/bitbake.conf not found in /home/scott-lenovo/hello | ||
245 | |||
246 | ERROR: Unable to parse conf/bitbake.conf: file conf/bitbake.conf not found in /home/scott-lenovo/hello | ||
247 | </literallayout> | ||
248 | This sample output shows that BitBake could not find the | ||
249 | <filename>conf/bitbake.conf</filename> file in the project | ||
250 | directory. | ||
251 | This file is the first thing BitBake must find in order | ||
252 | to build a target. | ||
253 | And, since the project directory for this example is | ||
254 | empty, you need to provide a <filename>conf/bitbake.conf</filename> | ||
255 | file. | ||
256 | </para></listitem> | ||
257 | <listitem><para><emphasis>Creating <filename>conf/bitbake.conf</filename>:</emphasis> | ||
258 | The <filename>conf/bitbake.conf</filename> includes a number of | ||
259 | configuration variables BitBake uses for metadata and recipe | ||
260 | files. | ||
261 | For this example, you need to create the file in your project directory | ||
262 | and define some key BitBake variables. | ||
263 | For more information on the <filename>bitbake.conf</filename> file, | ||
264 | see | ||
265 | <ulink url='http://git.openembedded.org/bitbake/tree/conf/bitbake.conf'></ulink>. | ||
266 | </para> | ||
267 | <para>Use the following commands to create the <filename>conf</filename> | ||
268 | directory in the project directory: | ||
269 | <literallayout class='monospaced'> | ||
270 | $ mkdir conf | ||
271 | </literallayout> | ||
272 | From within the <filename>conf</filename> directory, use | ||
273 | some editor to create the <filename>bitbake.conf</filename> | ||
274 | so that it contains the following: | ||
275 | <literallayout class='monospaced'> | ||
276 | <link linkend='var-bb-PN'>PN</link> = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" | ||
277 | </literallayout> | ||
278 | <literallayout class='monospaced'> | ||
279 | TMPDIR = "${<link linkend='var-bb-TOPDIR'>TOPDIR</link>}/tmp" | ||
280 | <link linkend='var-bb-CACHE'>CACHE</link> = "${TMPDIR}/cache" | ||
281 | <link linkend='var-bb-STAMP'>STAMP</link> = "${TMPDIR}/${PN}/stamps" | ||
282 | <link linkend='var-bb-T'>T</link> = "${TMPDIR}/${PN}/work" | ||
283 | <link linkend='var-bb-B'>B</link> = "${TMPDIR}/${PN}" | ||
284 | </literallayout> | ||
285 | <note> | ||
286 | Without a value for <filename>PN</filename>, the | ||
287 | variables <filename>STAMP</filename>, | ||
288 | <filename>T</filename>, and <filename>B</filename>, | ||
289 | prevent more than one recipe from working. You can fix | ||
290 | this by either setting <filename>PN</filename> to have | ||
291 | a value similar to what OpenEmbedded and BitBake use | ||
292 | in the default <filename>bitbake.conf</filename> file | ||
293 | (see previous example). Or, by manually updating each | ||
294 | recipe to set <filename>PN</filename>. You will also | ||
295 | need to include <filename>PN</filename> as part of the | ||
296 | <filename>STAMP</filename>, <filename>T</filename>, and | ||
297 | <filename>B</filename> variable definitions in the | ||
298 | <filename>local.conf</filename> file. | ||
299 | </note> | ||
300 | The <filename>TMPDIR</filename> variable establishes a directory | ||
301 | that BitBake uses for build output and intermediate files other | ||
302 | than the cached information used by the | ||
303 | <link linkend='setscene'>Setscene</link> process. | ||
304 | Here, the <filename>TMPDIR</filename> directory is set to | ||
305 | <filename>hello/tmp</filename>. | ||
306 | <note><title>Tip</title> | ||
307 | You can always safely delete the <filename>tmp</filename> | ||
308 | directory in order to rebuild a BitBake target. | ||
309 | The build process creates the directory for you | ||
310 | when you run BitBake. | ||
311 | </note></para> | ||
312 | <para>For information about each of the other variables defined in this | ||
313 | example, click on the links to take you to the definitions in | ||
314 | the glossary. | ||
315 | </para></listitem> | ||
316 | <listitem><para><emphasis>Run BitBake:</emphasis> | ||
317 | After making sure that the <filename>conf/bitbake.conf</filename> | ||
318 | file exists, you can run the <filename>bitbake</filename> | ||
319 | command again: | ||
320 | <literallayout class='monospaced'> | ||
321 | $ bitbake | ||
322 | ERROR: Traceback (most recent call last): | ||
323 | File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped | ||
324 | return func(fn, *args) | ||
325 | File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 177, in _inherit | ||
326 | bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data) | ||
327 | File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 92, in inherit | ||
328 | include(fn, file, lineno, d, "inherit") | ||
329 | File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 100, in include | ||
330 | raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno) | ||
331 | ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass | ||
332 | |||
333 | ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass | ||
334 | </literallayout> | ||
335 | In the sample output, BitBake could not find the | ||
336 | <filename>classes/base.bbclass</filename> file. | ||
337 | You need to create that file next. | ||
338 | </para></listitem> | ||
339 | <listitem><para><emphasis>Creating <filename>classes/base.bbclass</filename>:</emphasis> | ||
340 | BitBake uses class files to provide common code and functionality. | ||
341 | The minimally required class for BitBake is the | ||
342 | <filename>classes/base.bbclass</filename> file. | ||
343 | The <filename>base</filename> class is implicitly inherited by | ||
344 | every recipe. | ||
345 | BitBake looks for the class in the <filename>classes</filename> | ||
346 | directory of the project (i.e <filename>hello/classes</filename> | ||
347 | in this example). | ||
348 | </para> | ||
349 | <para>Create the <filename>classes</filename> directory as follows: | ||
350 | <literallayout class='monospaced'> | ||
351 | $ cd $HOME/hello | ||
352 | $ mkdir classes | ||
353 | </literallayout> | ||
354 | Move to the <filename>classes</filename> directory and then | ||
355 | create the <filename>base.bbclass</filename> file by inserting | ||
356 | this single line: | ||
357 | <literallayout class='monospaced'> | ||
358 | addtask build | ||
359 | </literallayout> | ||
360 | The minimal task that BitBake runs is the | ||
361 | <filename>do_build</filename> task. | ||
362 | This is all the example needs in order to build the project. | ||
363 | Of course, the <filename>base.bbclass</filename> can have much | ||
364 | more depending on which build environments BitBake is | ||
365 | supporting. | ||
366 | </para></listitem> | ||
367 | <listitem><para><emphasis>Run BitBake:</emphasis> | ||
368 | After making sure that the <filename>classes/base.bbclass</filename> | ||
369 | file exists, you can run the <filename>bitbake</filename> | ||
370 | command again: | ||
371 | <literallayout class='monospaced'> | ||
372 | $ bitbake | ||
373 | Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information. | ||
374 | </literallayout> | ||
375 | BitBake is finally reporting no errors. | ||
376 | However, you can see that it really does not have anything | ||
377 | to do. | ||
378 | You need to create a recipe that gives BitBake something to do. | ||
379 | </para></listitem> | ||
380 | <listitem><para><emphasis>Creating a Layer:</emphasis> | ||
381 | While it is not really necessary for such a small example, | ||
382 | it is good practice to create a layer in which to keep your | ||
383 | code separate from the general metadata used by BitBake. | ||
384 | Thus, this example creates and uses a layer called "mylayer". | ||
385 | <note> | ||
386 | You can find additional information on layers in the | ||
387 | "<link linkend='layers'>Layers</link>" section. | ||
388 | </note></para> | ||
389 | |||
390 | <para>Minimally, you need a recipe file and a layer configuration | ||
391 | file in your layer. | ||
392 | The configuration file needs to be in the <filename>conf</filename> | ||
393 | directory inside the layer. | ||
394 | Use these commands to set up the layer and the <filename>conf</filename> | ||
395 | directory: | ||
396 | <literallayout class='monospaced'> | ||
397 | $ cd $HOME | ||
398 | $ mkdir mylayer | ||
399 | $ cd mylayer | ||
400 | $ mkdir conf | ||
401 | </literallayout> | ||
402 | Move to the <filename>conf</filename> directory and create a | ||
403 | <filename>layer.conf</filename> file that has the following: | ||
404 | <literallayout class='monospaced'> | ||
405 | BBPATH .= ":${<link linkend='var-bb-LAYERDIR'>LAYERDIR</link>}" | ||
406 | |||
407 | <link linkend='var-bb-BBFILES'>BBFILES</link> += "${LAYERDIR}/*.bb" | ||
408 | |||
409 | <link linkend='var-bb-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</link> += "mylayer" | ||
410 | <link linkend='var-bb-BBFILE_PATTERN'>BBFILE_PATTERN_mylayer</link> := "^${LAYERDIR_RE}/" | ||
411 | </literallayout> | ||
412 | For information on these variables, click the links | ||
413 | to go to the definitions in the glossary.</para> | ||
414 | <para>You need to create the recipe file next. | ||
415 | Inside your layer at the top-level, use an editor and create | ||
416 | a recipe file named <filename>printhello.bb</filename> that | ||
417 | has the following: | ||
418 | <literallayout class='monospaced'> | ||
419 | <link linkend='var-bb-DESCRIPTION'>DESCRIPTION</link> = "Prints Hello World" | ||
420 | <link linkend='var-bb-PN'>PN</link> = 'printhello' | ||
421 | <link linkend='var-bb-PV'>PV</link> = '1' | ||
422 | |||
423 | python do_build() { | ||
424 | bb.plain("********************"); | ||
425 | bb.plain("* *"); | ||
426 | bb.plain("* Hello, World! *"); | ||
427 | bb.plain("* *"); | ||
428 | bb.plain("********************"); | ||
429 | } | ||
430 | </literallayout> | ||
431 | The recipe file simply provides a description of the | ||
432 | recipe, the name, version, and the <filename>do_build</filename> | ||
433 | task, which prints out "Hello World" to the console. | ||
434 | For more information on these variables, follow the links | ||
435 | to the glossary. | ||
436 | </para></listitem> | ||
437 | <listitem><para><emphasis>Run BitBake With a Target:</emphasis> | ||
438 | Now that a BitBake target exists, run the command and provide | ||
439 | that target: | ||
440 | <literallayout class='monospaced'> | ||
441 | $ cd $HOME/hello | ||
442 | $ bitbake printhello | ||
443 | ERROR: no recipe files to build, check your BBPATH and BBFILES? | ||
444 | |||
445 | Summary: There was 1 ERROR message shown, returning a non-zero exit code. | ||
446 | </literallayout> | ||
447 | We have created the layer with the recipe and the layer | ||
448 | configuration file but it still seems that BitBake cannot | ||
449 | find the recipe. | ||
450 | BitBake needs a <filename>conf/bblayers.conf</filename> that | ||
451 | lists the layers for the project. | ||
452 | Without this file, BitBake cannot find the recipe. | ||
453 | </para></listitem> | ||
454 | <listitem><para><emphasis>Creating <filename>conf/bblayers.conf</filename>:</emphasis> | ||
455 | BitBake uses the <filename>conf/bblayers.conf</filename> file | ||
456 | to locate layers needed for the project. | ||
457 | This file must reside in the <filename>conf</filename> directory | ||
458 | of the project (i.e. <filename>hello/conf</filename> for this | ||
459 | example).</para> | ||
460 | <para>Set your working directory to the <filename>hello/conf</filename> | ||
461 | directory and then create the <filename>bblayers.conf</filename> | ||
462 | file so that it contains the following: | ||
463 | <literallayout class='monospaced'> | ||
464 | BBLAYERS ?= " \ | ||
465 | /home/<you>/mylayer \ | ||
466 | " | ||
467 | </literallayout> | ||
468 | You need to provide your own information for | ||
469 | <filename>you</filename> in the file. | ||
470 | </para></listitem> | ||
471 | <listitem><para><emphasis>Run BitBake With a Target:</emphasis> | ||
472 | Now that you have supplied the <filename>bblayers.conf</filename> | ||
473 | file, run the <filename>bitbake</filename> command and provide | ||
474 | the target: | ||
475 | <literallayout class='monospaced'> | ||
476 | $ bitbake printhello | ||
477 | Parsing recipes: 100% |##################################################################################| | ||
478 | Time: 00:00:00 | ||
479 | Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0 skipped, 0 masked, 0 errors. | ||
480 | NOTE: Resolving any missing task queue dependencies | ||
481 | NOTE: Preparing RunQueue | ||
482 | NOTE: Executing RunQueue Tasks | ||
483 | ******************** | ||
484 | * * | ||
485 | * Hello, World! * | ||
486 | * * | ||
487 | ******************** | ||
488 | NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded. | ||
489 | </literallayout> | ||
490 | BitBake finds the <filename>printhello</filename> recipe and | ||
491 | successfully runs the task. | ||
492 | <note> | ||
493 | After the first execution, re-running | ||
494 | <filename>bitbake printhello</filename> again will not | ||
495 | result in a BitBake run that prints the same console | ||
496 | output. | ||
497 | The reason for this is that the first time the | ||
498 | <filename>printhello.bb</filename> recipe's | ||
499 | <filename>do_build</filename> task executes | ||
500 | successfully, BitBake writes a stamp file for the task. | ||
501 | Thus, the next time you attempt to run the task | ||
502 | using that same <filename>bitbake</filename> command, | ||
503 | BitBake notices the stamp and therefore determines | ||
504 | that the task does not need to be re-run. | ||
505 | If you delete the <filename>tmp</filename> directory | ||
506 | or run <filename>bitbake -c clean printhello</filename> | ||
507 | and then re-run the build, the "Hello, World!" message will | ||
508 | be printed again. | ||
509 | </note> | ||
510 | </para></listitem> | ||
511 | </orderedlist> | ||
512 | </section> | ||
513 | </appendix> | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml deleted file mode 100644 index 995c2fa7bf..0000000000 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml +++ /dev/null | |||
@@ -1,891 +0,0 @@ | |||
1 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" | ||
2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> | ||
3 | |||
4 | <chapter id="bitbake-user-manual-intro"> | ||
5 | <title>Overview</title> | ||
6 | |||
7 | <para> | ||
8 | Welcome to the BitBake User Manual. | ||
9 | This manual provides information on the BitBake tool. | ||
10 | The information attempts to be as independent as possible regarding | ||
11 | systems that use BitBake, such as OpenEmbedded and the | ||
12 | Yocto Project. | ||
13 | In some cases, scenarios or examples within the context of | ||
14 | a build system are used in the manual to help with understanding. | ||
15 | For these cases, the manual clearly states the context. | ||
16 | </para> | ||
17 | |||
18 | <section id="intro"> | ||
19 | <title>Introduction</title> | ||
20 | |||
21 | <para> | ||
22 | Fundamentally, BitBake is a generic task execution | ||
23 | engine that allows shell and Python tasks to be run | ||
24 | efficiently and in parallel while working within | ||
25 | complex inter-task dependency constraints. | ||
26 | One of BitBake's main users, OpenEmbedded, takes this core | ||
27 | and builds embedded Linux software stacks using | ||
28 | a task-oriented approach. | ||
29 | </para> | ||
30 | |||
31 | <para> | ||
32 | Conceptually, BitBake is similar to GNU Make in | ||
33 | some regards but has significant differences: | ||
34 | <itemizedlist> | ||
35 | <listitem><para> | ||
36 | BitBake executes tasks according to provided | ||
37 | metadata that builds up the tasks. | ||
38 | Metadata is stored in recipe (<filename>.bb</filename>) | ||
39 | and related recipe "append" (<filename>.bbappend</filename>) | ||
40 | files, configuration (<filename>.conf</filename>) and | ||
41 | underlying include (<filename>.inc</filename>) files, and | ||
42 | in class (<filename>.bbclass</filename>) files. | ||
43 | The metadata provides | ||
44 | BitBake with instructions on what tasks to run and | ||
45 | the dependencies between those tasks. | ||
46 | </para></listitem> | ||
47 | <listitem><para> | ||
48 | BitBake includes a fetcher library for obtaining source | ||
49 | code from various places such as local files, source control | ||
50 | systems, or websites. | ||
51 | </para></listitem> | ||
52 | <listitem><para> | ||
53 | The instructions for each unit to be built (e.g. a piece | ||
54 | of software) are known as "recipe" files and | ||
55 | contain all the information about the unit | ||
56 | (dependencies, source file locations, checksums, description | ||
57 | and so on). | ||
58 | </para></listitem> | ||
59 | <listitem><para> | ||
60 | BitBake includes a client/server abstraction and can | ||
61 | be used from a command line or used as a service over | ||
62 | XML-RPC and has several different user interfaces. | ||
63 | </para></listitem> | ||
64 | </itemizedlist> | ||
65 | </para> | ||
66 | </section> | ||
67 | |||
68 | <section id="history-and-goals"> | ||
69 | <title>History and Goals</title> | ||
70 | |||
71 | <para> | ||
72 | BitBake was originally a part of the OpenEmbedded project. | ||
73 | It was inspired by the Portage package management system | ||
74 | used by the Gentoo Linux distribution. | ||
75 | On December 7, 2004, OpenEmbedded project team member | ||
76 | Chris Larson split the project into two distinct pieces: | ||
77 | <itemizedlist> | ||
78 | <listitem><para>BitBake, a generic task executor</para></listitem> | ||
79 | <listitem><para>OpenEmbedded, a metadata set utilized by | ||
80 | BitBake</para></listitem> | ||
81 | </itemizedlist> | ||
82 | Today, BitBake is the primary basis of the | ||
83 | <ulink url="http://www.openembedded.org/">OpenEmbedded</ulink> | ||
84 | project, which is being used to build and maintain Linux | ||
85 | distributions such as the | ||
86 | <ulink url='http://www.angstrom-distribution.org/'>Angstrom Distribution</ulink>, | ||
87 | and which is also being used as the build tool for Linux projects | ||
88 | such as the | ||
89 | <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink>. | ||
90 | </para> | ||
91 | |||
92 | <para> | ||
93 | Prior to BitBake, no other build tool adequately met the needs of | ||
94 | an aspiring embedded Linux distribution. | ||
95 | All of the build systems used by traditional desktop Linux | ||
96 | distributions lacked important functionality, and none of the | ||
97 | ad hoc Buildroot-based systems, prevalent in the | ||
98 | embedded space, were scalable or maintainable. | ||
99 | </para> | ||
100 | |||
101 | <para> | ||
102 | Some important original goals for BitBake were: | ||
103 | <itemizedlist> | ||
104 | <listitem><para> | ||
105 | Handle cross-compilation. | ||
106 | </para></listitem> | ||
107 | <listitem><para> | ||
108 | Handle inter-package dependencies (build time on | ||
109 | target architecture, build time on native | ||
110 | architecture, and runtime). | ||
111 | </para></listitem> | ||
112 | <listitem><para> | ||
113 | Support running any number of tasks within a given | ||
114 | package, including, but not limited to, fetching | ||
115 | upstream sources, unpacking them, patching them, | ||
116 | configuring them, and so forth. | ||
117 | </para></listitem> | ||
118 | <listitem><para> | ||
119 | Be Linux distribution agnostic for both build and | ||
120 | target systems. | ||
121 | </para></listitem> | ||
122 | <listitem><para> | ||
123 | Be architecture agnostic. | ||
124 | </para></listitem> | ||
125 | <listitem><para> | ||
126 | Support multiple build and target operating systems | ||
127 | (e.g. Cygwin, the BSDs, and so forth). | ||
128 | </para></listitem> | ||
129 | <listitem><para> | ||
130 | Be self-contained, rather than tightly | ||
131 | integrated into the build machine's root | ||
132 | filesystem. | ||
133 | </para></listitem> | ||
134 | <listitem><para> | ||
135 | Handle conditional metadata on the target architecture, | ||
136 | operating system, distribution, and machine. | ||
137 | </para></listitem> | ||
138 | <listitem><para> | ||
139 | Be easy to use the tools to supply local metadata and packages | ||
140 | against which to operate. | ||
141 | </para></listitem> | ||
142 | <listitem><para> | ||
143 | Be easy to use BitBake to collaborate between multiple | ||
144 | projects for their builds. | ||
145 | </para></listitem> | ||
146 | <listitem><para> | ||
147 | Provide an inheritance mechanism to share | ||
148 | common metadata between many packages. | ||
149 | </para></listitem> | ||
150 | </itemizedlist> | ||
151 | Over time it became apparent that some further requirements | ||
152 | were necessary: | ||
153 | <itemizedlist> | ||
154 | <listitem><para> | ||
155 | Handle variants of a base recipe (e.g. native, sdk, | ||
156 | and multilib). | ||
157 | </para></listitem> | ||
158 | <listitem><para> | ||
159 | Split metadata into layers and allow layers | ||
160 | to enhance or override other layers. | ||
161 | </para></listitem> | ||
162 | <listitem><para> | ||
163 | Allow representation of a given set of input variables | ||
164 | to a task as a checksum. | ||
165 | Based on that checksum, allow acceleration of builds | ||
166 | with prebuilt components. | ||
167 | </para></listitem> | ||
168 | </itemizedlist> | ||
169 | BitBake satisfies all the original requirements and many more | ||
170 | with extensions being made to the basic functionality to | ||
171 | reflect the additional requirements. | ||
172 | Flexibility and power have always been the priorities. | ||
173 | BitBake is highly extensible and supports embedded Python code and | ||
174 | execution of any arbitrary tasks. | ||
175 | </para> | ||
176 | </section> | ||
177 | |||
178 | <section id="Concepts"> | ||
179 | <title>Concepts</title> | ||
180 | |||
181 | <para> | ||
182 | BitBake is a program written in the Python language. | ||
183 | At the highest level, BitBake interprets metadata, decides | ||
184 | what tasks are required to run, and executes those tasks. | ||
185 | Similar to GNU Make, BitBake controls how software is | ||
186 | built. | ||
187 | GNU Make achieves its control through "makefiles", while | ||
188 | BitBake uses "recipes". | ||
189 | </para> | ||
190 | |||
191 | <para> | ||
192 | BitBake extends the capabilities of a simple | ||
193 | tool like GNU Make by allowing for the definition of much more | ||
194 | complex tasks, such as assembling entire embedded Linux | ||
195 | distributions. | ||
196 | </para> | ||
197 | |||
198 | <para> | ||
199 | The remainder of this section introduces several concepts | ||
200 | that should be understood in order to better leverage | ||
201 | the power of BitBake. | ||
202 | </para> | ||
203 | |||
204 | <section id='recipes'> | ||
205 | <title>Recipes</title> | ||
206 | |||
207 | <para> | ||
208 | BitBake Recipes, which are denoted by the file extension | ||
209 | <filename>.bb</filename>, are the most basic metadata files. | ||
210 | These recipe files provide BitBake with the following: | ||
211 | <itemizedlist> | ||
212 | <listitem><para>Descriptive information about the | ||
213 | package (author, homepage, license, and so on)</para></listitem> | ||
214 | <listitem><para>The version of the recipe</para></listitem> | ||
215 | <listitem><para>Existing dependencies (both build | ||
216 | and runtime dependencies)</para></listitem> | ||
217 | <listitem><para>Where the source code resides and | ||
218 | how to fetch it</para></listitem> | ||
219 | <listitem><para>Whether the source code requires | ||
220 | any patches, where to find them, and how to apply | ||
221 | them</para></listitem> | ||
222 | <listitem><para>How to configure and compile the | ||
223 | source code</para></listitem> | ||
224 | <listitem><para>How to assemble the generated artifacts into | ||
225 | one or more installable packages</para></listitem> | ||
226 | <listitem><para>Where on the target machine to install the | ||
227 | package or packages created</para></listitem> | ||
228 | </itemizedlist> | ||
229 | </para> | ||
230 | |||
231 | <para> | ||
232 | Within the context of BitBake, or any project utilizing BitBake | ||
233 | as its build system, files with the <filename>.bb</filename> | ||
234 | extension are referred to as <firstterm>recipes</firstterm>. | ||
235 | <note> | ||
236 | The term "package" is also commonly used to describe recipes. | ||
237 | However, since the same word is used to describe packaged | ||
238 | output from a project, it is best to maintain a single | ||
239 | descriptive term - "recipes". | ||
240 | Put another way, a single "recipe" file is quite capable | ||
241 | of generating a number of related but separately installable | ||
242 | "packages". | ||
243 | In fact, that ability is fairly common. | ||
244 | </note> | ||
245 | </para> | ||
246 | </section> | ||
247 | |||
248 | <section id='configuration-files'> | ||
249 | <title>Configuration Files</title> | ||
250 | |||
251 | <para> | ||
252 | Configuration files, which are denoted by the | ||
253 | <filename>.conf</filename> extension, define | ||
254 | various configuration variables that govern the project's build | ||
255 | process. | ||
256 | These files fall into several areas that define | ||
257 | machine configuration, distribution configuration, | ||
258 | possible compiler tuning, general common | ||
259 | configuration, and user configuration. | ||
260 | The main configuration file is the sample | ||
261 | <filename>bitbake.conf</filename> file, which is | ||
262 | located within the BitBake source tree | ||
263 | <filename>conf</filename> directory. | ||
264 | </para> | ||
265 | </section> | ||
266 | |||
267 | <section id='classes'> | ||
268 | <title>Classes</title> | ||
269 | |||
270 | <para> | ||
271 | Class files, which are denoted by the | ||
272 | <filename>.bbclass</filename> extension, contain | ||
273 | information that is useful to share between metadata files. | ||
274 | The BitBake source tree currently comes with one class metadata file | ||
275 | called <filename>base.bbclass</filename>. | ||
276 | You can find this file in the | ||
277 | <filename>classes</filename> directory. | ||
278 | The <filename>base.bbclass</filename> class files is special since it | ||
279 | is always included automatically for all recipes | ||
280 | and classes. | ||
281 | This class contains definitions for standard basic tasks such | ||
282 | as fetching, unpacking, configuring (empty by default), | ||
283 | compiling (runs any Makefile present), installing (empty by | ||
284 | default) and packaging (empty by default). | ||
285 | These tasks are often overridden or extended by other classes | ||
286 | added during the project development process. | ||
287 | </para> | ||
288 | </section> | ||
289 | |||
290 | <section id='layers'> | ||
291 | <title>Layers</title> | ||
292 | |||
293 | <para> | ||
294 | Layers allow you to isolate different types of | ||
295 | customizations from each other. | ||
296 | While you might find it tempting to keep everything in one layer | ||
297 | when working on a single project, the more modular | ||
298 | your metadata, the easier it is to cope with future changes. | ||
299 | </para> | ||
300 | |||
301 | <para> | ||
302 | To illustrate how you can use layers to keep things modular, | ||
303 | consider customizations you might make to support a specific target machine. | ||
304 | These types of customizations typically reside in a special layer, | ||
305 | rather than a general layer, called a <firstterm>Board Support Package</firstterm> (BSP) | ||
306 | layer. | ||
307 | Furthermore, the machine customizations should be isolated from | ||
308 | recipes and metadata that support a new GUI environment, for | ||
309 | example. | ||
310 | This situation gives you a couple of layers: one for the machine | ||
311 | configurations and one for the GUI environment. | ||
312 | It is important to understand, however, that the BSP layer can still | ||
313 | make machine-specific additions to recipes within | ||
314 | the GUI environment layer without polluting the GUI layer itself | ||
315 | with those machine-specific changes. | ||
316 | You can accomplish this through a recipe that is a BitBake append | ||
317 | (<filename>.bbappend</filename>) file. | ||
318 | </para> | ||
319 | </section> | ||
320 | |||
321 | <section id='append-bbappend-files'> | ||
322 | <title>Append Files</title> | ||
323 | |||
324 | <para> | ||
325 | Append files, which are files that have the | ||
326 | <filename>.bbappend</filename> file extension, extend or | ||
327 | override information in an existing recipe file. | ||
328 | </para> | ||
329 | |||
330 | <para> | ||
331 | BitBake expects every append file to have a corresponding recipe file. | ||
332 | Furthermore, the append file and corresponding recipe file | ||
333 | must use the same root filename. | ||
334 | The filenames can differ only in the file type suffix used | ||
335 | (e.g. <filename>formfactor_0.0.bb</filename> and | ||
336 | <filename>formfactor_0.0.bbappend</filename>). | ||
337 | </para> | ||
338 | |||
339 | <para> | ||
340 | Information in append files extends or | ||
341 | overrides the information in the underlying, | ||
342 | similarly-named recipe files. | ||
343 | </para> | ||
344 | |||
345 | <para> | ||
346 | When you name an append file, you can use the | ||
347 | "<filename>%</filename>" wildcard character to allow for matching | ||
348 | recipe names. | ||
349 | For example, suppose you have an append file named | ||
350 | as follows: | ||
351 | <literallayout class='monospaced'> | ||
352 | busybox_1.21.%.bbappend | ||
353 | </literallayout> | ||
354 | That append file would match any <filename>busybox_1.21.</filename><replaceable>x</replaceable><filename>.bb</filename> | ||
355 | version of the recipe. | ||
356 | So, the append file would match the following recipe names: | ||
357 | <literallayout class='monospaced'> | ||
358 | busybox_1.21.1.bb | ||
359 | busybox_1.21.2.bb | ||
360 | busybox_1.21.3.bb | ||
361 | </literallayout> | ||
362 | <note><title>Important</title> | ||
363 | The use of the "<filename>%</filename>" character | ||
364 | is limited in that it only works directly in front of the | ||
365 | <filename>.bbappend</filename> portion of the append file's | ||
366 | name. | ||
367 | You cannot use the wildcard character in any other | ||
368 | location of the name. | ||
369 | </note> | ||
370 | If the <filename>busybox</filename> recipe was updated to | ||
371 | <filename>busybox_1.3.0.bb</filename>, the append name would not | ||
372 | match. | ||
373 | However, if you named the append file | ||
374 | <filename>busybox_1.%.bbappend</filename>, then you would have a match. | ||
375 | </para> | ||
376 | |||
377 | <para> | ||
378 | In the most general case, you could name the append file something as | ||
379 | simple as <filename>busybox_%.bbappend</filename> to be entirely | ||
380 | version independent. | ||
381 | </para> | ||
382 | </section> | ||
383 | </section> | ||
384 | |||
385 | <section id='obtaining-bitbake'> | ||
386 | <title>Obtaining BitBake</title> | ||
387 | |||
388 | <para> | ||
389 | You can obtain BitBake several different ways: | ||
390 | <itemizedlist> | ||
391 | <listitem><para><emphasis>Cloning BitBake:</emphasis> | ||
392 | Using Git to clone the BitBake source code repository | ||
393 | is the recommended method for obtaining BitBake. | ||
394 | Cloning the repository makes it easy to get bug fixes | ||
395 | and have access to stable branches and the master | ||
396 | branch. | ||
397 | Once you have cloned BitBake, you should use | ||
398 | the latest stable | ||
399 | branch for development since the master branch is for | ||
400 | BitBake development and might contain less stable changes. | ||
401 | </para> | ||
402 | <para>You usually need a version of BitBake | ||
403 | that matches the metadata you are using. | ||
404 | The metadata is generally backwards compatible but | ||
405 | not forward compatible.</para> | ||
406 | <para>Here is an example that clones the BitBake repository: | ||
407 | <literallayout class='monospaced'> | ||
408 | $ git clone git://git.openembedded.org/bitbake | ||
409 | </literallayout> | ||
410 | This command clones the BitBake Git repository into a | ||
411 | directory called <filename>bitbake</filename>. | ||
412 | Alternatively, you can | ||
413 | designate a directory after the | ||
414 | <filename>git clone</filename> command | ||
415 | if you want to call the new directory something | ||
416 | other than <filename>bitbake</filename>. | ||
417 | Here is an example that names the directory | ||
418 | <filename>bbdev</filename>: | ||
419 | <literallayout class='monospaced'> | ||
420 | $ git clone git://git.openembedded.org/bitbake bbdev | ||
421 | </literallayout></para></listitem> | ||
422 | <listitem><para><emphasis>Installation using your Distribution | ||
423 | Package Management System:</emphasis> | ||
424 | This method is not | ||
425 | recommended because the BitBake version that is | ||
426 | provided by your distribution, in most cases, | ||
427 | is several | ||
428 | releases behind a snapshot of the BitBake repository. | ||
429 | </para></listitem> | ||
430 | <listitem><para><emphasis>Taking a snapshot of BitBake:</emphasis> | ||
431 | Downloading a snapshot of BitBake from the | ||
432 | source code repository gives you access to a known | ||
433 | branch or release of BitBake. | ||
434 | <note> | ||
435 | Cloning the Git repository, as described earlier, | ||
436 | is the preferred method for getting BitBake. | ||
437 | Cloning the repository makes it easier to update as | ||
438 | patches are added to the stable branches. | ||
439 | </note></para> | ||
440 | <para>The following example downloads a snapshot of | ||
441 | BitBake version 1.17.0: | ||
442 | <literallayout class='monospaced'> | ||
443 | $ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz | ||
444 | $ tar zxpvf bitbake-1.17.0.tar.gz | ||
445 | </literallayout> | ||
446 | After extraction of the tarball using the tar utility, | ||
447 | you have a directory entitled | ||
448 | <filename>bitbake-1.17.0</filename>. | ||
449 | </para></listitem> | ||
450 | <listitem><para><emphasis>Using the BitBake that Comes With Your | ||
451 | Build Checkout:</emphasis> | ||
452 | A final possibility for getting a copy of BitBake is that it | ||
453 | already comes with your checkout of a larger BitBake-based build | ||
454 | system, such as Poky. | ||
455 | Rather than manually checking out individual layers and | ||
456 | gluing them together yourself, you can check | ||
457 | out an entire build system. | ||
458 | The checkout will already include a version of BitBake that | ||
459 | has been thoroughly tested for compatibility with the other | ||
460 | components. | ||
461 | For information on how to check out a particular BitBake-based | ||
462 | build system, consult that build system's supporting documentation. | ||
463 | </para></listitem> | ||
464 | </itemizedlist> | ||
465 | </para> | ||
466 | </section> | ||
467 | |||
468 | <section id="bitbake-user-manual-command"> | ||
469 | <title>The BitBake Command</title> | ||
470 | |||
471 | <para> | ||
472 | The <filename>bitbake</filename> command is the primary interface | ||
473 | to the BitBake tool. | ||
474 | This section presents the BitBake command syntax and provides | ||
475 | several execution examples. | ||
476 | </para> | ||
477 | |||
478 | <section id='usage-and-syntax'> | ||
479 | <title>Usage and syntax</title> | ||
480 | |||
481 | <para> | ||
482 | Following is the usage and syntax for BitBake: | ||
483 | <literallayout class='monospaced'> | ||
484 | $ bitbake -h | ||
485 | Usage: bitbake [options] [recipename/target recipe:do_task ...] | ||
486 | |||
487 | Executes the specified task (default is 'build') for a given set of target recipes (.bb files). | ||
488 | It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which | ||
489 | will provide the layer, BBFILES and other configuration information. | ||
490 | |||
491 | Options: | ||
492 | --version show program's version number and exit | ||
493 | -h, --help show this help message and exit | ||
494 | -b BUILDFILE, --buildfile=BUILDFILE | ||
495 | Execute tasks from a specific .bb recipe directly. | ||
496 | WARNING: Does not handle any dependencies from other | ||
497 | recipes. | ||
498 | -k, --continue Continue as much as possible after an error. While the | ||
499 | target that failed and anything depending on it cannot | ||
500 | be built, as much as possible will be built before | ||
501 | stopping. | ||
502 | -f, --force Force the specified targets/task to run (invalidating | ||
503 | any existing stamp file). | ||
504 | -c CMD, --cmd=CMD Specify the task to execute. The exact options | ||
505 | available depend on the metadata. Some examples might | ||
506 | be 'compile' or 'populate_sysroot' or 'listtasks' may | ||
507 | give a list of the tasks available. | ||
508 | -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP | ||
509 | Invalidate the stamp for the specified task such as | ||
510 | 'compile' and then run the default task for the | ||
511 | specified target(s). | ||
512 | -r PREFILE, --read=PREFILE | ||
513 | Read the specified file before bitbake.conf. | ||
514 | -R POSTFILE, --postread=POSTFILE | ||
515 | Read the specified file after bitbake.conf. | ||
516 | -v, --verbose Enable tracing of shell tasks (with 'set -x'). Also | ||
517 | print bb.note(...) messages to stdout (in addition to | ||
518 | writing them to ${T}/log.do_<task>). | ||
519 | -D, --debug Increase the debug level. You can specify this more | ||
520 | than once. -D sets the debug level to 1, where only | ||
521 | bb.debug(1, ...) messages are printed to stdout; -DD | ||
522 | sets the debug level to 2, where both bb.debug(1, ...) | ||
523 | and bb.debug(2, ...) messages are printed; etc. | ||
524 | Without -D, no debug messages are printed. Note that | ||
525 | -D only affects output to stdout. All debug messages | ||
526 | are written to ${T}/log.do_taskname, regardless of the | ||
527 | debug level. | ||
528 | -q, --quiet Output less log message data to the terminal. You can | ||
529 | specify this more than once. | ||
530 | -n, --dry-run Don't execute, just go through the motions. | ||
531 | -S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER | ||
532 | Dump out the signature construction information, with | ||
533 | no task execution. The SIGNATURE_HANDLER parameter is | ||
534 | passed to the handler. Two common values are none and | ||
535 | printdiff but the handler may define more/less. none | ||
536 | means only dump the signature, printdiff means compare | ||
537 | the dumped signature with the cached one. | ||
538 | -p, --parse-only Quit after parsing the BB recipes. | ||
539 | -s, --show-versions Show current and preferred versions of all recipes. | ||
540 | -e, --environment Show the global or per-recipe environment complete | ||
541 | with information about where variables were | ||
542 | set/changed. | ||
543 | -g, --graphviz Save dependency tree information for the specified | ||
544 | targets in the dot syntax. | ||
545 | -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED | ||
546 | Assume these dependencies don't exist and are already | ||
547 | provided (equivalent to ASSUME_PROVIDED). Useful to | ||
548 | make dependency graphs more appealing | ||
549 | -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS | ||
550 | Show debug logging for the specified logging domains | ||
551 | -P, --profile Profile the command and save reports. | ||
552 | -u UI, --ui=UI The user interface to use (knotty, ncurses or taskexp | ||
553 | - default knotty). | ||
554 | --token=XMLRPCTOKEN Specify the connection token to be used when | ||
555 | connecting to a remote server. | ||
556 | --revisions-changed Set the exit code depending on whether upstream | ||
557 | floating revisions have changed or not. | ||
558 | --server-only Run bitbake without a UI, only starting a server | ||
559 | (cooker) process. | ||
560 | -B BIND, --bind=BIND The name/address for the bitbake xmlrpc server to bind | ||
561 | to. | ||
562 | -T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT | ||
563 | Set timeout to unload bitbake server due to | ||
564 | inactivity, set to -1 means no unload, default: | ||
565 | Environment variable BB_SERVER_TIMEOUT. | ||
566 | --no-setscene Do not run any setscene tasks. sstate will be ignored | ||
567 | and everything needed, built. | ||
568 | --setscene-only Only run setscene tasks, don't run any real tasks. | ||
569 | --remote-server=REMOTE_SERVER | ||
570 | Connect to the specified server. | ||
571 | -m, --kill-server Terminate any running bitbake server. | ||
572 | --observe-only Connect to a server as an observing-only client. | ||
573 | --status-only Check the status of the remote bitbake server. | ||
574 | -w WRITEEVENTLOG, --write-log=WRITEEVENTLOG | ||
575 | Writes the event log of the build to a bitbake event | ||
576 | json file. Use '' (empty string) to assign the name | ||
577 | automatically. | ||
578 | --runall=RUNALL Run the specified task for any recipe in the taskgraph | ||
579 | of the specified target (even if it wouldn't otherwise | ||
580 | have run). | ||
581 | --runonly=RUNONLY Run only the specified task within the taskgraph of | ||
582 | the specified targets (and any task dependencies those | ||
583 | tasks may have). | ||
584 | </literallayout> | ||
585 | </para> | ||
586 | </section> | ||
587 | |||
588 | <section id='bitbake-examples'> | ||
589 | <title>Examples</title> | ||
590 | |||
591 | <para> | ||
592 | This section presents some examples showing how to use BitBake. | ||
593 | </para> | ||
594 | |||
595 | <section id='example-executing-a-task-against-a-single-recipe'> | ||
596 | <title>Executing a Task Against a Single Recipe</title> | ||
597 | |||
598 | <para> | ||
599 | Executing tasks for a single recipe file is relatively simple. | ||
600 | You specify the file in question, and BitBake parses | ||
601 | it and executes the specified task. | ||
602 | If you do not specify a task, BitBake executes the default | ||
603 | task, which is "buildâ€. | ||
604 | BitBake obeys inter-task dependencies when doing | ||
605 | so. | ||
606 | </para> | ||
607 | |||
608 | <para> | ||
609 | The following command runs the build task, which is | ||
610 | the default task, on the <filename>foo_1.0.bb</filename> | ||
611 | recipe file: | ||
612 | <literallayout class='monospaced'> | ||
613 | $ bitbake -b foo_1.0.bb | ||
614 | </literallayout> | ||
615 | The following command runs the clean task on the | ||
616 | <filename>foo.bb</filename> recipe file: | ||
617 | <literallayout class='monospaced'> | ||
618 | $ bitbake -b foo.bb -c clean | ||
619 | </literallayout> | ||
620 | <note> | ||
621 | The "-b" option explicitly does not handle recipe | ||
622 | dependencies. | ||
623 | Other than for debugging purposes, it is instead | ||
624 | recommended that you use the syntax presented in the | ||
625 | next section. | ||
626 | </note> | ||
627 | </para> | ||
628 | </section> | ||
629 | |||
630 | <section id='executing-tasks-against-a-set-of-recipe-files'> | ||
631 | <title>Executing Tasks Against a Set of Recipe Files</title> | ||
632 | |||
633 | <para> | ||
634 | There are a number of additional complexities introduced | ||
635 | when one wants to manage multiple <filename>.bb</filename> | ||
636 | files. | ||
637 | Clearly there needs to be a way to tell BitBake what | ||
638 | files are available and, of those, which you | ||
639 | want to execute. | ||
640 | There also needs to be a way for each recipe | ||
641 | to express its dependencies, both for build-time and | ||
642 | runtime. | ||
643 | There must be a way for you to express recipe preferences | ||
644 | when multiple recipes provide the same functionality, or when | ||
645 | there are multiple versions of a recipe. | ||
646 | </para> | ||
647 | |||
648 | <para> | ||
649 | The <filename>bitbake</filename> command, when not using | ||
650 | "--buildfile" or "-b" only accepts a "PROVIDES". | ||
651 | You cannot provide anything else. | ||
652 | By default, a recipe file generally "PROVIDES" its | ||
653 | "packagename" as shown in the following example: | ||
654 | <literallayout class='monospaced'> | ||
655 | $ bitbake foo | ||
656 | </literallayout> | ||
657 | This next example "PROVIDES" the package name and also uses | ||
658 | the "-c" option to tell BitBake to just execute the | ||
659 | <filename>do_clean</filename> task: | ||
660 | <literallayout class='monospaced'> | ||
661 | $ bitbake -c clean foo | ||
662 | </literallayout> | ||
663 | </para> | ||
664 | </section> | ||
665 | |||
666 | <section id='executing-a-list-of-task-and-recipe-combinations'> | ||
667 | <title>Executing a List of Task and Recipe Combinations</title> | ||
668 | |||
669 | <para> | ||
670 | The BitBake command line supports specifying different | ||
671 | tasks for individual targets when you specify multiple | ||
672 | targets. | ||
673 | For example, suppose you had two targets (or recipes) | ||
674 | <filename>myfirstrecipe</filename> and | ||
675 | <filename>mysecondrecipe</filename> and you needed | ||
676 | BitBake to run <filename>taskA</filename> for the first | ||
677 | recipe and <filename>taskB</filename> for the second | ||
678 | recipe: | ||
679 | <literallayout class='monospaced'> | ||
680 | $ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB | ||
681 | </literallayout> | ||
682 | </para> | ||
683 | </section> | ||
684 | |||
685 | <section id='generating-dependency-graphs'> | ||
686 | <title>Generating Dependency Graphs</title> | ||
687 | |||
688 | <para> | ||
689 | BitBake is able to generate dependency graphs using | ||
690 | the <filename>dot</filename> syntax. | ||
691 | You can convert these graphs into images using the | ||
692 | <filename>dot</filename> tool from | ||
693 | <ulink url='http://www.graphviz.org'>Graphviz</ulink>. | ||
694 | </para> | ||
695 | |||
696 | <para> | ||
697 | When you generate a dependency graph, BitBake writes two files | ||
698 | to the current working directory: | ||
699 | <itemizedlist> | ||
700 | <listitem><para> | ||
701 | <emphasis><filename>task-depends.dot</filename>:</emphasis> | ||
702 | Shows dependencies between tasks. | ||
703 | These dependencies match BitBake's internal task execution list. | ||
704 | </para></listitem> | ||
705 | <listitem><para> | ||
706 | <emphasis><filename>pn-buildlist</filename>:</emphasis> | ||
707 | Shows a simple list of targets that are to be built. | ||
708 | </para></listitem> | ||
709 | </itemizedlist> | ||
710 | </para> | ||
711 | |||
712 | <para> | ||
713 | To stop depending on common depends, use the "-I" depend | ||
714 | option and BitBake omits them from the graph. | ||
715 | Leaving this information out can produce more readable graphs. | ||
716 | This way, you can remove from the graph | ||
717 | <filename>DEPENDS</filename> from inherited classes | ||
718 | such as <filename>base.bbclass</filename>. | ||
719 | </para> | ||
720 | |||
721 | <para> | ||
722 | Here are two examples that create dependency graphs. | ||
723 | The second example omits depends common in OpenEmbedded from | ||
724 | the graph: | ||
725 | <literallayout class='monospaced'> | ||
726 | $ bitbake -g foo | ||
727 | |||
728 | $ bitbake -g -I virtual/kernel -I eglibc foo | ||
729 | </literallayout> | ||
730 | </para> | ||
731 | </section> | ||
732 | |||
733 | <section id='executing-a-multiple-configuration-build'> | ||
734 | <title>Executing a Multiple Configuration Build</title> | ||
735 | |||
736 | <para> | ||
737 | BitBake is able to build multiple images or packages | ||
738 | using a single command where the different targets | ||
739 | require different configurations (multiple configuration | ||
740 | builds). | ||
741 | Each target, in this scenario, is referred to as a | ||
742 | "multiconfig". | ||
743 | </para> | ||
744 | |||
745 | <para> | ||
746 | To accomplish a multiple configuration build, you must | ||
747 | define each target's configuration separately using | ||
748 | a parallel configuration file in the build directory. | ||
749 | The location for these multiconfig configuration files | ||
750 | is specific. | ||
751 | They must reside in the current build directory in | ||
752 | a sub-directory of <filename>conf</filename> named | ||
753 | <filename>multiconfig</filename>. | ||
754 | Following is an example for two separate targets: | ||
755 | <imagedata fileref="figures/bb_multiconfig_files.png" align="center" width="4in" depth="3in" /> | ||
756 | </para> | ||
757 | |||
758 | <para> | ||
759 | The reason for this required file hierarchy | ||
760 | is because the <filename>BBPATH</filename> variable | ||
761 | is not constructed until the layers are parsed. | ||
762 | Consequently, using the configuration file as a | ||
763 | pre-configuration file is not possible unless it is | ||
764 | located in the current working directory. | ||
765 | </para> | ||
766 | |||
767 | <para> | ||
768 | Minimally, each configuration file must define the | ||
769 | machine and the temporary directory BitBake uses | ||
770 | for the build. | ||
771 | Suggested practice dictates that you do not | ||
772 | overlap the temporary directories used during the | ||
773 | builds. | ||
774 | </para> | ||
775 | |||
776 | <para> | ||
777 | Aside from separate configuration files for each | ||
778 | target, you must also enable BitBake to perform multiple | ||
779 | configuration builds. | ||
780 | Enabling is accomplished by setting the | ||
781 | <link linkend='var-bb-BBMULTICONFIG'><filename>BBMULTICONFIG</filename></link> | ||
782 | variable in the <filename>local.conf</filename> | ||
783 | configuration file. | ||
784 | As an example, suppose you had configuration files | ||
785 | for <filename>target1</filename> and | ||
786 | <filename>target2</filename> defined in the build | ||
787 | directory. | ||
788 | The following statement in the | ||
789 | <filename>local.conf</filename> file both enables | ||
790 | BitBake to perform multiple configuration builds and | ||
791 | specifies the two extra multiconfigs: | ||
792 | <literallayout class='monospaced'> | ||
793 | BBMULTICONFIG = "target1 target2" | ||
794 | </literallayout> | ||
795 | </para> | ||
796 | |||
797 | <para> | ||
798 | Once the target configuration files are in place and | ||
799 | BitBake has been enabled to perform multiple configuration | ||
800 | builds, use the following command form to start the | ||
801 | builds: | ||
802 | <literallayout class='monospaced'> | ||
803 | $ bitbake [mc:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable> [[[mc:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable>] ... ] | ||
804 | </literallayout> | ||
805 | Here is an example for two extra multiconfigs: | ||
806 | <filename>target1</filename> and | ||
807 | <filename>target2</filename>: | ||
808 | <literallayout class='monospaced'> | ||
809 | $ bitbake mc::<replaceable>target</replaceable> mc:target1:<replaceable>target</replaceable> mc:target2:<replaceable>target</replaceable> | ||
810 | </literallayout> | ||
811 | </para> | ||
812 | </section> | ||
813 | |||
814 | <section id='bb-enabling-multiple-configuration-build-dependencies'> | ||
815 | <title>Enabling Multiple Configuration Build Dependencies</title> | ||
816 | |||
817 | <para> | ||
818 | Sometimes dependencies can exist between targets | ||
819 | (multiconfigs) in a multiple configuration build. | ||
820 | For example, suppose that in order to build an image | ||
821 | for a particular architecture, the root filesystem of | ||
822 | another build for a different architecture needs to | ||
823 | exist. | ||
824 | In other words, the image for the first multiconfig depends | ||
825 | on the root filesystem of the second multiconfig. | ||
826 | This dependency is essentially that the task in the recipe | ||
827 | that builds one multiconfig is dependent on the | ||
828 | completion of the task in the recipe that builds | ||
829 | another multiconfig. | ||
830 | </para> | ||
831 | |||
832 | <para> | ||
833 | To enable dependencies in a multiple configuration | ||
834 | build, you must declare the dependencies in the recipe | ||
835 | using the following statement form: | ||
836 | <literallayout class='monospaced'> | ||
837 | <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>" | ||
838 | </literallayout> | ||
839 | To better show how to use this statement, consider an | ||
840 | example with two multiconfigs: <filename>target1</filename> | ||
841 | and <filename>target2</filename>: | ||
842 | <literallayout class='monospaced'> | ||
843 | <replaceable>image_task</replaceable>[mcdepends] = "mc:target1:target2:<replaceable>image2</replaceable>:<replaceable>rootfs_task</replaceable>" | ||
844 | </literallayout> | ||
845 | In this example, the | ||
846 | <replaceable>from_multiconfig</replaceable> is "target1" and | ||
847 | the <replaceable>to_multiconfig</replaceable> is "target2". | ||
848 | The task on which the image whose recipe contains | ||
849 | <replaceable>image_task</replaceable> depends on the | ||
850 | completion of the <replaceable>rootfs_task</replaceable> | ||
851 | used to build out <replaceable>image2</replaceable>, which | ||
852 | is associated with the "target2" multiconfig. | ||
853 | </para> | ||
854 | |||
855 | <para> | ||
856 | Once you set up this dependency, you can build the | ||
857 | "target1" multiconfig using a BitBake command as follows: | ||
858 | <literallayout class='monospaced'> | ||
859 | $ bitbake mc:target1:<replaceable>image1</replaceable> | ||
860 | </literallayout> | ||
861 | This command executes all the tasks needed to create | ||
862 | <replaceable>image1</replaceable> for the "target1" | ||
863 | multiconfig. | ||
864 | Because of the dependency, BitBake also executes through | ||
865 | the <replaceable>rootfs_task</replaceable> for the "target2" | ||
866 | multiconfig build. | ||
867 | </para> | ||
868 | |||
869 | <para> | ||
870 | Having a recipe depend on the root filesystem of another | ||
871 | build might not seem that useful. | ||
872 | Consider this change to the statement in the | ||
873 | <replaceable>image1</replaceable> recipe: | ||
874 | <literallayout class='monospaced'> | ||
875 | <replaceable>image_task</replaceable>[mcdepends] = "mc:target1:target2:<replaceable>image2</replaceable>:<replaceable>image_task</replaceable>" | ||
876 | </literallayout> | ||
877 | In this case, BitBake must create | ||
878 | <replaceable>image2</replaceable> for the "target2" | ||
879 | build since the "target1" build depends on it. | ||
880 | </para> | ||
881 | |||
882 | <para> | ||
883 | Because "target1" and "target2" are enabled for multiple | ||
884 | configuration builds and have separate configuration | ||
885 | files, BitBake places the artifacts for each build in the | ||
886 | respective temporary build directories. | ||
887 | </para> | ||
888 | </section> | ||
889 | </section> | ||
890 | </section> | ||
891 | </chapter> | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml deleted file mode 100644 index 0ca5321618..0000000000 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml +++ /dev/null | |||
@@ -1,2862 +0,0 @@ | |||
1 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" | ||
2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> | ||
3 | |||
4 | <chapter id="bitbake-user-manual-metadata"> | ||
5 | <title>Syntax and Operators</title> | ||
6 | |||
7 | <para> | ||
8 | BitBake files have their own syntax. | ||
9 | The syntax has similarities to several | ||
10 | other languages but also has some unique features. | ||
11 | This section describes the available syntax and operators | ||
12 | as well as provides examples. | ||
13 | </para> | ||
14 | |||
15 | <section id='basic-syntax'> | ||
16 | <title>Basic Syntax</title> | ||
17 | |||
18 | <para> | ||
19 | This section provides some basic syntax examples. | ||
20 | </para> | ||
21 | |||
22 | <section id='basic-variable-setting'> | ||
23 | <title>Basic Variable Setting</title> | ||
24 | |||
25 | <para> | ||
26 | The following example sets <filename>VARIABLE</filename> to | ||
27 | "value". | ||
28 | This assignment occurs immediately as the statement is parsed. | ||
29 | It is a "hard" assignment. | ||
30 | <literallayout class='monospaced'> | ||
31 | VARIABLE = "value" | ||
32 | </literallayout> | ||
33 | As expected, if you include leading or trailing spaces as part of | ||
34 | an assignment, the spaces are retained: | ||
35 | <literallayout class='monospaced'> | ||
36 | VARIABLE = " value" | ||
37 | VARIABLE = "value " | ||
38 | </literallayout> | ||
39 | Setting <filename>VARIABLE</filename> to "" sets it to an empty string, | ||
40 | while setting the variable to " " sets it to a blank space | ||
41 | (i.e. these are not the same values). | ||
42 | <literallayout class='monospaced'> | ||
43 | VARIABLE = "" | ||
44 | VARIABLE = " " | ||
45 | </literallayout> | ||
46 | </para> | ||
47 | |||
48 | <para> | ||
49 | You can use single quotes instead of double quotes | ||
50 | when setting a variable's value. | ||
51 | Doing so allows you to use values that contain the double | ||
52 | quote character: | ||
53 | <literallayout class='monospaced'> | ||
54 | VARIABLE = 'I have a " in my value' | ||
55 | </literallayout> | ||
56 | <note> | ||
57 | Unlike in Bourne shells, single quotes work identically | ||
58 | to double quotes in all other ways. | ||
59 | They do not suppress variable expansions. | ||
60 | </note> | ||
61 | </para> | ||
62 | </section> | ||
63 | |||
64 | <section id='modifying-existing-variables'> | ||
65 | <title>Modifying Existing Variables</title> | ||
66 | |||
67 | <para> | ||
68 | Sometimes you need to modify existing variables. | ||
69 | Following are some cases where you might find you want to | ||
70 | modify an existing variable: | ||
71 | <itemizedlist> | ||
72 | <listitem><para> | ||
73 | Customize a recipe that uses the variable. | ||
74 | </para></listitem> | ||
75 | <listitem><para> | ||
76 | Change a variable's default value used in a | ||
77 | <filename>*.bbclass</filename> file. | ||
78 | </para></listitem> | ||
79 | <listitem><para> | ||
80 | Change the variable in a <filename>*.bbappend</filename> | ||
81 | file to override the variable in the original recipe. | ||
82 | </para></listitem> | ||
83 | <listitem><para> | ||
84 | Change the variable in a configuration file so that the | ||
85 | value overrides an existing configuration. | ||
86 | </para></listitem> | ||
87 | </itemizedlist> | ||
88 | </para> | ||
89 | |||
90 | <para> | ||
91 | Changing a variable value can sometimes depend on how the | ||
92 | value was originally assigned and also on the desired | ||
93 | intent of the change. | ||
94 | In particular, when you append a value to a variable that | ||
95 | has a default value, the resulting value might not be what | ||
96 | you expect. | ||
97 | In this case, the value you provide might replace the value | ||
98 | rather than append to the default value. | ||
99 | </para> | ||
100 | |||
101 | <para> | ||
102 | If after you have changed a variable's value and something | ||
103 | unexplained occurs, you can use BitBake to check the actual | ||
104 | value of the suspect variable. | ||
105 | You can make these checks for both configuration and recipe | ||
106 | level changes: | ||
107 | <itemizedlist> | ||
108 | <listitem><para> | ||
109 | For configuration changes, use the following: | ||
110 | <literallayout class='monospaced'> | ||
111 | $ bitbake -e | ||
112 | </literallayout> | ||
113 | This command displays variable values after the | ||
114 | configuration files (i.e. <filename>local.conf</filename>, | ||
115 | <filename>bblayers.conf</filename>, | ||
116 | <filename>bitbake.conf</filename> and so forth) have | ||
117 | been parsed. | ||
118 | <note> | ||
119 | Variables that are exported to the environment are | ||
120 | preceded by the string "export" in the command's | ||
121 | output. | ||
122 | </note> | ||
123 | </para></listitem> | ||
124 | <listitem><para> | ||
125 | For recipe changes, use the following: | ||
126 | <literallayout class='monospaced'> | ||
127 | $ bitbake <replaceable>recipe</replaceable> -e | grep VARIABLE=" | ||
128 | </literallayout> | ||
129 | This command checks to see if the variable actually | ||
130 | makes it into a specific recipe. | ||
131 | </para></listitem> | ||
132 | </itemizedlist> | ||
133 | </para> | ||
134 | </section> | ||
135 | |||
136 | <section id='line-joining'> | ||
137 | <title>Line Joining</title> | ||
138 | |||
139 | <para> | ||
140 | Outside of | ||
141 | <link linkend='functions'>functions</link>, BitBake joins | ||
142 | any line ending in a backslash character ("\") | ||
143 | with the following line before parsing statements. | ||
144 | The most common use for the "\" character is to split variable | ||
145 | assignments over multiple lines, as in the following example: | ||
146 | <literallayout class='monospaced'> | ||
147 | FOO = "bar \ | ||
148 | baz \ | ||
149 | qaz" | ||
150 | </literallayout> | ||
151 | Both the "\" character and the newline character | ||
152 | that follow it are removed when joining lines. | ||
153 | Thus, no newline characters end up in the value of | ||
154 | <filename>FOO</filename>. | ||
155 | </para> | ||
156 | |||
157 | <para> | ||
158 | Consider this additional example where the two | ||
159 | assignments both assign "barbaz" to | ||
160 | <filename>FOO</filename>: | ||
161 | <literallayout class='monospaced'> | ||
162 | FOO = "barbaz" | ||
163 | |||
164 | FOO = "bar\ | ||
165 | baz" | ||
166 | </literallayout> | ||
167 | <note> | ||
168 | BitBake does not interpret escape sequences like | ||
169 | "\n" in variable values. | ||
170 | For these to have an effect, the value must be passed | ||
171 | to some utility that interprets escape sequences, | ||
172 | such as <filename>printf</filename> or | ||
173 | <filename>echo -n</filename>. | ||
174 | </note> | ||
175 | </para> | ||
176 | </section> | ||
177 | |||
178 | <section id='variable-expansion'> | ||
179 | <title>Variable Expansion</title> | ||
180 | |||
181 | <para> | ||
182 | Variables can reference the contents of other variables | ||
183 | using a syntax that is similar to variable expansion in | ||
184 | Bourne shells. | ||
185 | The following assignments | ||
186 | result in A containing "aval" and B evaluating to "preavalpost". | ||
187 | <literallayout class='monospaced'> | ||
188 | A = "aval" | ||
189 | B = "pre${A}post" | ||
190 | </literallayout> | ||
191 | <note> | ||
192 | Unlike in Bourne shells, the curly braces are mandatory: | ||
193 | Only <filename>${FOO}</filename> and not | ||
194 | <filename>$FOO</filename> is recognized as an expansion of | ||
195 | <filename>FOO</filename>. | ||
196 | </note> | ||
197 | The "=" operator does not immediately expand variable | ||
198 | references in the right-hand side. | ||
199 | Instead, expansion is deferred until the variable assigned to | ||
200 | is actually used. | ||
201 | The result depends on the current values of the referenced | ||
202 | variables. | ||
203 | The following example should clarify this behavior: | ||
204 | <literallayout class='monospaced'> | ||
205 | A = "${B} baz" | ||
206 | B = "${C} bar" | ||
207 | C = "foo" | ||
208 | *At this point, ${A} equals "foo bar baz"* | ||
209 | C = "qux" | ||
210 | *At this point, ${A} equals "qux bar baz"* | ||
211 | B = "norf" | ||
212 | *At this point, ${A} equals "norf baz"* | ||
213 | </literallayout> | ||
214 | Contrast this behavior with the | ||
215 | <link linkend='immediate-variable-expansion'>immediate variable expansion</link> | ||
216 | operator (i.e. ":="). | ||
217 | </para> | ||
218 | |||
219 | <para> | ||
220 | If the variable expansion syntax is used on a variable that | ||
221 | does not exist, the string is kept as is. | ||
222 | For example, given the following assignment, | ||
223 | <filename>BAR</filename> expands to the literal string | ||
224 | "${FOO}" as long as <filename>FOO</filename> does not exist. | ||
225 | <literallayout class='monospaced'> | ||
226 | BAR = "${FOO}" | ||
227 | </literallayout> | ||
228 | </para> | ||
229 | </section> | ||
230 | |||
231 | <section id='setting-a-default-value'> | ||
232 | <title>Setting a default value (?=)</title> | ||
233 | |||
234 | <para> | ||
235 | You can use the "?=" operator to achieve a "softer" assignment | ||
236 | for a variable. | ||
237 | This type of assignment allows you to define a variable if it | ||
238 | is undefined when the statement is parsed, but to leave the | ||
239 | value alone if the variable has a value. | ||
240 | Here is an example: | ||
241 | <literallayout class='monospaced'> | ||
242 | A ?= "aval" | ||
243 | </literallayout> | ||
244 | If <filename>A</filename> is set at the time this statement is parsed, | ||
245 | the variable retains its value. | ||
246 | However, if <filename>A</filename> is not set, | ||
247 | the variable is set to "aval". | ||
248 | <note> | ||
249 | This assignment is immediate. | ||
250 | Consequently, if multiple "?=" assignments | ||
251 | to a single variable exist, the first of those ends up getting | ||
252 | used. | ||
253 | </note> | ||
254 | </para> | ||
255 | </section> | ||
256 | |||
257 | <section id='setting-a-weak-default-value'> | ||
258 | <title>Setting a weak default value (??=)</title> | ||
259 | |||
260 | <para> | ||
261 | It is possible to use a "weaker" assignment than in the | ||
262 | previous section by using the "??=" operator. | ||
263 | This assignment behaves identical to "?=" except that the | ||
264 | assignment is made at the end of the parsing process rather | ||
265 | than immediately. | ||
266 | Consequently, when multiple "??=" assignments exist, the last | ||
267 | one is used. | ||
268 | Also, any "=" or "?=" assignment will override the value set with | ||
269 | "??=". | ||
270 | Here is an example: | ||
271 | <literallayout class='monospaced'> | ||
272 | A ??= "somevalue" | ||
273 | A ??= "someothervalue" | ||
274 | </literallayout> | ||
275 | If <filename>A</filename> is set before the above statements are parsed, | ||
276 | the variable retains its value. | ||
277 | If <filename>A</filename> is not set, | ||
278 | the variable is set to "someothervalue". | ||
279 | </para> | ||
280 | |||
281 | <para> | ||
282 | Again, this assignment is a "lazy" or "weak" assignment | ||
283 | because it does not occur until the end | ||
284 | of the parsing process. | ||
285 | </para> | ||
286 | </section> | ||
287 | |||
288 | <section id='immediate-variable-expansion'> | ||
289 | <title>Immediate variable expansion (:=)</title> | ||
290 | |||
291 | <para> | ||
292 | The ":=" operator results in a variable's | ||
293 | contents being expanded immediately, | ||
294 | rather than when the variable is actually used: | ||
295 | <literallayout class='monospaced'> | ||
296 | T = "123" | ||
297 | A := "test ${T}" | ||
298 | T = "456" | ||
299 | B := "${T} ${C}" | ||
300 | C = "cval" | ||
301 | C := "${C}append" | ||
302 | </literallayout> | ||
303 | In this example, <filename>A</filename> contains | ||
304 | "test 123", even though the final value of <filename>T</filename> | ||
305 | is "456". | ||
306 | The variable <filename>B</filename> will end up containing "456 cvalappend". | ||
307 | This is because references to undefined variables are preserved as is | ||
308 | during (immediate)expansion. This is in contrast to GNU Make, where undefined | ||
309 | variables expand to nothing. | ||
310 | The variable <filename>C</filename> | ||
311 | contains "cvalappend" since <filename>${C}</filename> immediately | ||
312 | expands to "cval". | ||
313 | </para> | ||
314 | </section> | ||
315 | |||
316 | <section id='appending-and-prepending'> | ||
317 | <title>Appending (+=) and prepending (=+) With Spaces</title> | ||
318 | |||
319 | <para> | ||
320 | Appending and prepending values is common and can be accomplished | ||
321 | using the "+=" and "=+" operators. | ||
322 | These operators insert a space between the current | ||
323 | value and prepended or appended value. | ||
324 | </para> | ||
325 | |||
326 | <para> | ||
327 | These operators take immediate effect during parsing. | ||
328 | Here are some examples: | ||
329 | <literallayout class='monospaced'> | ||
330 | B = "bval" | ||
331 | B += "additionaldata" | ||
332 | C = "cval" | ||
333 | C =+ "test" | ||
334 | </literallayout> | ||
335 | The variable <filename>B</filename> contains | ||
336 | "bval additionaldata" and <filename>C</filename> | ||
337 | contains "test cval". | ||
338 | </para> | ||
339 | </section> | ||
340 | |||
341 | <section id='appending-and-prepending-without-spaces'> | ||
342 | <title>Appending (.=) and Prepending (=.) Without Spaces</title> | ||
343 | |||
344 | <para> | ||
345 | If you want to append or prepend values without an | ||
346 | inserted space, use the ".=" and "=." operators. | ||
347 | </para> | ||
348 | |||
349 | <para> | ||
350 | These operators take immediate effect during parsing. | ||
351 | Here are some examples: | ||
352 | <literallayout class='monospaced'> | ||
353 | B = "bval" | ||
354 | B .= "additionaldata" | ||
355 | C = "cval" | ||
356 | C =. "test" | ||
357 | </literallayout> | ||
358 | The variable <filename>B</filename> contains | ||
359 | "bvaladditionaldata" and | ||
360 | <filename>C</filename> contains "testcval". | ||
361 | </para> | ||
362 | </section> | ||
363 | |||
364 | <section id='appending-and-prepending-override-style-syntax'> | ||
365 | <title>Appending and Prepending (Override Style Syntax)</title> | ||
366 | |||
367 | <para> | ||
368 | You can also append and prepend a variable's value | ||
369 | using an override style syntax. | ||
370 | When you use this syntax, no spaces are inserted. | ||
371 | </para> | ||
372 | |||
373 | <para> | ||
374 | These operators differ from the ":=", ".=", "=.", "+=", and "=+" | ||
375 | operators in that their effects are applied at variable | ||
376 | expansion time rather than being immediately applied. | ||
377 | Here are some examples: | ||
378 | <literallayout class='monospaced'> | ||
379 | B = "bval" | ||
380 | B_append = " additional data" | ||
381 | C = "cval" | ||
382 | C_prepend = "additional data " | ||
383 | D = "dval" | ||
384 | D_append = "additional data" | ||
385 | </literallayout> | ||
386 | The variable <filename>B</filename> becomes | ||
387 | "bval additional data" and <filename>C</filename> becomes | ||
388 | "additional data cval". | ||
389 | The variable <filename>D</filename> becomes | ||
390 | "dvaladditional data". | ||
391 | <note> | ||
392 | You must control all spacing when you use the | ||
393 | override syntax. | ||
394 | </note> | ||
395 | </para> | ||
396 | |||
397 | <para> | ||
398 | It is also possible to append and prepend to shell | ||
399 | functions and BitBake-style Python functions. | ||
400 | See the | ||
401 | "<link linkend='shell-functions'>Shell Functions</link>" and | ||
402 | "<link linkend='bitbake-style-python-functions'>BitBake-Style Python Functions</link> | ||
403 | sections for examples. | ||
404 | </para> | ||
405 | </section> | ||
406 | |||
407 | <section id='removing-override-style-syntax'> | ||
408 | <title>Removal (Override Style Syntax)</title> | ||
409 | |||
410 | <para> | ||
411 | You can remove values from lists using the removal | ||
412 | override style syntax. | ||
413 | Specifying a value for removal causes all occurrences of that | ||
414 | value to be removed from the variable. | ||
415 | </para> | ||
416 | |||
417 | <para> | ||
418 | When you use this syntax, BitBake expects one or more strings. | ||
419 | Surrounding spaces and spacing are preserved. | ||
420 | Here is an example: | ||
421 | <literallayout class='monospaced'> | ||
422 | FOO = "123 456 789 123456 123 456 123 456" | ||
423 | FOO_remove = "123" | ||
424 | FOO_remove = "456" | ||
425 | FOO2 = " abc def ghi abcdef abc def abc def def" | ||
426 | FOO2_remove = " \ | ||
427 | def \ | ||
428 | abc \ | ||
429 | ghi \ | ||
430 | " | ||
431 | </literallayout> | ||
432 | The variable <filename>FOO</filename> becomes | ||
433 | " 789 123456 " | ||
434 | and <filename>FOO2</filename> becomes | ||
435 | " abcdef ". | ||
436 | </para> | ||
437 | |||
438 | <para> | ||
439 | Like "_append" and "_prepend", "_remove" | ||
440 | is applied at variable expansion time. | ||
441 | </para> | ||
442 | </section> | ||
443 | |||
444 | <section id='override-style-operation-advantages'> | ||
445 | <title>Override Style Operation Advantages</title> | ||
446 | |||
447 | <para> | ||
448 | An advantage of the override style operations | ||
449 | "_append", "_prepend", and "_remove" as compared to the | ||
450 | "+=" and "=+" operators is that the override style | ||
451 | operators provide guaranteed operations. | ||
452 | For example, consider a class <filename>foo.bbclass</filename> | ||
453 | that needs to add the value "val" to the variable | ||
454 | <filename>FOO</filename>, and a recipe that uses | ||
455 | <filename>foo.bbclass</filename> as follows: | ||
456 | <literallayout class='monospaced'> | ||
457 | inherit foo | ||
458 | |||
459 | FOO = "initial" | ||
460 | </literallayout> | ||
461 | If <filename>foo.bbclass</filename> uses the "+=" operator, | ||
462 | as follows, then the final value of <filename>FOO</filename> | ||
463 | will be "initial", which is not what is desired: | ||
464 | <literallayout class='monospaced'> | ||
465 | FOO += "val" | ||
466 | </literallayout> | ||
467 | If, on the other hand, <filename>foo.bbclass</filename> | ||
468 | uses the "_append" operator, then the final value of | ||
469 | <filename>FOO</filename> will be "initial val", as intended: | ||
470 | <literallayout class='monospaced'> | ||
471 | FOO_append = " val" | ||
472 | </literallayout> | ||
473 | <note> | ||
474 | It is never necessary to use "+=" together with "_append". | ||
475 | The following sequence of assignments appends "barbaz" to | ||
476 | <filename>FOO</filename>: | ||
477 | <literallayout class='monospaced'> | ||
478 | FOO_append = "bar" | ||
479 | FOO_append = "baz" | ||
480 | </literallayout> | ||
481 | The only effect of changing the second assignment in the | ||
482 | previous example to use "+=" would be to add a space before | ||
483 | "baz" in the appended value (due to how the "+=" operator | ||
484 | works). | ||
485 | </note> | ||
486 | Another advantage of the override style operations is that | ||
487 | you can combine them with other overrides as described in the | ||
488 | "<link linkend='conditional-syntax-overrides'>Conditional Syntax (Overrides)</link>" | ||
489 | section. | ||
490 | </para> | ||
491 | </section> | ||
492 | |||
493 | <section id='variable-flag-syntax'> | ||
494 | <title>Variable Flag Syntax</title> | ||
495 | |||
496 | <para> | ||
497 | Variable flags are BitBake's implementation of variable properties | ||
498 | or attributes. | ||
499 | It is a way of tagging extra information onto a variable. | ||
500 | You can find more out about variable flags in general in the | ||
501 | "<link linkend='variable-flags'>Variable Flags</link>" | ||
502 | section. | ||
503 | </para> | ||
504 | |||
505 | <para> | ||
506 | You can define, append, and prepend values to variable flags. | ||
507 | All the standard syntax operations previously mentioned work | ||
508 | for variable flags except for override style syntax | ||
509 | (i.e. "_prepend", "_append", and "_remove"). | ||
510 | </para> | ||
511 | |||
512 | <para> | ||
513 | Here are some examples showing how to set variable flags: | ||
514 | <literallayout class='monospaced'> | ||
515 | FOO[a] = "abc" | ||
516 | FOO[b] = "123" | ||
517 | FOO[a] += "456" | ||
518 | </literallayout> | ||
519 | The variable <filename>FOO</filename> has two flags: | ||
520 | <filename>[a]</filename> and <filename>[b]</filename>. | ||
521 | The flags are immediately set to "abc" and "123", respectively. | ||
522 | The <filename>[a]</filename> flag becomes "abc 456". | ||
523 | </para> | ||
524 | |||
525 | <para> | ||
526 | No need exists to pre-define variable flags. | ||
527 | You can simply start using them. | ||
528 | One extremely common application | ||
529 | is to attach some brief documentation to a BitBake variable as | ||
530 | follows: | ||
531 | <literallayout class='monospaced'> | ||
532 | CACHE[doc] = "The directory holding the cache of the metadata." | ||
533 | </literallayout> | ||
534 | </para> | ||
535 | </section> | ||
536 | |||
537 | <section id='inline-python-variable-expansion'> | ||
538 | <title>Inline Python Variable Expansion</title> | ||
539 | |||
540 | <para> | ||
541 | You can use inline Python variable expansion to | ||
542 | set variables. | ||
543 | Here is an example: | ||
544 | <literallayout class='monospaced'> | ||
545 | DATE = "${@time.strftime('%Y%m%d',time.gmtime())}" | ||
546 | </literallayout> | ||
547 | This example results in the <filename>DATE</filename> | ||
548 | variable being set to the current date. | ||
549 | </para> | ||
550 | |||
551 | <para> | ||
552 | Probably the most common use of this feature is to extract | ||
553 | the value of variables from BitBake's internal data dictionary, | ||
554 | <filename>d</filename>. | ||
555 | The following lines select the values of a package name | ||
556 | and its version number, respectively: | ||
557 | <literallayout class='monospaced'> | ||
558 | PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" | ||
559 | PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" | ||
560 | </literallayout> | ||
561 | <note> | ||
562 | Inline Python expressions work just like variable expansions | ||
563 | insofar as the "=" and ":=" operators are concerned. | ||
564 | Given the following assignment, <filename>foo()</filename> | ||
565 | is called each time <filename>FOO</filename> is expanded: | ||
566 | <literallayout class='monospaced'> | ||
567 | FOO = "${@foo()}" | ||
568 | </literallayout> | ||
569 | Contrast this with the following immediate assignment, where | ||
570 | <filename>foo()</filename> is only called once, while the | ||
571 | assignment is parsed: | ||
572 | <literallayout class='monospaced'> | ||
573 | FOO := "${@foo()}" | ||
574 | </literallayout> | ||
575 | </note> | ||
576 | For a different way to set variables with Python code during | ||
577 | parsing, see the | ||
578 | "<link linkend='anonymous-python-functions'>Anonymous Python Functions</link>" | ||
579 | section. | ||
580 | </para> | ||
581 | </section> | ||
582 | |||
583 | <section id='unsetting-variables'> | ||
584 | <title>Unsetting variables</title> | ||
585 | |||
586 | <para> | ||
587 | It is possible to completely remove a variable or a variable flag | ||
588 | from BitBake's internal data dictionary by using the "unset" keyword. | ||
589 | Here is an example: | ||
590 | <literallayout class='monospaced'> | ||
591 | unset DATE | ||
592 | unset do_fetch[noexec] | ||
593 | </literallayout> | ||
594 | These two statements remove the <filename>DATE</filename> and the | ||
595 | <filename>do_fetch[noexec]</filename> flag. | ||
596 | </para> | ||
597 | |||
598 | </section> | ||
599 | |||
600 | <section id='providing-pathnames'> | ||
601 | <title>Providing Pathnames</title> | ||
602 | |||
603 | <para> | ||
604 | When specifying pathnames for use with BitBake, | ||
605 | do not use the tilde ("~") character as a shortcut | ||
606 | for your home directory. | ||
607 | Doing so might cause BitBake to not recognize the | ||
608 | path since BitBake does not expand this character in | ||
609 | the same way a shell would. | ||
610 | </para> | ||
611 | |||
612 | <para> | ||
613 | Instead, provide a fuller path as the following | ||
614 | example illustrates: | ||
615 | <literallayout class='monospaced'> | ||
616 | BBLAYERS ?= " \ | ||
617 | /home/scott-lenovo/LayerA \ | ||
618 | " | ||
619 | </literallayout> | ||
620 | </para> | ||
621 | </section> | ||
622 | </section> | ||
623 | |||
624 | <section id='exporting-variables-to-the-environment'> | ||
625 | <title>Exporting Variables to the Environment</title> | ||
626 | |||
627 | <para> | ||
628 | You can export variables to the environment of running | ||
629 | tasks by using the <filename>export</filename> keyword. | ||
630 | For example, in the following example, the | ||
631 | <filename>do_foo</filename> task prints "value from | ||
632 | the environment" when run: | ||
633 | <literallayout class='monospaced'> | ||
634 | export ENV_VARIABLE | ||
635 | ENV_VARIABLE = "value from the environment" | ||
636 | |||
637 | do_foo() { | ||
638 | bbplain "$ENV_VARIABLE" | ||
639 | } | ||
640 | </literallayout> | ||
641 | <note> | ||
642 | BitBake does not expand <filename>$ENV_VARIABLE</filename> | ||
643 | in this case because it lacks the obligatory | ||
644 | <filename>{}</filename>. | ||
645 | Rather, <filename>$ENV_VARIABLE</filename> is expanded | ||
646 | by the shell. | ||
647 | </note> | ||
648 | It does not matter whether | ||
649 | <filename>export ENV_VARIABLE</filename> appears before or | ||
650 | after assignments to <filename>ENV_VARIABLE</filename>. | ||
651 | </para> | ||
652 | |||
653 | <para> | ||
654 | It is also possible to combine <filename>export</filename> | ||
655 | with setting a value for the variable. | ||
656 | Here is an example: | ||
657 | <literallayout class='monospaced'> | ||
658 | export ENV_VARIABLE = "<replaceable>variable-value</replaceable>" | ||
659 | </literallayout> | ||
660 | In the output of <filename>bitbake -e</filename>, variables | ||
661 | that are exported to the environment are preceded by "export". | ||
662 | </para> | ||
663 | |||
664 | <para> | ||
665 | Among the variables commonly exported to the environment | ||
666 | are <filename>CC</filename> and <filename>CFLAGS</filename>, | ||
667 | which are picked up by many build systems. | ||
668 | </para> | ||
669 | </section> | ||
670 | |||
671 | <section id='conditional-syntax-overrides'> | ||
672 | <title>Conditional Syntax (Overrides)</title> | ||
673 | |||
674 | <para> | ||
675 | BitBake uses | ||
676 | <link linkend='var-bb-OVERRIDES'><filename>OVERRIDES</filename></link> | ||
677 | to control what variables are overridden after BitBake | ||
678 | parses recipes and configuration files. | ||
679 | This section describes how you can use | ||
680 | <filename>OVERRIDES</filename> as conditional metadata, | ||
681 | talks about key expansion in relationship to | ||
682 | <filename>OVERRIDES</filename>, and provides some examples | ||
683 | to help with understanding. | ||
684 | </para> | ||
685 | |||
686 | <section id='conditional-metadata'> | ||
687 | <title>Conditional Metadata</title> | ||
688 | |||
689 | <para> | ||
690 | You can use <filename>OVERRIDES</filename> to conditionally select | ||
691 | a specific version of a variable and to conditionally | ||
692 | append or prepend the value of a variable. | ||
693 | <note> | ||
694 | Overrides can only use lower-case characters. | ||
695 | Additionally, underscores are not permitted in override names | ||
696 | as they are used to separate overrides from each other and | ||
697 | from the variable name. | ||
698 | </note> | ||
699 | <itemizedlist> | ||
700 | <listitem><para><emphasis>Selecting a Variable:</emphasis> | ||
701 | The <filename>OVERRIDES</filename> variable is | ||
702 | a colon-character-separated list that contains items | ||
703 | for which you want to satisfy conditions. | ||
704 | Thus, if you have a variable that is conditional on “armâ€, and “arm†| ||
705 | is in <filename>OVERRIDES</filename>, then the “armâ€-specific | ||
706 | version of the variable is used rather than the non-conditional | ||
707 | version. | ||
708 | Here is an example: | ||
709 | <literallayout class='monospaced'> | ||
710 | OVERRIDES = "architecture:os:machine" | ||
711 | TEST = "default" | ||
712 | TEST_os = "osspecific" | ||
713 | TEST_nooverride = "othercondvalue" | ||
714 | </literallayout> | ||
715 | In this example, the <filename>OVERRIDES</filename> | ||
716 | variable lists three overrides: | ||
717 | "architecture", "os", and "machine". | ||
718 | The variable <filename>TEST</filename> by itself has a default | ||
719 | value of "default". | ||
720 | You select the os-specific version of the <filename>TEST</filename> | ||
721 | variable by appending the "os" override to the variable | ||
722 | (i.e.<filename>TEST_os</filename>). | ||
723 | </para> | ||
724 | |||
725 | <para> | ||
726 | To better understand this, consider a practical example | ||
727 | that assumes an OpenEmbedded metadata-based Linux | ||
728 | kernel recipe file. | ||
729 | The following lines from the recipe file first set | ||
730 | the kernel branch variable <filename>KBRANCH</filename> | ||
731 | to a default value, then conditionally override that | ||
732 | value based on the architecture of the build: | ||
733 | <literallayout class='monospaced'> | ||
734 | KBRANCH = "standard/base" | ||
735 | KBRANCH_qemuarm = "standard/arm-versatile-926ejs" | ||
736 | KBRANCH_qemumips = "standard/mti-malta32" | ||
737 | KBRANCH_qemuppc = "standard/qemuppc" | ||
738 | KBRANCH_qemux86 = "standard/common-pc/base" | ||
739 | KBRANCH_qemux86-64 = "standard/common-pc-64/base" | ||
740 | KBRANCH_qemumips64 = "standard/mti-malta64" | ||
741 | </literallayout> | ||
742 | </para></listitem> | ||
743 | <listitem><para><emphasis>Appending and Prepending:</emphasis> | ||
744 | BitBake also supports append and prepend operations to | ||
745 | variable values based on whether a specific item is | ||
746 | listed in <filename>OVERRIDES</filename>. | ||
747 | Here is an example: | ||
748 | <literallayout class='monospaced'> | ||
749 | DEPENDS = "glibc ncurses" | ||
750 | OVERRIDES = "machine:local" | ||
751 | DEPENDS_append_machine = " libmad" | ||
752 | </literallayout> | ||
753 | In this example, <filename>DEPENDS</filename> becomes | ||
754 | "glibc ncurses libmad". | ||
755 | </para> | ||
756 | |||
757 | <para> | ||
758 | Again, using an OpenEmbedded metadata-based | ||
759 | kernel recipe file as an example, the | ||
760 | following lines will conditionally append to the | ||
761 | <filename>KERNEL_FEATURES</filename> variable based | ||
762 | on the architecture: | ||
763 | <literallayout class='monospaced'> | ||
764 | KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" | ||
765 | KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" | ||
766 | KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" | ||
767 | </literallayout> | ||
768 | </para></listitem> | ||
769 | <listitem><para><emphasis>Setting a Variable for a Single Task:</emphasis> | ||
770 | BitBake supports setting a variable just for the | ||
771 | duration of a single task. | ||
772 | Here is an example: | ||
773 | <literallayout class='monospaced'> | ||
774 | FOO_task-configure = "val 1" | ||
775 | FOO_task-compile = "val 2" | ||
776 | </literallayout> | ||
777 | In the previous example, <filename>FOO</filename> | ||
778 | has the value "val 1" while the | ||
779 | <filename>do_configure</filename> task is executed, | ||
780 | and the value "val 2" while the | ||
781 | <filename>do_compile</filename> task is executed. | ||
782 | </para> | ||
783 | |||
784 | <para>Internally, this is implemented by prepending | ||
785 | the task (e.g. "task-compile:") to the value of | ||
786 | <link linkend='var-bb-OVERRIDES'><filename>OVERRIDES</filename></link> | ||
787 | for the local datastore of the <filename>do_compile</filename> | ||
788 | task.</para> | ||
789 | |||
790 | <para>You can also use this syntax with other combinations | ||
791 | (e.g. "<filename>_prepend</filename>") as shown in the | ||
792 | following example: | ||
793 | <literallayout class='monospaced'> | ||
794 | EXTRA_OEMAKE_prepend_task-compile = "${PARALLEL_MAKE} " | ||
795 | </literallayout> | ||
796 | </para></listitem> | ||
797 | </itemizedlist> | ||
798 | </para> | ||
799 | </section> | ||
800 | |||
801 | <section id='key-expansion'> | ||
802 | <title>Key Expansion</title> | ||
803 | |||
804 | <para> | ||
805 | Key expansion happens when the BitBake datastore is finalized. | ||
806 | To better understand this, consider the following example: | ||
807 | <literallayout class='monospaced'> | ||
808 | A${B} = "X" | ||
809 | B = "2" | ||
810 | A2 = "Y" | ||
811 | </literallayout> | ||
812 | In this case, after all the parsing is complete, | ||
813 | BitBake expands <filename>${B}</filename> into "2". | ||
814 | This expansion causes <filename>A2</filename>, which was | ||
815 | set to "Y" before the expansion, to become "X". | ||
816 | </para> | ||
817 | </section> | ||
818 | |||
819 | <section id='variable-interaction-worked-examples'> | ||
820 | <title>Examples</title> | ||
821 | |||
822 | <para> | ||
823 | Despite the previous explanations that show the different forms of | ||
824 | variable definitions, it can be hard to work | ||
825 | out exactly what happens when variable operators, conditional | ||
826 | overrides, and unconditional overrides are combined. | ||
827 | This section presents some common scenarios along | ||
828 | with explanations for variable interactions that | ||
829 | typically confuse users. | ||
830 | </para> | ||
831 | |||
832 | <para> | ||
833 | There is often confusion concerning the order in which | ||
834 | overrides and various "append" operators take effect. | ||
835 | Recall that an append or prepend operation using "_append" | ||
836 | and "_prepend" does not result in an immediate assignment | ||
837 | as would "+=", ".=", "=+", or "=.". | ||
838 | Consider the following example: | ||
839 | <literallayout class='monospaced'> | ||
840 | OVERRIDES = "foo" | ||
841 | A = "Z" | ||
842 | A_foo_append = "X" | ||
843 | </literallayout> | ||
844 | For this case, <filename>A</filename> is | ||
845 | unconditionally set to "Z" and "X" is | ||
846 | unconditionally and immediately appended to the variable | ||
847 | <filename>A_foo</filename>. | ||
848 | Because overrides have not been applied yet, | ||
849 | <filename>A_foo</filename> is set to "X" due to the append | ||
850 | and <filename>A</filename> simply equals "Z". | ||
851 | </para> | ||
852 | |||
853 | <para> | ||
854 | Applying overrides, however, changes things. | ||
855 | Since "foo" is listed in <filename>OVERRIDES</filename>, | ||
856 | the conditional variable <filename>A</filename> is replaced | ||
857 | with the "foo" version, which is equal to "X". | ||
858 | So effectively, <filename>A_foo</filename> replaces <filename>A</filename>. | ||
859 | </para> | ||
860 | |||
861 | <para> | ||
862 | This next example changes the order of the override and | ||
863 | the append: | ||
864 | <literallayout class='monospaced'> | ||
865 | OVERRIDES = "foo" | ||
866 | A = "Z" | ||
867 | A_append_foo = "X" | ||
868 | </literallayout> | ||
869 | For this case, before overrides are handled, | ||
870 | <filename>A</filename> is set to "Z" and <filename>A_append_foo</filename> | ||
871 | is set to "X". | ||
872 | Once the override for "foo" is applied, however, | ||
873 | <filename>A</filename> gets appended with "X". | ||
874 | Consequently, <filename>A</filename> becomes "ZX". | ||
875 | Notice that spaces are not appended. | ||
876 | </para> | ||
877 | |||
878 | <para> | ||
879 | This next example has the order of the appends and overrides reversed | ||
880 | back as in the first example: | ||
881 | <literallayout class='monospaced'> | ||
882 | OVERRIDES = "foo" | ||
883 | A = "Y" | ||
884 | A_foo_append = "Z" | ||
885 | A_foo_append = "X" | ||
886 | </literallayout> | ||
887 | For this case, before any overrides are resolved, | ||
888 | <filename>A</filename> is set to "Y" using an immediate assignment. | ||
889 | After this immediate assignment, <filename>A_foo</filename> is set | ||
890 | to "Z", and then further appended with | ||
891 | "X" leaving the variable set to "ZX". | ||
892 | Finally, applying the override for "foo" results in the conditional | ||
893 | variable <filename>A</filename> becoming "ZX" (i.e. | ||
894 | <filename>A</filename> is replaced with <filename>A_foo</filename>). | ||
895 | </para> | ||
896 | |||
897 | <para> | ||
898 | This final example mixes in some varying operators: | ||
899 | <literallayout class='monospaced'> | ||
900 | A = "1" | ||
901 | A_append = "2" | ||
902 | A_append = "3" | ||
903 | A += "4" | ||
904 | A .= "5" | ||
905 | </literallayout> | ||
906 | For this case, the type of append operators are affecting the | ||
907 | order of assignments as BitBake passes through the code | ||
908 | multiple times. | ||
909 | Initially, <filename>A</filename> is set to "1 45" because | ||
910 | of the three statements that use immediate operators. | ||
911 | After these assignments are made, BitBake applies the | ||
912 | "_append" operations. | ||
913 | Those operations result in <filename>A</filename> becoming "1 4523". | ||
914 | </para> | ||
915 | </section> | ||
916 | </section> | ||
917 | |||
918 | <section id='sharing-functionality'> | ||
919 | <title>Sharing Functionality</title> | ||
920 | |||
921 | <para> | ||
922 | BitBake allows for metadata sharing through include files | ||
923 | (<filename>.inc</filename>) and class files | ||
924 | (<filename>.bbclass</filename>). | ||
925 | For example, suppose you have a piece of common functionality | ||
926 | such as a task definition that you want to share between | ||
927 | more than one recipe. | ||
928 | In this case, creating a <filename>.bbclass</filename> | ||
929 | file that contains the common functionality and then using | ||
930 | the <filename>inherit</filename> directive in your recipes to | ||
931 | inherit the class would be a common way to share the task. | ||
932 | </para> | ||
933 | |||
934 | <para> | ||
935 | This section presents the mechanisms BitBake provides to | ||
936 | allow you to share functionality between recipes. | ||
937 | Specifically, the mechanisms include <filename>include</filename>, | ||
938 | <filename>inherit</filename>, <filename>INHERIT</filename>, and | ||
939 | <filename>require</filename> directives. | ||
940 | </para> | ||
941 | |||
942 | <section id='locating-include-and-class-files'> | ||
943 | <title>Locating Include and Class Files</title> | ||
944 | |||
945 | <para> | ||
946 | BitBake uses the | ||
947 | <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link> | ||
948 | variable to locate needed include and class files. | ||
949 | Additionally, BitBake searches the current directory for | ||
950 | <filename>include</filename> and <filename>require</filename> | ||
951 | directives. | ||
952 | <note> | ||
953 | The <filename>BBPATH</filename> variable is analogous to | ||
954 | the environment variable <filename>PATH</filename>. | ||
955 | </note> | ||
956 | </para> | ||
957 | |||
958 | <para> | ||
959 | In order for include and class files to be found by BitBake, | ||
960 | they need to be located in a "classes" subdirectory that can | ||
961 | be found in <filename>BBPATH</filename>. | ||
962 | </para> | ||
963 | </section> | ||
964 | |||
965 | <section id='inherit-directive'> | ||
966 | <title><filename>inherit</filename> Directive</title> | ||
967 | |||
968 | <para> | ||
969 | When writing a recipe or class file, you can use the | ||
970 | <filename>inherit</filename> directive to inherit the | ||
971 | functionality of a class (<filename>.bbclass</filename>). | ||
972 | BitBake only supports this directive when used within recipe | ||
973 | and class files (i.e. <filename>.bb</filename> and | ||
974 | <filename>.bbclass</filename>). | ||
975 | </para> | ||
976 | |||
977 | <para> | ||
978 | The <filename>inherit</filename> directive is a rudimentary | ||
979 | means of specifying functionality contained in class files | ||
980 | that your recipes require. | ||
981 | For example, you can easily abstract out the tasks involved in | ||
982 | building a package that uses Autoconf and Automake and put | ||
983 | those tasks into a class file and then have your recipe | ||
984 | inherit that class file. | ||
985 | </para> | ||
986 | |||
987 | <para> | ||
988 | As an example, your recipes could use the following directive | ||
989 | to inherit an <filename>autotools.bbclass</filename> file. | ||
990 | The class file would contain common functionality for using | ||
991 | Autotools that could be shared across recipes: | ||
992 | <literallayout class='monospaced'> | ||
993 | inherit autotools | ||
994 | </literallayout> | ||
995 | In this case, BitBake would search for the directory | ||
996 | <filename>classes/autotools.bbclass</filename> | ||
997 | in <filename>BBPATH</filename>. | ||
998 | <note> | ||
999 | You can override any values and functions of the | ||
1000 | inherited class within your recipe by doing so | ||
1001 | after the "inherit" statement. | ||
1002 | </note> | ||
1003 | If you want to use the directive to inherit | ||
1004 | multiple classes, separate them with spaces. | ||
1005 | The following example shows how to inherit both the | ||
1006 | <filename>buildhistory</filename> and <filename>rm_work</filename> | ||
1007 | classes: | ||
1008 | <literallayout class='monospaced'> | ||
1009 | inherit buildhistory rm_work | ||
1010 | </literallayout> | ||
1011 | </para> | ||
1012 | |||
1013 | <para> | ||
1014 | An advantage with the inherit directive as compared to both | ||
1015 | the | ||
1016 | <link linkend='include-directive'>include</link> and | ||
1017 | <link linkend='require-inclusion'>require</link> directives | ||
1018 | is that you can inherit class files conditionally. | ||
1019 | You can accomplish this by using a variable expression | ||
1020 | after the <filename>inherit</filename> statement. | ||
1021 | Here is an example: | ||
1022 | <literallayout class='monospaced'> | ||
1023 | inherit ${VARNAME} | ||
1024 | </literallayout> | ||
1025 | If <filename>VARNAME</filename> is going to be set, it needs | ||
1026 | to be set before the <filename>inherit</filename> statement | ||
1027 | is parsed. | ||
1028 | One way to achieve a conditional inherit in this case is to use | ||
1029 | overrides: | ||
1030 | <literallayout class='monospaced'> | ||
1031 | VARIABLE = "" | ||
1032 | VARIABLE_someoverride = "myclass" | ||
1033 | </literallayout> | ||
1034 | </para> | ||
1035 | |||
1036 | <para> | ||
1037 | Another method is by using anonymous Python. | ||
1038 | Here is an example: | ||
1039 | <literallayout class='monospaced'> | ||
1040 | python () { | ||
1041 | if condition == value: | ||
1042 | d.setVar('VARIABLE', 'myclass') | ||
1043 | else: | ||
1044 | d.setVar('VARIABLE', '') | ||
1045 | } | ||
1046 | </literallayout> | ||
1047 | </para> | ||
1048 | |||
1049 | <para> | ||
1050 | Alternatively, you could use an in-line Python expression | ||
1051 | in the following form: | ||
1052 | <literallayout class='monospaced'> | ||
1053 | inherit ${@'classname' if condition else ''} | ||
1054 | inherit ${@functionname(params)} | ||
1055 | </literallayout> | ||
1056 | In all cases, if the expression evaluates to an empty | ||
1057 | string, the statement does not trigger a syntax error | ||
1058 | because it becomes a no-op. | ||
1059 | </para> | ||
1060 | </section> | ||
1061 | |||
1062 | <section id='include-directive'> | ||
1063 | <title><filename>include</filename> Directive</title> | ||
1064 | |||
1065 | <para> | ||
1066 | BitBake understands the <filename>include</filename> | ||
1067 | directive. | ||
1068 | This directive causes BitBake to parse whatever file you specify, | ||
1069 | and to insert that file at that location. | ||
1070 | The directive is much like its equivalent in Make except | ||
1071 | that if the path specified on the include line is a relative | ||
1072 | path, BitBake locates the first file it can find | ||
1073 | within <filename>BBPATH</filename>. | ||
1074 | </para> | ||
1075 | |||
1076 | <para> | ||
1077 | The include directive is a more generic method of including | ||
1078 | functionality as compared to the | ||
1079 | <link linkend='inherit-directive'>inherit</link> directive, | ||
1080 | which is restricted to class (i.e. <filename>.bbclass</filename>) | ||
1081 | files. | ||
1082 | The include directive is applicable for any other kind of | ||
1083 | shared or encapsulated functionality or configuration that | ||
1084 | does not suit a <filename>.bbclass</filename> file. | ||
1085 | </para> | ||
1086 | |||
1087 | <para> | ||
1088 | As an example, suppose you needed a recipe to include some | ||
1089 | self-test definitions: | ||
1090 | <literallayout class='monospaced'> | ||
1091 | include test_defs.inc | ||
1092 | </literallayout> | ||
1093 | <note> | ||
1094 | The <filename>include</filename> directive does not | ||
1095 | produce an error when the file cannot be found. | ||
1096 | Consequently, it is recommended that if the file you | ||
1097 | are including is expected to exist, you should use | ||
1098 | <link linkend='require-inclusion'><filename>require</filename></link> | ||
1099 | instead of <filename>include</filename>. | ||
1100 | Doing so makes sure that an error is produced if the | ||
1101 | file cannot be found. | ||
1102 | </note> | ||
1103 | </para> | ||
1104 | </section> | ||
1105 | |||
1106 | <section id='require-inclusion'> | ||
1107 | <title><filename>require</filename> Directive</title> | ||
1108 | |||
1109 | <para> | ||
1110 | BitBake understands the <filename>require</filename> | ||
1111 | directive. | ||
1112 | This directive behaves just like the | ||
1113 | <filename>include</filename> directive with the exception that | ||
1114 | BitBake raises a parsing error if the file to be included cannot | ||
1115 | be found. | ||
1116 | Thus, any file you require is inserted into the file that is | ||
1117 | being parsed at the location of the directive. | ||
1118 | </para> | ||
1119 | |||
1120 | <para> | ||
1121 | The require directive, like the include directive previously | ||
1122 | described, is a more generic method of including | ||
1123 | functionality as compared to the | ||
1124 | <link linkend='inherit-directive'>inherit</link> directive, | ||
1125 | which is restricted to class (i.e. <filename>.bbclass</filename>) | ||
1126 | files. | ||
1127 | The require directive is applicable for any other kind of | ||
1128 | shared or encapsulated functionality or configuration that | ||
1129 | does not suit a <filename>.bbclass</filename> file. | ||
1130 | </para> | ||
1131 | |||
1132 | <para> | ||
1133 | Similar to how BitBake handles | ||
1134 | <link linkend='include-directive'><filename>include</filename></link>, | ||
1135 | if the path specified | ||
1136 | on the require line is a relative path, BitBake locates | ||
1137 | the first file it can find within <filename>BBPATH</filename>. | ||
1138 | </para> | ||
1139 | |||
1140 | <para> | ||
1141 | As an example, suppose you have two versions of a recipe | ||
1142 | (e.g. <filename>foo_1.2.2.bb</filename> and | ||
1143 | <filename>foo_2.0.0.bb</filename>) where | ||
1144 | each version contains some identical functionality that could be | ||
1145 | shared. | ||
1146 | You could create an include file named <filename>foo.inc</filename> | ||
1147 | that contains the common definitions needed to build "foo". | ||
1148 | You need to be sure <filename>foo.inc</filename> is located in the | ||
1149 | same directory as your two recipe files as well. | ||
1150 | Once these conditions are set up, you can share the functionality | ||
1151 | using a <filename>require</filename> directive from within each | ||
1152 | recipe: | ||
1153 | <literallayout class='monospaced'> | ||
1154 | require foo.inc | ||
1155 | </literallayout> | ||
1156 | </para> | ||
1157 | </section> | ||
1158 | |||
1159 | <section id='inherit-configuration-directive'> | ||
1160 | <title><filename>INHERIT</filename> Configuration Directive</title> | ||
1161 | |||
1162 | <para> | ||
1163 | When creating a configuration file (<filename>.conf</filename>), | ||
1164 | you can use the | ||
1165 | <link linkend='var-bb-INHERIT'><filename>INHERIT</filename></link> | ||
1166 | configuration directive to inherit a class. | ||
1167 | BitBake only supports this directive when used within | ||
1168 | a configuration file. | ||
1169 | </para> | ||
1170 | |||
1171 | <para> | ||
1172 | As an example, suppose you needed to inherit a class | ||
1173 | file called <filename>abc.bbclass</filename> from a | ||
1174 | configuration file as follows: | ||
1175 | <literallayout class='monospaced'> | ||
1176 | INHERIT += "abc" | ||
1177 | </literallayout> | ||
1178 | This configuration directive causes the named | ||
1179 | class to be inherited at the point of the directive | ||
1180 | during parsing. | ||
1181 | As with the <filename>inherit</filename> directive, the | ||
1182 | <filename>.bbclass</filename> file must be located in a | ||
1183 | "classes" subdirectory in one of the directories specified | ||
1184 | in <filename>BBPATH</filename>. | ||
1185 | <note> | ||
1186 | Because <filename>.conf</filename> files are parsed | ||
1187 | first during BitBake's execution, using | ||
1188 | <filename>INHERIT</filename> to inherit a class effectively | ||
1189 | inherits the class globally (i.e. for all recipes). | ||
1190 | </note> | ||
1191 | If you want to use the directive to inherit | ||
1192 | multiple classes, you can provide them on the same line in the | ||
1193 | <filename>local.conf</filename> file. | ||
1194 | Use spaces to separate the classes. | ||
1195 | The following example shows how to inherit both the | ||
1196 | <filename>autotools</filename> and <filename>pkgconfig</filename> | ||
1197 | classes: | ||
1198 | <literallayout class='monospaced'> | ||
1199 | INHERIT += "autotools pkgconfig" | ||
1200 | </literallayout> | ||
1201 | </para> | ||
1202 | </section> | ||
1203 | </section> | ||
1204 | |||
1205 | <section id='functions'> | ||
1206 | <title>Functions</title> | ||
1207 | |||
1208 | <para> | ||
1209 | As with most languages, functions are the building blocks that | ||
1210 | are used to build up operations into tasks. | ||
1211 | BitBake supports these types of functions: | ||
1212 | <itemizedlist> | ||
1213 | <listitem><para><emphasis>Shell Functions:</emphasis> | ||
1214 | Functions written in shell script and executed either | ||
1215 | directly as functions, tasks, or both. | ||
1216 | They can also be called by other shell functions. | ||
1217 | </para></listitem> | ||
1218 | <listitem><para><emphasis>BitBake-Style Python Functions:</emphasis> | ||
1219 | Functions written in Python and executed by BitBake or other | ||
1220 | Python functions using <filename>bb.build.exec_func()</filename>. | ||
1221 | </para></listitem> | ||
1222 | <listitem><para><emphasis>Python Functions:</emphasis> | ||
1223 | Functions written in Python and executed by Python. | ||
1224 | </para></listitem> | ||
1225 | <listitem><para><emphasis>Anonymous Python Functions:</emphasis> | ||
1226 | Python functions executed automatically during | ||
1227 | parsing. | ||
1228 | </para></listitem> | ||
1229 | </itemizedlist> | ||
1230 | Regardless of the type of function, you can only | ||
1231 | define them in class (<filename>.bbclass</filename>) | ||
1232 | and recipe (<filename>.bb</filename> or <filename>.inc</filename>) | ||
1233 | files. | ||
1234 | </para> | ||
1235 | |||
1236 | <section id='shell-functions'> | ||
1237 | <title>Shell Functions</title> | ||
1238 | |||
1239 | <para> | ||
1240 | Functions written in shell script and executed either | ||
1241 | directly as functions, tasks, or both. | ||
1242 | They can also be called by other shell functions. | ||
1243 | Here is an example shell function definition: | ||
1244 | <literallayout class='monospaced'> | ||
1245 | some_function () { | ||
1246 | echo "Hello World" | ||
1247 | } | ||
1248 | </literallayout> | ||
1249 | When you create these types of functions in your recipe | ||
1250 | or class files, you need to follow the shell programming | ||
1251 | rules. | ||
1252 | The scripts are executed by <filename>/bin/sh</filename>, | ||
1253 | which may not be a bash shell but might be something | ||
1254 | such as <filename>dash</filename>. | ||
1255 | You should not use Bash-specific script (bashisms). | ||
1256 | </para> | ||
1257 | |||
1258 | <para> | ||
1259 | Overrides and override-style operators like | ||
1260 | <filename>_append</filename> and | ||
1261 | <filename>_prepend</filename> can also be applied to | ||
1262 | shell functions. | ||
1263 | Most commonly, this application would be used in a | ||
1264 | <filename>.bbappend</filename> file to modify functions in | ||
1265 | the main recipe. | ||
1266 | It can also be used to modify functions inherited from | ||
1267 | classes. | ||
1268 | </para> | ||
1269 | |||
1270 | <para> | ||
1271 | As an example, consider the following: | ||
1272 | <literallayout class='monospaced'> | ||
1273 | do_foo() { | ||
1274 | bbplain first | ||
1275 | fn | ||
1276 | } | ||
1277 | |||
1278 | fn_prepend() { | ||
1279 | bbplain second | ||
1280 | } | ||
1281 | |||
1282 | fn() { | ||
1283 | bbplain third | ||
1284 | } | ||
1285 | |||
1286 | do_foo_append() { | ||
1287 | bbplain fourth | ||
1288 | } | ||
1289 | </literallayout> | ||
1290 | Running <filename>do_foo</filename> | ||
1291 | prints the following: | ||
1292 | <literallayout class='monospaced'> | ||
1293 | recipename do_foo: first | ||
1294 | recipename do_foo: second | ||
1295 | recipename do_foo: third | ||
1296 | recipename do_foo: fourth | ||
1297 | </literallayout> | ||
1298 | <note> | ||
1299 | Overrides and override-style operators can | ||
1300 | be applied to any shell function, not just | ||
1301 | <link linkend='tasks'>tasks</link>. | ||
1302 | </note> | ||
1303 | You can use the <filename>bitbake -e</filename> <replaceable>recipename</replaceable> | ||
1304 | command to view the final assembled function | ||
1305 | after all overrides have been applied. | ||
1306 | </para> | ||
1307 | </section> | ||
1308 | |||
1309 | <section id='bitbake-style-python-functions'> | ||
1310 | <title>BitBake-Style Python Functions</title> | ||
1311 | |||
1312 | <para> | ||
1313 | These functions are written in Python and executed by | ||
1314 | BitBake or other Python functions using | ||
1315 | <filename>bb.build.exec_func()</filename>. | ||
1316 | </para> | ||
1317 | |||
1318 | <para> | ||
1319 | An example BitBake function is: | ||
1320 | <literallayout class='monospaced'> | ||
1321 | python some_python_function () { | ||
1322 | d.setVar("TEXT", "Hello World") | ||
1323 | print d.getVar("TEXT") | ||
1324 | } | ||
1325 | </literallayout> | ||
1326 | Because the Python "bb" and "os" modules are already | ||
1327 | imported, you do not need to import these modules. | ||
1328 | Also in these types of functions, the datastore ("d") | ||
1329 | is a global variable and is always automatically | ||
1330 | available. | ||
1331 | <note> | ||
1332 | Variable expressions (e.g. <filename>${X}</filename>) | ||
1333 | are no longer expanded within Python functions. | ||
1334 | This behavior is intentional in order to allow you | ||
1335 | to freely set variable values to expandable expressions | ||
1336 | without having them expanded prematurely. | ||
1337 | If you do wish to expand a variable within a Python | ||
1338 | function, use <filename>d.getVar("X")</filename>. | ||
1339 | Or, for more complicated expressions, use | ||
1340 | <filename>d.expand()</filename>. | ||
1341 | </note> | ||
1342 | </para> | ||
1343 | |||
1344 | <para> | ||
1345 | Similar to shell functions, you can also apply overrides | ||
1346 | and override-style operators to BitBake-style Python | ||
1347 | functions. | ||
1348 | </para> | ||
1349 | |||
1350 | <para> | ||
1351 | As an example, consider the following: | ||
1352 | <literallayout class='monospaced'> | ||
1353 | python do_foo_prepend() { | ||
1354 | bb.plain("first") | ||
1355 | } | ||
1356 | |||
1357 | python do_foo() { | ||
1358 | bb.plain("second") | ||
1359 | } | ||
1360 | |||
1361 | python do_foo_append() { | ||
1362 | bb.plain("third") | ||
1363 | } | ||
1364 | </literallayout> | ||
1365 | Running <filename>do_foo</filename> prints | ||
1366 | the following: | ||
1367 | <literallayout class='monospaced'> | ||
1368 | recipename do_foo: first | ||
1369 | recipename do_foo: second | ||
1370 | recipename do_foo: third | ||
1371 | </literallayout> | ||
1372 | You can use the <filename>bitbake -e</filename> <replaceable>recipename</replaceable> | ||
1373 | command to view the final assembled function | ||
1374 | after all overrides have been applied. | ||
1375 | </para> | ||
1376 | </section> | ||
1377 | |||
1378 | <section id='python-functions'> | ||
1379 | <title>Python Functions</title> | ||
1380 | |||
1381 | <para> | ||
1382 | These functions are written in Python and are executed by | ||
1383 | other Python code. | ||
1384 | Examples of Python functions are utility functions | ||
1385 | that you intend to call from in-line Python or | ||
1386 | from within other Python functions. | ||
1387 | Here is an example: | ||
1388 | <literallayout class='monospaced'> | ||
1389 | def get_depends(d): | ||
1390 | if d.getVar('SOMECONDITION'): | ||
1391 | return "dependencywithcond" | ||
1392 | else: | ||
1393 | return "dependency" | ||
1394 | SOMECONDITION = "1" | ||
1395 | DEPENDS = "${@get_depends(d)}" | ||
1396 | </literallayout> | ||
1397 | This would result in <filename>DEPENDS</filename> | ||
1398 | containing <filename>dependencywithcond</filename>. | ||
1399 | </para> | ||
1400 | |||
1401 | <para> | ||
1402 | Here are some things to know about Python functions: | ||
1403 | <itemizedlist> | ||
1404 | <listitem><para>Python functions can take parameters. | ||
1405 | </para></listitem> | ||
1406 | <listitem><para>The BitBake datastore is not | ||
1407 | automatically available. | ||
1408 | Consequently, you must pass it in as a | ||
1409 | parameter to the function. | ||
1410 | </para></listitem> | ||
1411 | <listitem><para>The "bb" and "os" Python modules are | ||
1412 | automatically available. | ||
1413 | You do not need to import them. | ||
1414 | </para></listitem> | ||
1415 | </itemizedlist> | ||
1416 | </para> | ||
1417 | </section> | ||
1418 | |||
1419 | <section id='bitbake-style-python-functions-versus-python-functions'> | ||
1420 | <title>BitBake-Style Python Functions Versus Python Functions</title> | ||
1421 | |||
1422 | <para> | ||
1423 | Following are some important differences between | ||
1424 | BitBake-style Python functions and regular Python | ||
1425 | functions defined with "def": | ||
1426 | <itemizedlist> | ||
1427 | <listitem><para> | ||
1428 | Only BitBake-style Python functions can be | ||
1429 | <link linkend='tasks'>tasks</link>. | ||
1430 | </para></listitem> | ||
1431 | <listitem><para> | ||
1432 | Overrides and override-style operators can only | ||
1433 | be applied to BitBake-style Python functions. | ||
1434 | </para></listitem> | ||
1435 | <listitem><para> | ||
1436 | Only regular Python functions can take arguments | ||
1437 | and return values. | ||
1438 | </para></listitem> | ||
1439 | <listitem><para> | ||
1440 | <link linkend='variable-flags'>Variable flags</link> | ||
1441 | such as <filename>[dirs]</filename>, | ||
1442 | <filename>[cleandirs]</filename>, and | ||
1443 | <filename>[lockfiles]</filename> can be used | ||
1444 | on BitBake-style Python functions, but not on | ||
1445 | regular Python functions. | ||
1446 | </para></listitem> | ||
1447 | <listitem><para> | ||
1448 | BitBake-style Python functions generate a separate | ||
1449 | <filename>${</filename><link linkend='var-bb-T'><filename>T</filename></link><filename>}/run.</filename><replaceable>function-name</replaceable><filename>.</filename><replaceable>pid</replaceable> | ||
1450 | script that is executed to run the function, and also | ||
1451 | generate a log file in | ||
1452 | <filename>${T}/log.</filename><replaceable>function-name</replaceable><filename>.</filename><replaceable>pid</replaceable> | ||
1453 | if they are executed as tasks.</para> | ||
1454 | |||
1455 | <para> | ||
1456 | Regular Python functions execute "inline" and do not | ||
1457 | generate any files in <filename>${T}</filename>. | ||
1458 | </para></listitem> | ||
1459 | <listitem><para> | ||
1460 | Regular Python functions are called with the usual | ||
1461 | Python syntax. | ||
1462 | BitBake-style Python functions are usually tasks and | ||
1463 | are called directly by BitBake, but can also be called | ||
1464 | manually from Python code by using the | ||
1465 | <filename>bb.build.exec_func()</filename> function. | ||
1466 | Here is an example: | ||
1467 | <literallayout class='monospaced'> | ||
1468 | bb.build.exec_func("my_bitbake_style_function", d) | ||
1469 | </literallayout> | ||
1470 | <note> | ||
1471 | <filename>bb.build.exec_func()</filename> can also | ||
1472 | be used to run shell functions from Python code. | ||
1473 | If you want to run a shell function before a Python | ||
1474 | function within the same task, then you can use a | ||
1475 | parent helper Python function that starts by running | ||
1476 | the shell function with | ||
1477 | <filename>bb.build.exec_func()</filename> and then | ||
1478 | runs the Python code. | ||
1479 | </note></para> | ||
1480 | |||
1481 | <para>To detect errors from functions executed with | ||
1482 | <filename>bb.build.exec_func()</filename>, you | ||
1483 | can catch the <filename>bb.build.FuncFailed</filename> | ||
1484 | exception. | ||
1485 | <note> | ||
1486 | Functions in metadata (recipes and classes) should | ||
1487 | not themselves raise | ||
1488 | <filename>bb.build.FuncFailed</filename>. | ||
1489 | Rather, <filename>bb.build.FuncFailed</filename> | ||
1490 | should be viewed as a general indicator that the | ||
1491 | called function failed by raising an exception. | ||
1492 | For example, an exception raised by | ||
1493 | <filename>bb.fatal()</filename> will be caught inside | ||
1494 | <filename>bb.build.exec_func()</filename>, and a | ||
1495 | <filename>bb.build.FuncFailed</filename> will be raised | ||
1496 | in response. | ||
1497 | </note> | ||
1498 | </para></listitem> | ||
1499 | </itemizedlist> | ||
1500 | </para> | ||
1501 | |||
1502 | <para> | ||
1503 | Due to their simplicity, you should prefer regular Python functions | ||
1504 | over BitBake-style Python functions unless you need a feature specific | ||
1505 | to BitBake-style Python functions. | ||
1506 | Regular Python functions in metadata are a more recent invention than | ||
1507 | BitBake-style Python functions, and older code tends to use | ||
1508 | <filename>bb.build.exec_func()</filename> more often. | ||
1509 | </para> | ||
1510 | </section> | ||
1511 | |||
1512 | <section id='anonymous-python-functions'> | ||
1513 | <title>Anonymous Python Functions</title> | ||
1514 | |||
1515 | <para> | ||
1516 | Sometimes it is useful to set variables or perform | ||
1517 | other operations programmatically during parsing. | ||
1518 | To do this, you can define special Python functions, | ||
1519 | called anonymous Python functions, that run at the | ||
1520 | end of parsing. | ||
1521 | For example, the following conditionally sets a variable | ||
1522 | based on the value of another variable: | ||
1523 | <literallayout class='monospaced'> | ||
1524 | python () { | ||
1525 | if d.getVar('SOMEVAR') == 'value': | ||
1526 | d.setVar('ANOTHERVAR', 'value2') | ||
1527 | } | ||
1528 | </literallayout> | ||
1529 | An equivalent way to mark a function as an anonymous | ||
1530 | function is to give it the name "__anonymous", rather | ||
1531 | than no name. | ||
1532 | </para> | ||
1533 | |||
1534 | <para> | ||
1535 | Anonymous Python functions always run at the end | ||
1536 | of parsing, regardless of where they are defined. | ||
1537 | If a recipe contains many anonymous functions, they | ||
1538 | run in the same order as they are defined within the | ||
1539 | recipe. | ||
1540 | As an example, consider the following snippet: | ||
1541 | <literallayout class='monospaced'> | ||
1542 | python () { | ||
1543 | d.setVar('FOO', 'foo 2') | ||
1544 | } | ||
1545 | |||
1546 | FOO = "foo 1" | ||
1547 | |||
1548 | python () { | ||
1549 | d.appendVar('BAR', ' bar 2') | ||
1550 | } | ||
1551 | |||
1552 | BAR = "bar 1" | ||
1553 | </literallayout> | ||
1554 | The previous example is conceptually equivalent to the | ||
1555 | following snippet: | ||
1556 | <literallayout class='monospaced'> | ||
1557 | FOO = "foo 1" | ||
1558 | BAR = "bar 1" | ||
1559 | FOO = "foo 2" | ||
1560 | BAR += "bar 2" | ||
1561 | </literallayout> | ||
1562 | <filename>FOO</filename> ends up with the value "foo 2", | ||
1563 | and <filename>BAR</filename> with the value "bar 1 bar 2". | ||
1564 | Just as in the second snippet, the values set for the | ||
1565 | variables within the anonymous functions become available | ||
1566 | to tasks, which always run after parsing. | ||
1567 | </para> | ||
1568 | |||
1569 | <para> | ||
1570 | Overrides and override-style operators such as | ||
1571 | "<filename>_append</filename>" are applied before | ||
1572 | anonymous functions run. | ||
1573 | In the following example, <filename>FOO</filename> ends | ||
1574 | up with the value "foo from anonymous": | ||
1575 | <literallayout class='monospaced'> | ||
1576 | FOO = "foo" | ||
1577 | FOO_append = " from outside" | ||
1578 | |||
1579 | python () { | ||
1580 | d.setVar("FOO", "foo from anonymous") | ||
1581 | } | ||
1582 | </literallayout> | ||
1583 | For methods you can use with anonymous Python functions, | ||
1584 | see the | ||
1585 | "<link linkend='functions-you-can-call-from-within-python'>Functions You Can Call From Within Python</link>" | ||
1586 | section. | ||
1587 | For a different method to run Python code during parsing, | ||
1588 | see the | ||
1589 | "<link linkend='inline-python-variable-expansion'>Inline Python Variable Expansion</link>" | ||
1590 | section. | ||
1591 | </para> | ||
1592 | </section> | ||
1593 | |||
1594 | <section id='flexible-inheritance-for-class-functions'> | ||
1595 | <title>Flexible Inheritance for Class Functions</title> | ||
1596 | |||
1597 | <para> | ||
1598 | Through coding techniques and the use of | ||
1599 | <filename>EXPORT_FUNCTIONS</filename>, BitBake supports | ||
1600 | exporting a function from a class such that the | ||
1601 | class function appears as the default implementation | ||
1602 | of the function, but can still be called if a recipe | ||
1603 | inheriting the class needs to define its own version of | ||
1604 | the function. | ||
1605 | </para> | ||
1606 | |||
1607 | <para> | ||
1608 | To understand the benefits of this feature, consider | ||
1609 | the basic scenario where a class defines a task function | ||
1610 | and your recipe inherits the class. | ||
1611 | In this basic scenario, your recipe inherits the task | ||
1612 | function as defined in the class. | ||
1613 | If desired, your recipe can add to the start and end of the | ||
1614 | function by using the "_prepend" or "_append" operations | ||
1615 | respectively, or it can redefine the function completely. | ||
1616 | However, if it redefines the function, there is | ||
1617 | no means for it to call the class version of the function. | ||
1618 | <filename>EXPORT_FUNCTIONS</filename> provides a mechanism | ||
1619 | that enables the recipe's version of the function to call | ||
1620 | the original version of the function. | ||
1621 | </para> | ||
1622 | |||
1623 | <para> | ||
1624 | To make use of this technique, you need the following | ||
1625 | things in place: | ||
1626 | <itemizedlist> | ||
1627 | <listitem><para> | ||
1628 | The class needs to define the function as follows: | ||
1629 | <literallayout class='monospaced'> | ||
1630 | <replaceable>classname</replaceable><filename>_</filename><replaceable>functionname</replaceable> | ||
1631 | </literallayout> | ||
1632 | For example, if you have a class file | ||
1633 | <filename>bar.bbclass</filename> and a function named | ||
1634 | <filename>do_foo</filename>, the class must define the function | ||
1635 | as follows: | ||
1636 | <literallayout class='monospaced'> | ||
1637 | bar_do_foo | ||
1638 | </literallayout> | ||
1639 | </para></listitem> | ||
1640 | <listitem><para> | ||
1641 | The class needs to contain the <filename>EXPORT_FUNCTIONS</filename> | ||
1642 | statement as follows: | ||
1643 | <literallayout class='monospaced'> | ||
1644 | EXPORT_FUNCTIONS <replaceable>functionname</replaceable> | ||
1645 | </literallayout> | ||
1646 | For example, continuing with the same example, the | ||
1647 | statement in the <filename>bar.bbclass</filename> would be | ||
1648 | as follows: | ||
1649 | <literallayout class='monospaced'> | ||
1650 | EXPORT_FUNCTIONS do_foo | ||
1651 | </literallayout> | ||
1652 | </para></listitem> | ||
1653 | <listitem><para> | ||
1654 | You need to call the function appropriately from within your | ||
1655 | recipe. | ||
1656 | Continuing with the same example, if your recipe | ||
1657 | needs to call the class version of the function, | ||
1658 | it should call <filename>bar_do_foo</filename>. | ||
1659 | Assuming <filename>do_foo</filename> was a shell function | ||
1660 | and <filename>EXPORT_FUNCTIONS</filename> was used as above, | ||
1661 | the recipe's function could conditionally call the | ||
1662 | class version of the function as follows: | ||
1663 | <literallayout class='monospaced'> | ||
1664 | do_foo() { | ||
1665 | if [ somecondition ] ; then | ||
1666 | bar_do_foo | ||
1667 | else | ||
1668 | # Do something else | ||
1669 | fi | ||
1670 | } | ||
1671 | </literallayout> | ||
1672 | To call your modified version of the function as defined | ||
1673 | in your recipe, call it as <filename>do_foo</filename>. | ||
1674 | </para></listitem> | ||
1675 | </itemizedlist> | ||
1676 | With these conditions met, your single recipe | ||
1677 | can freely choose between the original function | ||
1678 | as defined in the class file and the modified function in your recipe. | ||
1679 | If you do not set up these conditions, you are limited to using one function | ||
1680 | or the other. | ||
1681 | </para> | ||
1682 | </section> | ||
1683 | </section> | ||
1684 | |||
1685 | <section id='tasks'> | ||
1686 | <title>Tasks</title> | ||
1687 | |||
1688 | <para> | ||
1689 | Tasks are BitBake execution units that make up the | ||
1690 | steps that BitBake can run for a given recipe. | ||
1691 | Tasks are only supported in recipes and classes | ||
1692 | (i.e. in <filename>.bb</filename> files and files | ||
1693 | included or inherited from <filename>.bb</filename> | ||
1694 | files). | ||
1695 | By convention, tasks have names that start with "do_". | ||
1696 | </para> | ||
1697 | |||
1698 | <section id='promoting-a-function-to-a-task'> | ||
1699 | <title>Promoting a Function to a Task</title> | ||
1700 | |||
1701 | <para> | ||
1702 | Tasks are either | ||
1703 | <link linkend='shell-functions'>shell functions</link> or | ||
1704 | <link linkend='bitbake-style-python-functions'>BitBake-style Python functions</link> | ||
1705 | that have been promoted to tasks by using the | ||
1706 | <filename>addtask</filename> command. | ||
1707 | The <filename>addtask</filename> command can also | ||
1708 | optionally describe dependencies between the | ||
1709 | task and other tasks. | ||
1710 | Here is an example that shows how to define a task | ||
1711 | and declare some dependencies: | ||
1712 | <literallayout class='monospaced'> | ||
1713 | python do_printdate () { | ||
1714 | import time | ||
1715 | print time.strftime('%Y%m%d', time.gmtime()) | ||
1716 | } | ||
1717 | addtask printdate after do_fetch before do_build | ||
1718 | </literallayout> | ||
1719 | The first argument to <filename>addtask</filename> | ||
1720 | is the name of the function to promote to | ||
1721 | a task. | ||
1722 | If the name does not start with "do_", "do_" is | ||
1723 | implicitly added, which enforces the convention that | ||
1724 | all task names start with "do_". | ||
1725 | </para> | ||
1726 | |||
1727 | <para> | ||
1728 | In the previous example, the | ||
1729 | <filename>do_printdate</filename> task becomes a | ||
1730 | dependency of the <filename>do_build</filename> | ||
1731 | task, which is the default task (i.e. the task run by | ||
1732 | the <filename>bitbake</filename> command unless | ||
1733 | another task is specified explicitly). | ||
1734 | Additionally, the <filename>do_printdate</filename> | ||
1735 | task becomes dependent upon the | ||
1736 | <filename>do_fetch</filename> task. | ||
1737 | Running the <filename>do_build</filename> task | ||
1738 | results in the <filename>do_printdate</filename> | ||
1739 | task running first. | ||
1740 | <note> | ||
1741 | If you try out the previous example, you might see that | ||
1742 | the <filename>do_printdate</filename> task is only run | ||
1743 | the first time you build the recipe with | ||
1744 | the <filename>bitbake</filename> command. | ||
1745 | This is because BitBake considers the task "up-to-date" | ||
1746 | after that initial run. | ||
1747 | If you want to force the task to always be rerun for | ||
1748 | experimentation purposes, you can make BitBake always | ||
1749 | consider the task "out-of-date" by using the | ||
1750 | <filename>[</filename><link linkend='variable-flags'><filename>nostamp</filename></link><filename>]</filename> | ||
1751 | variable flag, as follows: | ||
1752 | <literallayout class='monospaced'> | ||
1753 | do_printdate[nostamp] = "1" | ||
1754 | </literallayout> | ||
1755 | You can also explicitly run the task and provide the | ||
1756 | <filename>-f</filename> option as follows: | ||
1757 | <literallayout class='monospaced'> | ||
1758 | $ bitbake <replaceable>recipe</replaceable> -c printdate -f | ||
1759 | </literallayout> | ||
1760 | When manually selecting a task to run with the | ||
1761 | <filename>bitbake</filename> <replaceable>recipe</replaceable> <filename>-c</filename> <replaceable>task</replaceable> | ||
1762 | command, you can omit the "do_" prefix as part of the | ||
1763 | task name. | ||
1764 | </note> | ||
1765 | </para> | ||
1766 | |||
1767 | <para> | ||
1768 | You might wonder about the practical effects of using | ||
1769 | <filename>addtask</filename> without specifying any | ||
1770 | dependencies as is done in the following example: | ||
1771 | <literallayout class='monospaced'> | ||
1772 | addtask printdate | ||
1773 | </literallayout> | ||
1774 | In this example, assuming dependencies have not been | ||
1775 | added through some other means, the only way to run | ||
1776 | the task is by explicitly selecting it with | ||
1777 | <filename>bitbake</filename> <replaceable>recipe</replaceable> <filename>-c printdate</filename>. | ||
1778 | You can use the | ||
1779 | <filename>do_listtasks</filename> task to list all tasks | ||
1780 | defined in a recipe as shown in the following example: | ||
1781 | <literallayout class='monospaced'> | ||
1782 | $ bitbake <replaceable>recipe</replaceable> -c listtasks | ||
1783 | </literallayout> | ||
1784 | For more information on task dependencies, see the | ||
1785 | "<link linkend='dependencies'>Dependencies</link>" | ||
1786 | section. | ||
1787 | </para> | ||
1788 | |||
1789 | <para> | ||
1790 | See the | ||
1791 | "<link linkend='variable-flags'>Variable Flags</link>" | ||
1792 | section for information on variable flags you can use with | ||
1793 | tasks. | ||
1794 | </para> | ||
1795 | </section> | ||
1796 | |||
1797 | <section id='deleting-a-task'> | ||
1798 | <title>Deleting a Task</title> | ||
1799 | |||
1800 | <para> | ||
1801 | As well as being able to add tasks, you can delete them. | ||
1802 | Simply use the <filename>deltask</filename> command to | ||
1803 | delete a task. | ||
1804 | For example, to delete the example task used in the previous | ||
1805 | sections, you would use: | ||
1806 | <literallayout class='monospaced'> | ||
1807 | deltask printdate | ||
1808 | </literallayout> | ||
1809 | If you delete a task using the <filename>deltask</filename> | ||
1810 | command and the task has dependencies, the dependencies are | ||
1811 | not reconnected. | ||
1812 | For example, suppose you have three tasks named | ||
1813 | <filename>do_a</filename>, <filename>do_b</filename>, and | ||
1814 | <filename>do_c</filename>. | ||
1815 | Furthermore, <filename>do_c</filename> is dependent on | ||
1816 | <filename>do_b</filename>, which in turn is dependent on | ||
1817 | <filename>do_a</filename>. | ||
1818 | Given this scenario, if you use <filename>deltask</filename> | ||
1819 | to delete <filename>do_b</filename>, the implicit dependency | ||
1820 | relationship between <filename>do_c</filename> and | ||
1821 | <filename>do_a</filename> through <filename>do_b</filename> | ||
1822 | no longer exists, and <filename>do_c</filename> dependencies | ||
1823 | are not updated to include <filename>do_a</filename>. | ||
1824 | Thus, <filename>do_c</filename> is free to run before | ||
1825 | <filename>do_a</filename>. | ||
1826 | </para> | ||
1827 | |||
1828 | <para> | ||
1829 | If you want dependencies such as these to remain intact, use | ||
1830 | the <filename>[noexec]</filename> varflag to disable the task | ||
1831 | instead of using the <filename>deltask</filename> command to | ||
1832 | delete it: | ||
1833 | <literallayout class='monospaced'> | ||
1834 | do_b[noexec] = "1" | ||
1835 | </literallayout> | ||
1836 | </para> | ||
1837 | </section> | ||
1838 | |||
1839 | <section id='passing-information-into-the-build-task-environment'> | ||
1840 | <title>Passing Information Into the Build Task Environment</title> | ||
1841 | |||
1842 | <para> | ||
1843 | When running a task, BitBake tightly controls the shell execution | ||
1844 | environment of the build tasks to make | ||
1845 | sure unwanted contamination from the build machine cannot | ||
1846 | influence the build. | ||
1847 | <note> | ||
1848 | By default, BitBake cleans the environment to include only those | ||
1849 | things exported or listed in its whitelist to ensure that the build | ||
1850 | environment is reproducible and consistent. | ||
1851 | You can prevent this "cleaning" by setting the | ||
1852 | <link linkend='var-bb-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link> | ||
1853 | variable. | ||
1854 | </note> | ||
1855 | Consequently, if you do want something to get passed into the | ||
1856 | build task environment, you must take these two steps: | ||
1857 | <orderedlist> | ||
1858 | <listitem><para> | ||
1859 | Tell BitBake to load what you want from the environment | ||
1860 | into the datastore. | ||
1861 | You can do so through the | ||
1862 | <link linkend='var-bb-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link> | ||
1863 | and | ||
1864 | <link linkend='var-bb-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link> | ||
1865 | variables. | ||
1866 | For example, assume you want to prevent the build system from | ||
1867 | accessing your <filename>$HOME/.ccache</filename> | ||
1868 | directory. | ||
1869 | The following command "whitelists" the environment variable | ||
1870 | <filename>CCACHE_DIR</filename> causing BitBake to allow that | ||
1871 | variable into the datastore: | ||
1872 | <literallayout class='monospaced'> | ||
1873 | export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR" | ||
1874 | </literallayout></para></listitem> | ||
1875 | <listitem><para> | ||
1876 | Tell BitBake to export what you have loaded into the | ||
1877 | datastore to the task environment of every running task. | ||
1878 | Loading something from the environment into the datastore | ||
1879 | (previous step) only makes it available in the datastore. | ||
1880 | To export it to the task environment of every running task, | ||
1881 | use a command similar to the following in your local configuration | ||
1882 | file <filename>local.conf</filename> or your | ||
1883 | distribution configuration file: | ||
1884 | <literallayout class='monospaced'> | ||
1885 | export CCACHE_DIR | ||
1886 | </literallayout> | ||
1887 | <note> | ||
1888 | A side effect of the previous steps is that BitBake | ||
1889 | records the variable as a dependency of the build process | ||
1890 | in things like the setscene checksums. | ||
1891 | If doing so results in unnecessary rebuilds of tasks, you can | ||
1892 | whitelist the variable so that the setscene code | ||
1893 | ignores the dependency when it creates checksums. | ||
1894 | </note></para></listitem> | ||
1895 | </orderedlist> | ||
1896 | </para> | ||
1897 | |||
1898 | <para> | ||
1899 | Sometimes, it is useful to be able to obtain information | ||
1900 | from the original execution environment. | ||
1901 | BitBake saves a copy of the original environment into | ||
1902 | a special variable named | ||
1903 | <link linkend='var-bb-BB_ORIGENV'><filename>BB_ORIGENV</filename></link>. | ||
1904 | </para> | ||
1905 | |||
1906 | <para> | ||
1907 | The <filename>BB_ORIGENV</filename> variable returns a datastore | ||
1908 | object that can be queried using the standard datastore operators | ||
1909 | such as <filename>getVar(, False)</filename>. | ||
1910 | The datastore object is useful, for example, to find the original | ||
1911 | <filename>DISPLAY</filename> variable. | ||
1912 | Here is an example: | ||
1913 | <literallayout class='monospaced'> | ||
1914 | origenv = d.getVar("BB_ORIGENV", False) | ||
1915 | bar = origenv.getVar("BAR", False) | ||
1916 | </literallayout> | ||
1917 | The previous example returns <filename>BAR</filename> from the original | ||
1918 | execution environment. | ||
1919 | </para> | ||
1920 | </section> | ||
1921 | </section> | ||
1922 | |||
1923 | <section id='variable-flags'> | ||
1924 | <title>Variable Flags</title> | ||
1925 | |||
1926 | <para> | ||
1927 | Variable flags (varflags) help control a task's functionality | ||
1928 | and dependencies. | ||
1929 | BitBake reads and writes varflags to the datastore using the following | ||
1930 | command forms: | ||
1931 | <literallayout class='monospaced'> | ||
1932 | <replaceable>variable</replaceable> = d.getVarFlags("<replaceable>variable</replaceable>") | ||
1933 | self.d.setVarFlags("FOO", {"func": True}) | ||
1934 | </literallayout> | ||
1935 | </para> | ||
1936 | |||
1937 | <para> | ||
1938 | When working with varflags, the same syntax, with the exception of | ||
1939 | overrides, applies. | ||
1940 | In other words, you can set, append, and prepend varflags just like | ||
1941 | variables. | ||
1942 | See the | ||
1943 | "<link linkend='variable-flag-syntax'>Variable Flag Syntax</link>" | ||
1944 | section for details. | ||
1945 | </para> | ||
1946 | |||
1947 | <para> | ||
1948 | BitBake has a defined set of varflags available for recipes and | ||
1949 | classes. | ||
1950 | Tasks support a number of these flags which control various | ||
1951 | functionality of the task: | ||
1952 | <itemizedlist> | ||
1953 | <listitem><para><emphasis><filename>[cleandirs]</filename>:</emphasis> | ||
1954 | Empty directories that should be created before the | ||
1955 | task runs. | ||
1956 | Directories that already exist are removed and recreated | ||
1957 | to empty them. | ||
1958 | </para></listitem> | ||
1959 | <listitem><para><emphasis><filename>[depends]</filename>:</emphasis> | ||
1960 | Controls inter-task dependencies. | ||
1961 | See the | ||
1962 | <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> | ||
1963 | variable and the | ||
1964 | "<link linkend='inter-task-dependencies'>Inter-Task Dependencies</link>" | ||
1965 | section for more information. | ||
1966 | </para></listitem> | ||
1967 | <listitem><para><emphasis><filename>[deptask]</filename>:</emphasis> | ||
1968 | Controls task build-time dependencies. | ||
1969 | See the | ||
1970 | <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> | ||
1971 | variable and the | ||
1972 | "<link linkend='build-dependencies'>Build Dependencies</link>" | ||
1973 | section for more information. | ||
1974 | </para></listitem> | ||
1975 | <listitem><para><emphasis><filename>[dirs]</filename>:</emphasis> | ||
1976 | Directories that should be created before the task runs. | ||
1977 | Directories that already exist are left as is. | ||
1978 | The last directory listed is used as the | ||
1979 | current working directory for the task. | ||
1980 | </para></listitem> | ||
1981 | <listitem><para><emphasis><filename>[lockfiles]</filename>:</emphasis> | ||
1982 | Specifies one or more lockfiles to lock while the task | ||
1983 | executes. | ||
1984 | Only one task may hold a lockfile, and any task that | ||
1985 | attempts to lock an already locked file will block until | ||
1986 | the lock is released. | ||
1987 | You can use this variable flag to accomplish mutual | ||
1988 | exclusion. | ||
1989 | </para></listitem> | ||
1990 | <listitem><para><emphasis><filename>[noexec]</filename>:</emphasis> | ||
1991 | When set to "1", marks the task as being empty, with | ||
1992 | no execution required. | ||
1993 | You can use the <filename>[noexec]</filename> flag to set up | ||
1994 | tasks as dependency placeholders, or to disable tasks defined | ||
1995 | elsewhere that are not needed in a particular recipe. | ||
1996 | </para></listitem> | ||
1997 | <listitem><para><emphasis><filename>[nostamp]</filename>:</emphasis> | ||
1998 | When set to "1", tells BitBake to not generate a stamp | ||
1999 | file for a task, which implies the task should always | ||
2000 | be executed. | ||
2001 | <note><title>Caution</title> | ||
2002 | Any task that depends (possibly indirectly) on a | ||
2003 | <filename>[nostamp]</filename> task will always be | ||
2004 | executed as well. | ||
2005 | This can cause unnecessary rebuilding if you are | ||
2006 | not careful. | ||
2007 | </note> | ||
2008 | </para></listitem> | ||
2009 | <listitem><para><emphasis><filename>[number_threads]</filename>:</emphasis> | ||
2010 | Limits tasks to a specific number of simultaneous threads | ||
2011 | during execution. | ||
2012 | This varflag is useful when your build host has a large number | ||
2013 | of cores but certain tasks need to be rate-limited due to various | ||
2014 | kinds of resource constraints (e.g. to avoid network throttling). | ||
2015 | <filename>number_threads</filename> works similarly to the | ||
2016 | <link linkend='var-bb-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> | ||
2017 | variable but is task-specific.</para> | ||
2018 | |||
2019 | <para>Set the value globally. | ||
2020 | For example, the following makes sure the | ||
2021 | <filename>do_fetch</filename> task uses no more than two | ||
2022 | simultaneous execution threads: | ||
2023 | <literallayout class='monospaced'> | ||
2024 | do_fetch[number_threads] = "2" | ||
2025 | </literallayout> | ||
2026 | <note><title>Warnings</title> | ||
2027 | <itemizedlist> | ||
2028 | <listitem><para> | ||
2029 | Setting the varflag in individual recipes rather | ||
2030 | than globally can result in unpredictable behavior. | ||
2031 | </para></listitem> | ||
2032 | <listitem><para> | ||
2033 | Setting the varflag to a value greater than the | ||
2034 | value used in the <filename>BB_NUMBER_THREADS</filename> | ||
2035 | variable causes <filename>number_threads</filename> | ||
2036 | to have no effect. | ||
2037 | </para></listitem> | ||
2038 | </itemizedlist> | ||
2039 | </note> | ||
2040 | </para></listitem> | ||
2041 | <listitem><para><emphasis><filename>[postfuncs]</filename>:</emphasis> | ||
2042 | List of functions to call after the completion of the task. | ||
2043 | </para></listitem> | ||
2044 | <listitem><para><emphasis><filename>[prefuncs]</filename>:</emphasis> | ||
2045 | List of functions to call before the task executes. | ||
2046 | </para></listitem> | ||
2047 | <listitem><para><emphasis><filename>[rdepends]</filename>:</emphasis> | ||
2048 | Controls inter-task runtime dependencies. | ||
2049 | See the | ||
2050 | <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> | ||
2051 | variable, the | ||
2052 | <link linkend='var-bb-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> | ||
2053 | variable, and the | ||
2054 | "<link linkend='inter-task-dependencies'>Inter-Task Dependencies</link>" | ||
2055 | section for more information. | ||
2056 | </para></listitem> | ||
2057 | <listitem><para><emphasis><filename>[rdeptask]</filename>:</emphasis> | ||
2058 | Controls task runtime dependencies. | ||
2059 | See the | ||
2060 | <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> | ||
2061 | variable, the | ||
2062 | <link linkend='var-bb-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> | ||
2063 | variable, and the | ||
2064 | "<link linkend='runtime-dependencies'>Runtime Dependencies</link>" | ||
2065 | section for more information. | ||
2066 | </para></listitem> | ||
2067 | <listitem><para><emphasis><filename>[recideptask]</filename>:</emphasis> | ||
2068 | When set in conjunction with | ||
2069 | <filename>recrdeptask</filename>, specifies a task that | ||
2070 | should be inspected for additional dependencies. | ||
2071 | </para></listitem> | ||
2072 | <listitem><para><emphasis><filename>[recrdeptask]</filename>:</emphasis> | ||
2073 | Controls task recursive runtime dependencies. | ||
2074 | See the | ||
2075 | <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> | ||
2076 | variable, the | ||
2077 | <link linkend='var-bb-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> | ||
2078 | variable, and the | ||
2079 | "<link linkend='recursive-dependencies'>Recursive Dependencies</link>" | ||
2080 | section for more information. | ||
2081 | </para></listitem> | ||
2082 | <listitem><para><emphasis><filename>[stamp-extra-info]</filename>:</emphasis> | ||
2083 | Extra stamp information to append to the task's stamp. | ||
2084 | As an example, OpenEmbedded uses this flag to allow | ||
2085 | machine-specific tasks. | ||
2086 | </para></listitem> | ||
2087 | <listitem><para><emphasis><filename>[umask]</filename>:</emphasis> | ||
2088 | The umask to run the task under. | ||
2089 | </para></listitem> | ||
2090 | </itemizedlist> | ||
2091 | </para> | ||
2092 | |||
2093 | <para> | ||
2094 | Several varflags are useful for controlling how signatures are | ||
2095 | calculated for variables. | ||
2096 | For more information on this process, see the | ||
2097 | "<link linkend='checksums'>Checksums (Signatures)</link>" | ||
2098 | section. | ||
2099 | <itemizedlist> | ||
2100 | <listitem><para><emphasis><filename>[vardeps]</filename>:</emphasis> | ||
2101 | Specifies a space-separated list of additional | ||
2102 | variables to add to a variable's dependencies | ||
2103 | for the purposes of calculating its signature. | ||
2104 | Adding variables to this list is useful, for example, when | ||
2105 | a function refers to a variable in a manner that | ||
2106 | does not allow BitBake to automatically determine | ||
2107 | that the variable is referred to. | ||
2108 | </para></listitem> | ||
2109 | <listitem><para><emphasis><filename>[vardepsexclude]</filename>:</emphasis> | ||
2110 | Specifies a space-separated list of variables | ||
2111 | that should be excluded from a variable's dependencies | ||
2112 | for the purposes of calculating its signature. | ||
2113 | </para></listitem> | ||
2114 | <listitem><para><emphasis><filename>[vardepvalue]</filename>:</emphasis> | ||
2115 | If set, instructs BitBake to ignore the actual | ||
2116 | value of the variable and instead use the specified | ||
2117 | value when calculating the variable's signature. | ||
2118 | </para></listitem> | ||
2119 | <listitem><para><emphasis><filename>[vardepvalueexclude]</filename>:</emphasis> | ||
2120 | Specifies a pipe-separated list of strings to exclude | ||
2121 | from the variable's value when calculating the | ||
2122 | variable's signature. | ||
2123 | </para></listitem> | ||
2124 | </itemizedlist> | ||
2125 | </para> | ||
2126 | </section> | ||
2127 | |||
2128 | <section id='events'> | ||
2129 | <title>Events</title> | ||
2130 | |||
2131 | <para> | ||
2132 | BitBake allows installation of event handlers within recipe | ||
2133 | and class files. | ||
2134 | Events are triggered at certain points during operation, such | ||
2135 | as the beginning of operation against a given recipe | ||
2136 | (i.e. <filename>*.bb</filename>), the start of a given task, | ||
2137 | a task failure, a task success, and so forth. | ||
2138 | The intent is to make it easy to do things like email | ||
2139 | notification on build failures. | ||
2140 | </para> | ||
2141 | |||
2142 | <para> | ||
2143 | Following is an example event handler that prints the name | ||
2144 | of the event and the content of the | ||
2145 | <filename>FILE</filename> variable: | ||
2146 | <literallayout class='monospaced'> | ||
2147 | addhandler myclass_eventhandler | ||
2148 | python myclass_eventhandler() { | ||
2149 | from bb.event import getName | ||
2150 | print("The name of the Event is %s" % getName(e)) | ||
2151 | print("The file we run for is %s" % d.getVar('FILE')) | ||
2152 | } | ||
2153 | myclass_eventhandler[eventmask] = "bb.event.BuildStarted bb.event.BuildCompleted" | ||
2154 | </literallayout> | ||
2155 | In the previous example, an eventmask has been set so that | ||
2156 | the handler only sees the "BuildStarted" and "BuildCompleted" | ||
2157 | events. | ||
2158 | This event handler gets called every time an event matching | ||
2159 | the eventmask is triggered. | ||
2160 | A global variable "e" is defined, which represents the current | ||
2161 | event. | ||
2162 | With the <filename>getName(e)</filename> method, you can get | ||
2163 | the name of the triggered event. | ||
2164 | The global datastore is available as "d". | ||
2165 | In legacy code, you might see "e.data" used to get the datastore. | ||
2166 | However, realize that "e.data" is deprecated and you should use | ||
2167 | "d" going forward. | ||
2168 | </para> | ||
2169 | |||
2170 | <para> | ||
2171 | The context of the datastore is appropriate to the event | ||
2172 | in question. | ||
2173 | For example, "BuildStarted" and "BuildCompleted" events run | ||
2174 | before any tasks are executed so would be in the global | ||
2175 | configuration datastore namespace. | ||
2176 | No recipe-specific metadata exists in that namespace. | ||
2177 | The "BuildStarted" and "BuildCompleted" events also run in | ||
2178 | the main cooker/server process rather than any worker context. | ||
2179 | Thus, any changes made to the datastore would be seen by other | ||
2180 | cooker/server events within the current build but not seen | ||
2181 | outside of that build or in any worker context. | ||
2182 | Task events run in the actual tasks in question consequently | ||
2183 | have recipe-specific and task-specific contents. | ||
2184 | These events run in the worker context and are discarded at | ||
2185 | the end of task execution. | ||
2186 | </para> | ||
2187 | |||
2188 | <para> | ||
2189 | During a standard build, the following common events might | ||
2190 | occur. | ||
2191 | The following events are the most common kinds of events that | ||
2192 | most metadata might have an interest in viewing: | ||
2193 | <itemizedlist> | ||
2194 | <listitem><para> | ||
2195 | <filename>bb.event.ConfigParsed()</filename>: | ||
2196 | Fired when the base configuration; which consists of | ||
2197 | <filename>bitbake.conf</filename>, | ||
2198 | <filename>base.bbclass</filename> and any global | ||
2199 | <filename>INHERIT</filename> statements; has been parsed. | ||
2200 | You can see multiple such events when each of the | ||
2201 | workers parse the base configuration or if the server | ||
2202 | changes configuration and reparses. | ||
2203 | Any given datastore only has one such event executed | ||
2204 | against it, however. | ||
2205 | If | ||
2206 | <link linkende='var-bb-BB_INVALIDCONF'><filename>BB_INVALIDCONF</filename></link> | ||
2207 | is set in the datastore by the event handler, the | ||
2208 | configuration is reparsed and a new event triggered, | ||
2209 | allowing the metadata to update configuration. | ||
2210 | </para></listitem> | ||
2211 | <listitem><para> | ||
2212 | <filename>bb.event.HeartbeatEvent()</filename>: | ||
2213 | Fires at regular time intervals of one second. | ||
2214 | You can configure the interval time using the | ||
2215 | <filename>BB_HEARTBEAT_EVENT</filename> variable. | ||
2216 | The event's "time" attribute is the | ||
2217 | <filename>time.time()</filename> value when the | ||
2218 | event is triggered. | ||
2219 | This event is useful for activities such as | ||
2220 | system state monitoring. | ||
2221 | </para></listitem> | ||
2222 | <listitem><para> | ||
2223 | <filename>bb.event.ParseStarted()</filename>: | ||
2224 | Fired when BitBake is about to start parsing recipes. | ||
2225 | This event's "total" attribute represents the number of | ||
2226 | recipes BitBake plans to parse. | ||
2227 | </para></listitem> | ||
2228 | <listitem><para> | ||
2229 | <filename>bb.event.ParseProgress()</filename>: | ||
2230 | Fired as parsing progresses. | ||
2231 | This event's "current" attribute is the number of | ||
2232 | recipes parsed as well as the "total" attribute. | ||
2233 | </para></listitem> | ||
2234 | <listitem><para> | ||
2235 | <filename>bb.event.ParseCompleted()</filename>: | ||
2236 | Fired when parsing is complete. | ||
2237 | This event's "cached", "parsed", "skipped", "virtuals", | ||
2238 | "masked", and "errors" attributes provide statistics | ||
2239 | for the parsing results. | ||
2240 | </para></listitem> | ||
2241 | <listitem><para> | ||
2242 | <filename>bb.event.BuildStarted()</filename>: | ||
2243 | Fired when a new build starts. | ||
2244 | BitBake fires multiple "BuildStarted" events (one per configuration) | ||
2245 | when multiple configuration (multiconfig) is enabled. | ||
2246 | </para></listitem> | ||
2247 | <listitem><para> | ||
2248 | <filename>bb.build.TaskStarted()</filename>: | ||
2249 | Fired when a task starts. | ||
2250 | This event's "taskfile" attribute points to the recipe | ||
2251 | from which the task originates. | ||
2252 | The "taskname" attribute, which is the task's name, | ||
2253 | includes the <filename>do_</filename> prefix, and the | ||
2254 | "logfile" attribute point to where the task's output is | ||
2255 | stored. | ||
2256 | Finally, the "time" attribute is the task's execution start | ||
2257 | time. | ||
2258 | </para></listitem> | ||
2259 | <listitem><para> | ||
2260 | <filename>bb.build.TaskInvalid()</filename>: | ||
2261 | Fired if BitBake tries to execute a task that does not exist. | ||
2262 | </para></listitem> | ||
2263 | <listitem><para> | ||
2264 | <filename>bb.build.TaskFailedSilent()</filename>: | ||
2265 | Fired for setscene tasks that fail and should not be | ||
2266 | presented to the user verbosely. | ||
2267 | </para></listitem> | ||
2268 | <listitem><para> | ||
2269 | <filename>bb.build.TaskFailed()</filename>: | ||
2270 | Fired for normal tasks that fail. | ||
2271 | </para></listitem> | ||
2272 | <listitem><para> | ||
2273 | <filename>bb.build.TaskSucceeded()</filename>: | ||
2274 | Fired when a task successfully completes. | ||
2275 | </para></listitem> | ||
2276 | <listitem><para> | ||
2277 | <filename>bb.event.BuildCompleted()</filename>: | ||
2278 | Fired when a build finishes. | ||
2279 | </para></listitem> | ||
2280 | <listitem><para> | ||
2281 | <filename>bb.cooker.CookerExit()</filename>: | ||
2282 | Fired when the BitBake server/cooker shuts down. | ||
2283 | This event is usually only seen by the UIs as a | ||
2284 | sign they should also shutdown. | ||
2285 | </para></listitem> | ||
2286 | </itemizedlist> | ||
2287 | </para> | ||
2288 | |||
2289 | <para> | ||
2290 | This next list of example events occur based on specific | ||
2291 | requests to the server. | ||
2292 | These events are often used to communicate larger pieces of | ||
2293 | information from the BitBake server to other parts of | ||
2294 | BitBake such as user interfaces: | ||
2295 | <itemizedlist> | ||
2296 | <listitem><para> | ||
2297 | <filename>bb.event.TreeDataPreparationStarted()</filename> | ||
2298 | </para></listitem> | ||
2299 | <listitem><para> | ||
2300 | <filename>bb.event.TreeDataPreparationProgress()</filename> | ||
2301 | </para></listitem> | ||
2302 | <listitem><para> | ||
2303 | <filename>bb.event.TreeDataPreparationCompleted()</filename> | ||
2304 | </para></listitem> | ||
2305 | <listitem><para> | ||
2306 | <filename>bb.event.DepTreeGenerated()</filename> | ||
2307 | </para></listitem> | ||
2308 | <listitem><para> | ||
2309 | <filename>bb.event.CoreBaseFilesFound()</filename> | ||
2310 | </para></listitem> | ||
2311 | <listitem><para> | ||
2312 | <filename>bb.event.ConfigFilePathFound()</filename> | ||
2313 | </para></listitem> | ||
2314 | <listitem><para> | ||
2315 | <filename>bb.event.FilesMatchingFound()</filename> | ||
2316 | </para></listitem> | ||
2317 | <listitem><para> | ||
2318 | <filename>bb.event.ConfigFilesFound()</filename> | ||
2319 | </para></listitem> | ||
2320 | <listitem><para> | ||
2321 | <filename>bb.event.TargetsTreeGenerated()</filename> | ||
2322 | </para></listitem> | ||
2323 | </itemizedlist> | ||
2324 | </para> | ||
2325 | </section> | ||
2326 | |||
2327 | <section id='variants-class-extension-mechanism'> | ||
2328 | <title>Variants - Class Extension Mechanism</title> | ||
2329 | |||
2330 | <para> | ||
2331 | BitBake supports two features that facilitate creating | ||
2332 | from a single recipe file multiple incarnations of that | ||
2333 | recipe file where all incarnations are buildable. | ||
2334 | These features are enabled through the | ||
2335 | <link linkend='var-bb-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link> | ||
2336 | and | ||
2337 | <link linkend='var-bb-BBVERSIONS'><filename>BBVERSIONS</filename></link> | ||
2338 | variables. | ||
2339 | <note> | ||
2340 | The mechanism for this class extension is extremely | ||
2341 | specific to the implementation. | ||
2342 | Usually, the recipe's | ||
2343 | <link linkend='var-bb-PROVIDES'><filename>PROVIDES</filename></link>, | ||
2344 | <link linkend='var-bb-PN'><filename>PN</filename></link>, and | ||
2345 | <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> | ||
2346 | variables would need to be modified by the extension class. | ||
2347 | For specific examples, see the OE-Core | ||
2348 | <filename>native</filename>, <filename>nativesdk</filename>, | ||
2349 | and <filename>multilib</filename> classes. | ||
2350 | </note> | ||
2351 | <itemizedlist> | ||
2352 | <listitem><para><emphasis><filename>BBCLASSEXTEND</filename>:</emphasis> | ||
2353 | This variable is a space separated list of classes used to "extend" the | ||
2354 | recipe for each variant. | ||
2355 | Here is an example that results in a second incarnation of the current | ||
2356 | recipe being available. | ||
2357 | This second incarnation will have the "native" class inherited. | ||
2358 | <literallayout class='monospaced'> | ||
2359 | BBCLASSEXTEND = "native" | ||
2360 | </literallayout></para></listitem> | ||
2361 | <listitem><para><emphasis><filename>BBVERSIONS</filename>:</emphasis> | ||
2362 | This variable allows a single recipe to build multiple versions of a | ||
2363 | project from a single recipe file. | ||
2364 | You can also specify conditional metadata | ||
2365 | (using the | ||
2366 | <link linkend='var-bb-OVERRIDES'><filename>OVERRIDES</filename></link> | ||
2367 | mechanism) for a single version, or an optionally named range of versions. | ||
2368 | Here is an example: | ||
2369 | <literallayout class='monospaced'> | ||
2370 | BBVERSIONS = "1.0 2.0 git" | ||
2371 | SRC_URI_git = "git://someurl/somepath.git" | ||
2372 | |||
2373 | BBVERSIONS = "1.0.[0-6]:1.0.0+ \ 1.0.[7-9]:1.0.7+" | ||
2374 | SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;patch=1" | ||
2375 | </literallayout> | ||
2376 | The name of the range defaults to the original version of the | ||
2377 | recipe. | ||
2378 | For example, in OpenEmbedded, the recipe file | ||
2379 | <filename>foo_1.0.0+.bb</filename> creates a default name range | ||
2380 | of <filename>1.0.0+</filename>. | ||
2381 | This is useful because the range name is not only placed | ||
2382 | into overrides, but it is also made available for the metadata to use | ||
2383 | in the variable that defines the base recipe versions for use in | ||
2384 | <filename>file://</filename> search paths | ||
2385 | (<link linkend='var-bb-FILESPATH'><filename>FILESPATH</filename></link>). | ||
2386 | </para></listitem> | ||
2387 | </itemizedlist> | ||
2388 | </para> | ||
2389 | </section> | ||
2390 | |||
2391 | <section id='dependencies'> | ||
2392 | <title>Dependencies</title> | ||
2393 | |||
2394 | <para> | ||
2395 | To allow for efficient parallel processing, BitBake handles | ||
2396 | dependencies at the task level. | ||
2397 | Dependencies can exist both between tasks within a single recipe | ||
2398 | and between tasks in different recipes. | ||
2399 | Following are examples of each: | ||
2400 | <itemizedlist> | ||
2401 | <listitem><para>For tasks within a single recipe, a | ||
2402 | recipe's <filename>do_configure</filename> | ||
2403 | task might need to complete before its | ||
2404 | <filename>do_compile</filename> task can run. | ||
2405 | </para></listitem> | ||
2406 | <listitem><para>For tasks in different recipes, one | ||
2407 | recipe's <filename>do_configure</filename> | ||
2408 | task might require another recipe's | ||
2409 | <filename>do_populate_sysroot</filename> | ||
2410 | task to finish first such that the libraries and headers | ||
2411 | provided by the other recipe are available. | ||
2412 | </para></listitem> | ||
2413 | </itemizedlist> | ||
2414 | </para> | ||
2415 | |||
2416 | <para> | ||
2417 | This section describes several ways to declare dependencies. | ||
2418 | Remember, even though dependencies are declared in different ways, they | ||
2419 | are all simply dependencies between tasks. | ||
2420 | </para> | ||
2421 | |||
2422 | <section id='dependencies-internal-to-the-bb-file'> | ||
2423 | <title>Dependencies Internal to the <filename>.bb</filename> File</title> | ||
2424 | |||
2425 | <para> | ||
2426 | BitBake uses the <filename>addtask</filename> directive | ||
2427 | to manage dependencies that are internal to a given recipe | ||
2428 | file. | ||
2429 | You can use the <filename>addtask</filename> directive to | ||
2430 | indicate when a task is dependent on other tasks or when | ||
2431 | other tasks depend on that recipe. | ||
2432 | Here is an example: | ||
2433 | <literallayout class='monospaced'> | ||
2434 | addtask printdate after do_fetch before do_build | ||
2435 | </literallayout> | ||
2436 | In this example, the <filename>do_printdate</filename> | ||
2437 | task depends on the completion of the | ||
2438 | <filename>do_fetch</filename> task, and the | ||
2439 | <filename>do_build</filename> task depends on the | ||
2440 | completion of the <filename>do_printdate</filename> | ||
2441 | task. | ||
2442 | <note><para> | ||
2443 | For a task to run, it must be a direct or indirect | ||
2444 | dependency of some other task that is scheduled to | ||
2445 | run.</para> | ||
2446 | |||
2447 | <para>For illustration, here are some examples: | ||
2448 | <itemizedlist> | ||
2449 | <listitem><para> | ||
2450 | The directive | ||
2451 | <filename>addtask mytask before do_configure</filename> | ||
2452 | causes <filename>do_mytask</filename> to run before | ||
2453 | <filename>do_configure</filename> runs. | ||
2454 | Be aware that <filename>do_mytask</filename> still only | ||
2455 | runs if its <link linkend='checksums'>input checksum</link> | ||
2456 | has changed since the last time it was run. | ||
2457 | Changes to the input checksum of | ||
2458 | <filename>do_mytask</filename> also indirectly cause | ||
2459 | <filename>do_configure</filename> to run. | ||
2460 | </para></listitem> | ||
2461 | <listitem><para> | ||
2462 | The directive | ||
2463 | <filename>addtask mytask after do_configure</filename> | ||
2464 | by itself never causes <filename>do_mytask</filename> | ||
2465 | to run. | ||
2466 | <filename>do_mytask</filename> can still be run manually | ||
2467 | as follows: | ||
2468 | <literallayout class='monospaced'> | ||
2469 | $ bitbake <replaceable>recipe</replaceable> -c mytask | ||
2470 | </literallayout> | ||
2471 | Declaring <filename>do_mytask</filename> as a dependency | ||
2472 | of some other task that is scheduled to run also causes | ||
2473 | it to run. | ||
2474 | Regardless, the task runs after | ||
2475 | <filename>do_configure</filename>. | ||
2476 | </para></listitem> | ||
2477 | </itemizedlist></para> | ||
2478 | </note> | ||
2479 | </para> | ||
2480 | </section> | ||
2481 | |||
2482 | <section id='build-dependencies'> | ||
2483 | <title>Build Dependencies</title> | ||
2484 | |||
2485 | <para> | ||
2486 | BitBake uses the | ||
2487 | <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> | ||
2488 | variable to manage build time dependencies. | ||
2489 | The <filename>[deptask]</filename> varflag for tasks | ||
2490 | signifies the task of each | ||
2491 | item listed in <filename>DEPENDS</filename> that must | ||
2492 | complete before that task can be executed. | ||
2493 | Here is an example: | ||
2494 | <literallayout class='monospaced'> | ||
2495 | do_configure[deptask] = "do_populate_sysroot" | ||
2496 | </literallayout> | ||
2497 | In this example, the <filename>do_populate_sysroot</filename> | ||
2498 | task of each item in <filename>DEPENDS</filename> must complete before | ||
2499 | <filename>do_configure</filename> can execute. | ||
2500 | </para> | ||
2501 | </section> | ||
2502 | |||
2503 | <section id='runtime-dependencies'> | ||
2504 | <title>Runtime Dependencies</title> | ||
2505 | |||
2506 | <para> | ||
2507 | BitBake uses the | ||
2508 | <link linkend='var-bb-PACKAGES'><filename>PACKAGES</filename></link>, | ||
2509 | <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link>, and | ||
2510 | <link linkend='var-bb-RRECOMMENDS'><filename>RRECOMMENDS</filename></link> | ||
2511 | variables to manage runtime dependencies. | ||
2512 | </para> | ||
2513 | |||
2514 | <para> | ||
2515 | The <filename>PACKAGES</filename> variable lists runtime | ||
2516 | packages. | ||
2517 | Each of those packages can have <filename>RDEPENDS</filename> and | ||
2518 | <filename>RRECOMMENDS</filename> runtime dependencies. | ||
2519 | The <filename>[rdeptask]</filename> flag for tasks is used to | ||
2520 | signify the task of each | ||
2521 | item runtime dependency which must have completed before that | ||
2522 | task can be executed. | ||
2523 | <literallayout class='monospaced'> | ||
2524 | do_package_qa[rdeptask] = "do_packagedata" | ||
2525 | </literallayout> | ||
2526 | In the previous example, the <filename>do_packagedata</filename> | ||
2527 | task of each item in <filename>RDEPENDS</filename> must have | ||
2528 | completed before <filename>do_package_qa</filename> can execute. | ||
2529 | Although <filename>RDEPENDS</filename> contains entries from the | ||
2530 | runtime dependency namespace, BitBake knows how to map them back | ||
2531 | to the build-time dependency namespace, in which the tasks are defined. | ||
2532 | </para> | ||
2533 | </section> | ||
2534 | |||
2535 | <section id='recursive-dependencies'> | ||
2536 | <title>Recursive Dependencies</title> | ||
2537 | |||
2538 | <para> | ||
2539 | BitBake uses the <filename>[recrdeptask]</filename> flag to manage | ||
2540 | recursive task dependencies. | ||
2541 | BitBake looks through the build-time and runtime | ||
2542 | dependencies of the current recipe, looks through | ||
2543 | the task's inter-task | ||
2544 | dependencies, and then adds dependencies for the | ||
2545 | listed task. | ||
2546 | Once BitBake has accomplished this, it recursively works through | ||
2547 | the dependencies of those tasks. | ||
2548 | Iterative passes continue until all dependencies are discovered | ||
2549 | and added. | ||
2550 | </para> | ||
2551 | |||
2552 | <para> | ||
2553 | The <filename>[recrdeptask]</filename> flag is most commonly | ||
2554 | used in high-level | ||
2555 | recipes that need to wait for some task to finish "globally". | ||
2556 | For example, <filename>image.bbclass</filename> has the following: | ||
2557 | <literallayout class='monospaced'> | ||
2558 | do_rootfs[recrdeptask] += "do_packagedata" | ||
2559 | </literallayout> | ||
2560 | This statement says that the <filename>do_packagedata</filename> | ||
2561 | task of the current recipe and all recipes reachable | ||
2562 | (by way of dependencies) from the | ||
2563 | image recipe must run before the <filename>do_rootfs</filename> | ||
2564 | task can run. | ||
2565 | </para> | ||
2566 | |||
2567 | <para> | ||
2568 | BitBake allows a task to recursively depend on itself by | ||
2569 | referencing itself in the task list: | ||
2570 | <literallayout class='monospaced'> | ||
2571 | do_a[recrdeptask] = "do_a do_b" | ||
2572 | </literallayout> | ||
2573 | In the same way as before, this means that the <filename>do_a</filename> | ||
2574 | and <filename>do_b</filename> tasks of the current recipe and all | ||
2575 | recipes reachable (by way of dependencies) from the recipe | ||
2576 | must run before the <filename>do_a</filename> task can run. In this | ||
2577 | case BitBake will ignore the current recipe's <filename>do_a</filename> | ||
2578 | task circular dependency on itself. | ||
2579 | </para> | ||
2580 | </section> | ||
2581 | |||
2582 | <section id='inter-task-dependencies'> | ||
2583 | <title>Inter-Task Dependencies</title> | ||
2584 | |||
2585 | <para> | ||
2586 | BitBake uses the <filename>[depends]</filename> | ||
2587 | flag in a more generic form | ||
2588 | to manage inter-task dependencies. | ||
2589 | This more generic form allows for inter-dependency | ||
2590 | checks for specific tasks rather than checks for | ||
2591 | the data in <filename>DEPENDS</filename>. | ||
2592 | Here is an example: | ||
2593 | <literallayout class='monospaced'> | ||
2594 | do_patch[depends] = "quilt-native:do_populate_sysroot" | ||
2595 | </literallayout> | ||
2596 | In this example, the <filename>do_populate_sysroot</filename> | ||
2597 | task of the target <filename>quilt-native</filename> | ||
2598 | must have completed before the | ||
2599 | <filename>do_patch</filename> task can execute. | ||
2600 | </para> | ||
2601 | |||
2602 | <para> | ||
2603 | The <filename>[rdepends]</filename> flag works in a similar | ||
2604 | way but takes targets | ||
2605 | in the runtime namespace instead of the build-time dependency | ||
2606 | namespace. | ||
2607 | </para> | ||
2608 | </section> | ||
2609 | </section> | ||
2610 | |||
2611 | <section id='functions-you-can-call-from-within-python'> | ||
2612 | <title>Functions You Can Call From Within Python</title> | ||
2613 | |||
2614 | <para> | ||
2615 | BitBake provides many functions you can call from | ||
2616 | within Python functions. | ||
2617 | This section lists the most commonly used functions, | ||
2618 | and mentions where to find others. | ||
2619 | </para> | ||
2620 | |||
2621 | <section id='functions-for-accessing-datastore-variables'> | ||
2622 | <title>Functions for Accessing Datastore Variables</title> | ||
2623 | |||
2624 | <para> | ||
2625 | It is often necessary to access variables in the | ||
2626 | BitBake datastore using Python functions. | ||
2627 | The BitBake datastore has an API that allows you this | ||
2628 | access. | ||
2629 | Here is a list of available operations: | ||
2630 | </para> | ||
2631 | |||
2632 | <para> | ||
2633 | <informaltable frame='none'> | ||
2634 | <tgroup cols='2' align='left' colsep='1' rowsep='1'> | ||
2635 | <colspec colname='c1' colwidth='1*'/> | ||
2636 | <colspec colname='c2' colwidth='1*'/> | ||
2637 | <thead> | ||
2638 | <row> | ||
2639 | <entry align="left"><emphasis>Operation</emphasis></entry> | ||
2640 | <entry align="left"><emphasis>Description</emphasis></entry> | ||
2641 | </row> | ||
2642 | </thead> | ||
2643 | <tbody> | ||
2644 | <row> | ||
2645 | <entry align="left"><filename>d.getVar("X", expand)</filename></entry> | ||
2646 | <entry align="left">Returns the value of variable "X". | ||
2647 | Using "expand=True" expands the value. | ||
2648 | Returns "None" if the variable "X" does not exist.</entry> | ||
2649 | </row> | ||
2650 | <row> | ||
2651 | <entry align="left"><filename>d.setVar("X", "value")</filename></entry> | ||
2652 | <entry align="left">Sets the variable "X" to "value".</entry> | ||
2653 | </row> | ||
2654 | <row> | ||
2655 | <entry align="left"><filename>d.appendVar("X", "value")</filename></entry> | ||
2656 | <entry align="left">Adds "value" to the end of the variable "X". | ||
2657 | Acts like <filename>d.setVar("X", "value")</filename> | ||
2658 | if the variable "X" does not exist.</entry> | ||
2659 | </row> | ||
2660 | <row> | ||
2661 | <entry align="left"><filename>d.prependVar("X", "value")</filename></entry> | ||
2662 | <entry align="left">Adds "value" to the start of the variable "X". | ||
2663 | Acts like <filename>d.setVar("X", "value")</filename> | ||
2664 | if the variable "X" does not exist.</entry> | ||
2665 | </row> | ||
2666 | <row> | ||
2667 | <entry align="left"><filename>d.delVar("X")</filename></entry> | ||
2668 | <entry align="left">Deletes the variable "X" from the datastore. | ||
2669 | Does nothing if the variable "X" does not exist.</entry> | ||
2670 | </row> | ||
2671 | <row> | ||
2672 | <entry align="left"><filename>d.renameVar("X", "Y")</filename></entry> | ||
2673 | <entry align="left">Renames the variable "X" to "Y". | ||
2674 | Does nothing if the variable "X" does not exist.</entry> | ||
2675 | </row> | ||
2676 | <row> | ||
2677 | <entry align="left"><filename>d.getVarFlag("X", flag, expand)</filename></entry> | ||
2678 | <entry align="left">Returns the value of variable "X". | ||
2679 | Using "expand=True" expands the value. | ||
2680 | Returns "None" if either the variable "X" or the named flag | ||
2681 | does not exist.</entry> | ||
2682 | </row> | ||
2683 | <row> | ||
2684 | <entry align="left"><filename>d.setVarFlag("X", flag, "value")</filename></entry> | ||
2685 | <entry align="left">Sets the named flag for variable "X" to "value".</entry> | ||
2686 | </row> | ||
2687 | <row> | ||
2688 | <entry align="left"><filename>d.appendVarFlag("X", flag, "value")</filename></entry> | ||
2689 | <entry align="left">Appends "value" to the named flag on the | ||
2690 | variable "X". | ||
2691 | Acts like <filename>d.setVarFlag("X", flag, "value")</filename> | ||
2692 | if the named flag does not exist.</entry> | ||
2693 | </row> | ||
2694 | <row> | ||
2695 | <entry align="left"><filename>d.prependVarFlag("X", flag, "value")</filename></entry> | ||
2696 | <entry align="left">Prepends "value" to the named flag on | ||
2697 | the variable "X". | ||
2698 | Acts like <filename>d.setVarFlag("X", flag, "value")</filename> | ||
2699 | if the named flag does not exist.</entry> | ||
2700 | </row> | ||
2701 | <row> | ||
2702 | <entry align="left"><filename>d.delVarFlag("X", flag)</filename></entry> | ||
2703 | <entry align="left">Deletes the named flag on the variable | ||
2704 | "X" from the datastore.</entry> | ||
2705 | </row> | ||
2706 | <row> | ||
2707 | <entry align="left"><filename>d.setVarFlags("X", flagsdict)</filename></entry> | ||
2708 | <entry align="left">Sets the flags specified in | ||
2709 | the <filename>flagsdict()</filename> parameter. | ||
2710 | <filename>setVarFlags</filename> does not clear previous flags. | ||
2711 | Think of this operation as <filename>addVarFlags</filename>.</entry> | ||
2712 | </row> | ||
2713 | <row> | ||
2714 | <entry align="left"><filename>d.getVarFlags("X")</filename></entry> | ||
2715 | <entry align="left">Returns a <filename>flagsdict</filename> | ||
2716 | of the flags for the variable "X". | ||
2717 | Returns "None" if the variable "X" does not exist.</entry> | ||
2718 | </row> | ||
2719 | <row> | ||
2720 | <entry align="left"><filename>d.delVarFlags("X")</filename></entry> | ||
2721 | <entry align="left">Deletes all the flags for the variable "X". | ||
2722 | Does nothing if the variable "X" does not exist.</entry> | ||
2723 | </row> | ||
2724 | <row> | ||
2725 | <entry align="left"><filename>d.expand(expression)</filename></entry> | ||
2726 | <entry align="left">Expands variable references in the specified | ||
2727 | string expression. | ||
2728 | References to variables that do not exist are left as is. | ||
2729 | For example, <filename>d.expand("foo ${X}")</filename> | ||
2730 | expands to the literal string "foo ${X}" if the | ||
2731 | variable "X" does not exist.</entry> | ||
2732 | </row> | ||
2733 | </tbody> | ||
2734 | </tgroup> | ||
2735 | </informaltable> | ||
2736 | </para> | ||
2737 | </section> | ||
2738 | |||
2739 | <section id='other-functions'> | ||
2740 | <title>Other Functions</title> | ||
2741 | |||
2742 | <para> | ||
2743 | You can find many other functions that can be called | ||
2744 | from Python by looking at the source code of the | ||
2745 | <filename>bb</filename> module, which is in | ||
2746 | <filename>bitbake/lib/bb</filename>. | ||
2747 | For example, | ||
2748 | <filename>bitbake/lib/bb/utils.py</filename> includes | ||
2749 | the commonly used functions | ||
2750 | <filename>bb.utils.contains()</filename> and | ||
2751 | <filename>bb.utils.mkdirhier()</filename>, which come | ||
2752 | with docstrings. | ||
2753 | </para> | ||
2754 | </section> | ||
2755 | </section> | ||
2756 | |||
2757 | <section id='task-checksums-and-setscene'> | ||
2758 | <title>Task Checksums and Setscene</title> | ||
2759 | |||
2760 | <para> | ||
2761 | BitBake uses checksums (or signatures) along with the setscene | ||
2762 | to determine if a task needs to be run. | ||
2763 | This section describes the process. | ||
2764 | To help understand how BitBake does this, the section assumes an | ||
2765 | OpenEmbedded metadata-based example. | ||
2766 | </para> | ||
2767 | |||
2768 | <para> | ||
2769 | These checksums are stored in | ||
2770 | <link linkend='var-bb-STAMP'><filename>STAMP</filename></link>. | ||
2771 | You can examine the checksums using the following BitBake command: | ||
2772 | <literallayout class='monospaced'> | ||
2773 | $ bitbake-dumpsigs | ||
2774 | </literallayout> | ||
2775 | This command returns the signature data in a readable format | ||
2776 | that allows you to examine the inputs used when the | ||
2777 | OpenEmbedded build system generates signatures. | ||
2778 | For example, using <filename>bitbake-dumpsigs</filename> | ||
2779 | allows you to examine the <filename>do_compile</filename> | ||
2780 | task's “sigdata†for a C application (e.g. | ||
2781 | <filename>bash</filename>). | ||
2782 | Running the command also reveals that the “CC†variable is part of | ||
2783 | the inputs that are hashed. | ||
2784 | Any changes to this variable would invalidate the stamp and | ||
2785 | cause the <filename>do_compile</filename> task to run. | ||
2786 | </para> | ||
2787 | |||
2788 | <para> | ||
2789 | The following list describes related variables: | ||
2790 | <itemizedlist> | ||
2791 | <listitem><para> | ||
2792 | <link linkend='var-bb-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></link>: | ||
2793 | Specifies the name of the function to call during | ||
2794 | the "setscene" part of the task's execution in order | ||
2795 | to validate the list of task hashes. | ||
2796 | </para></listitem> | ||
2797 | <listitem><para> | ||
2798 | <link linkend='var-bb-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></link>: | ||
2799 | Specifies a function BitBake calls that determines | ||
2800 | whether BitBake requires a setscene dependency to | ||
2801 | be met. | ||
2802 | </para></listitem> | ||
2803 | <listitem><para> | ||
2804 | <link linkend='var-bb-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></link>: | ||
2805 | Specifies a function to call that verifies the list of | ||
2806 | planned task execution before the main task execution | ||
2807 | happens. | ||
2808 | </para></listitem> | ||
2809 | <listitem><para> | ||
2810 | <link linkend='var-bb-BB_STAMP_POLICY'><filename>BB_STAMP_POLICY</filename></link>: | ||
2811 | Defines the mode for comparing timestamps of stamp files. | ||
2812 | </para></listitem> | ||
2813 | <listitem><para> | ||
2814 | <link linkend='var-bb-BB_STAMP_WHITELIST'><filename>BB_STAMP_WHITELIST</filename></link>: | ||
2815 | Lists stamp files that are looked at when the stamp policy | ||
2816 | is "whitelist". | ||
2817 | </para></listitem> | ||
2818 | <listitem><para> | ||
2819 | <link linkend='var-bb-BB_TASKHASH'><filename>BB_TASKHASH</filename></link>: | ||
2820 | Within an executing task, this variable holds the hash | ||
2821 | of the task as returned by the currently enabled | ||
2822 | signature generator. | ||
2823 | </para></listitem> | ||
2824 | <listitem><para> | ||
2825 | <link linkend='var-bb-STAMP'><filename>STAMP</filename></link>: | ||
2826 | The base path to create stamp files. | ||
2827 | </para></listitem> | ||
2828 | <listitem><para> | ||
2829 | <link linkend='var-bb-STAMPCLEAN'><filename>STAMPCLEAN</filename></link>: | ||
2830 | Again, the base path to create stamp files but can use wildcards | ||
2831 | for matching a range of files for clean operations. | ||
2832 | </para></listitem> | ||
2833 | </itemizedlist> | ||
2834 | </para> | ||
2835 | </section> | ||
2836 | |||
2837 | <section id='wildcard-support-in-variables'> | ||
2838 | <title>Wildcard Support in Variables</title> | ||
2839 | |||
2840 | <para> | ||
2841 | Support for wildcard use in variables varies depending on the | ||
2842 | context in which it is used. | ||
2843 | For example, some variables and file names allow limited use of | ||
2844 | wildcards through the "<filename>%</filename>" and | ||
2845 | "<filename>*</filename>" characters. | ||
2846 | Other variables or names support Python's | ||
2847 | <ulink url='https://docs.python.org/3/library/glob.html'><filename>glob</filename></ulink> | ||
2848 | syntax, | ||
2849 | <ulink url='https://docs.python.org/3/library/fnmatch.html#module-fnmatch'><filename>fnmatch</filename></ulink> | ||
2850 | syntax, or | ||
2851 | <ulink url='https://docs.python.org/3/library/re.html#re'><filename>Regular Expression (re)</filename></ulink> | ||
2852 | syntax. | ||
2853 | </para> | ||
2854 | |||
2855 | <para> | ||
2856 | For variables that have wildcard suport, the | ||
2857 | documentation describes which form of wildcard, its | ||
2858 | use, and its limitations. | ||
2859 | </para> | ||
2860 | </section> | ||
2861 | |||
2862 | </chapter> | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml deleted file mode 100644 index 4c29b2464f..0000000000 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml +++ /dev/null | |||
@@ -1,2537 +0,0 @@ | |||
1 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" | ||
2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" | ||
3 | [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > | ||
4 | |||
5 | <!-- Dummy chapter --> | ||
6 | <chapter id='ref-bb-variables-glos'> | ||
7 | |||
8 | <title>Variables Glossary</title> | ||
9 | |||
10 | <para> | ||
11 | This chapter lists common variables used by BitBake and gives an overview | ||
12 | of their function and contents. | ||
13 | </para> | ||
14 | |||
15 | <note> | ||
16 | Following are some points regarding the variables listed in this glossary: | ||
17 | <itemizedlist> | ||
18 | <listitem><para>The variables listed in this glossary | ||
19 | are specific to BitBake. | ||
20 | Consequently, the descriptions are limited to that context. | ||
21 | </para></listitem> | ||
22 | <listitem><para>Also, variables exist in other systems that use BitBake | ||
23 | (e.g. The Yocto Project and OpenEmbedded) that have names identical | ||
24 | to those found in this glossary. | ||
25 | For such cases, the variables in those systems extend the | ||
26 | functionality of the variable as it is described here in | ||
27 | this glossary. | ||
28 | </para></listitem> | ||
29 | <listitem><para>Finally, there are variables mentioned in this | ||
30 | glossary that do not appear in the BitBake glossary. | ||
31 | These other variables are variables used in systems that use | ||
32 | BitBake. | ||
33 | </para></listitem> | ||
34 | </itemizedlist> | ||
35 | </note> | ||
36 | |||
37 | <glossary id='ref-bb-variables-glossary'> | ||
38 | |||
39 | <para> | ||
40 | <link linkend='var-bb-ASSUME_PROVIDED'>A</link> | ||
41 | <link linkend='var-bb-B'>B</link> | ||
42 | <link linkend='var-bb-CACHE'>C</link> | ||
43 | <link linkend='var-bb-DEFAULT_PREFERENCE'>D</link> | ||
44 | <link linkend='var-bb-EXCLUDE_FROM_WORLD'>E</link> | ||
45 | <link linkend='var-bb-FAKEROOT'>F</link> | ||
46 | <link linkend='var-bb-GITDIR'>G</link> | ||
47 | <link linkend='var-bb-HGDIR'>H</link> | ||
48 | <link linkend='var-bb-INHERIT'>I</link> | ||
49 | <!-- <link linkend='var-glossary-j'>J</link> --> | ||
50 | <!-- <link linkend='var-KARCH'>K</link> --> | ||
51 | <link linkend='var-bb-LAYERDEPENDS'>L</link> | ||
52 | <link linkend='var-bb-MIRRORS'>M</link> | ||
53 | <!-- <link linkend='var-glossary-n'>N</link> --> | ||
54 | <link linkend='var-bb-OVERRIDES'>O</link> | ||
55 | <link linkend='var-bb-P4DIR'>P</link> | ||
56 | <!-- <link linkend='var-QMAKE_PROFILES'>Q</link> --> | ||
57 | <link linkend='var-bb-RDEPENDS'>R</link> | ||
58 | <link linkend='var-bb-SECTION'>S</link> | ||
59 | <link linkend='var-bb-T'>T</link> | ||
60 | <!-- <link linkend='var-UBOOT_CONFIG'>U</link> --> | ||
61 | <!-- <link linkend='var-glossary-v'>V</link> --> | ||
62 | <!-- <link linkend='var-WARN_QA'>W</link> --> | ||
63 | <!-- <link linkend='var-glossary-x'>X</link> --> | ||
64 | <!-- <link linkend='var-glossary-y'>Y</link> --> | ||
65 | <!-- <link linkend='var-glossary-z'>Z</link>--> | ||
66 | </para> | ||
67 | |||
68 | <glossdiv id='var-bb-glossary-a'><title>A</title> | ||
69 | |||
70 | <glossentry id='var-bb-ASSUME_PROVIDED'><glossterm>ASSUME_PROVIDED</glossterm> | ||
71 | <glossdef> | ||
72 | <para> | ||
73 | Lists recipe names | ||
74 | (<link linkend='var-bb-PN'><filename>PN</filename></link> | ||
75 | values) BitBake does not attempt to build. | ||
76 | Instead, BitBake assumes these recipes have already been | ||
77 | built. | ||
78 | </para> | ||
79 | |||
80 | <para> | ||
81 | In OpenEmbedded-Core, <filename>ASSUME_PROVIDED</filename> | ||
82 | mostly specifies native tools that should not be built. | ||
83 | An example is <filename>git-native</filename>, which | ||
84 | when specified allows for the Git binary from the host to | ||
85 | be used rather than building | ||
86 | <filename>git-native</filename>. | ||
87 | </para> | ||
88 | </glossdef> | ||
89 | </glossentry> | ||
90 | |||
91 | </glossdiv> | ||
92 | |||
93 | |||
94 | <glossdiv id='var-bb-glossary-b'><title>B</title> | ||
95 | |||
96 | <glossentry id='var-bb-B'><glossterm>B</glossterm> | ||
97 | <glossdef> | ||
98 | <para> | ||
99 | The directory in which BitBake executes functions | ||
100 | during a recipe's build process. | ||
101 | </para> | ||
102 | </glossdef> | ||
103 | </glossentry> | ||
104 | |||
105 | <glossentry id='var-bb-BB_ALLOWED_NETWORKS'><glossterm>BB_ALLOWED_NETWORKS</glossterm> | ||
106 | <glossdef> | ||
107 | <para> | ||
108 | Specifies a space-delimited list of hosts that the fetcher | ||
109 | is allowed to use to obtain the required source code. | ||
110 | Following are considerations surrounding this variable: | ||
111 | <itemizedlist> | ||
112 | <listitem><para> | ||
113 | This host list is only used if | ||
114 | <link linkend='var-bb-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></link> | ||
115 | is either not set or set to "0". | ||
116 | </para></listitem> | ||
117 | <listitem><para> | ||
118 | Limited support for the "<filename>*</filename>" | ||
119 | wildcard character for matching against the | ||
120 | beginning of host names exists. | ||
121 | For example, the following setting matches | ||
122 | <filename>git.gnu.org</filename>, | ||
123 | <filename>ftp.gnu.org</filename>, and | ||
124 | <filename>foo.git.gnu.org</filename>. | ||
125 | <literallayout class='monospaced'> | ||
126 | BB_ALLOWED_NETWORKS = "*.gnu.org" | ||
127 | </literallayout> | ||
128 | <note><title>Important</title> | ||
129 | <para>The use of the "<filename>*</filename>" | ||
130 | character only works at the beginning of | ||
131 | a host name and it must be isolated from | ||
132 | the remainder of the host name. | ||
133 | You cannot use the wildcard character in any | ||
134 | other location of the name or combined with | ||
135 | the front part of the name.</para> | ||
136 | |||
137 | <para>For example, | ||
138 | <filename>*.foo.bar</filename> is supported, | ||
139 | while <filename>*aa.foo.bar</filename> is not. | ||
140 | </para> | ||
141 | </note> | ||
142 | </para></listitem> | ||
143 | <listitem><para> | ||
144 | Mirrors not in the host list are skipped and | ||
145 | logged in debug. | ||
146 | </para></listitem> | ||
147 | <listitem><para> | ||
148 | Attempts to access networks not in the host list | ||
149 | cause a failure. | ||
150 | </para></listitem> | ||
151 | </itemizedlist> | ||
152 | Using <filename>BB_ALLOWED_NETWORKS</filename> in | ||
153 | conjunction with | ||
154 | <link linkend='var-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link> | ||
155 | is very useful. | ||
156 | Adding the host you want to use to | ||
157 | <filename>PREMIRRORS</filename> results in the source code | ||
158 | being fetched from an allowed location and avoids raising | ||
159 | an error when a host that is not allowed is in a | ||
160 | <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link> | ||
161 | statement. | ||
162 | This is because the fetcher does not attempt to use the | ||
163 | host listed in <filename>SRC_URI</filename> after a | ||
164 | successful fetch from the | ||
165 | <filename>PREMIRRORS</filename> occurs. | ||
166 | </para> | ||
167 | </glossdef> | ||
168 | </glossentry> | ||
169 | |||
170 | <glossentry id='var-bb-BB_CONSOLELOG'><glossterm>BB_CONSOLELOG</glossterm> | ||
171 | <glossdef> | ||
172 | <para> | ||
173 | Specifies the path to a log file into which BitBake's user | ||
174 | interface writes output during the build. | ||
175 | </para> | ||
176 | </glossdef> | ||
177 | </glossentry> | ||
178 | |||
179 | <glossentry id='var-bb-BB_CURRENTTASK'><glossterm>BB_CURRENTTASK</glossterm> | ||
180 | <glossdef> | ||
181 | <para> | ||
182 | Contains the name of the currently running task. | ||
183 | The name does not include the | ||
184 | <filename>do_</filename> prefix. | ||
185 | </para> | ||
186 | </glossdef> | ||
187 | </glossentry> | ||
188 | |||
189 | <glossentry id='var-bb-BB_DANGLINGAPPENDS_WARNONLY'><glossterm>BB_DANGLINGAPPENDS_WARNONLY</glossterm> | ||
190 | <glossdef> | ||
191 | <para> | ||
192 | Defines how BitBake handles situations where an append | ||
193 | file (<filename>.bbappend</filename>) has no | ||
194 | corresponding recipe file (<filename>.bb</filename>). | ||
195 | This condition often occurs when layers get out of sync | ||
196 | (e.g. <filename>oe-core</filename> bumps a | ||
197 | recipe version and the old recipe no longer exists and the | ||
198 | other layer has not been updated to the new version | ||
199 | of the recipe yet). | ||
200 | </para> | ||
201 | |||
202 | <para> | ||
203 | The default fatal behavior is safest because it is | ||
204 | the sane reaction given something is out of sync. | ||
205 | It is important to realize when your changes are no longer | ||
206 | being applied. | ||
207 | </para> | ||
208 | </glossdef> | ||
209 | </glossentry> | ||
210 | |||
211 | <glossentry id='var-bb-BB_DEFAULT_TASK'><glossterm>BB_DEFAULT_TASK</glossterm> | ||
212 | <glossdef> | ||
213 | <para> | ||
214 | The default task to use when none is specified (e.g. | ||
215 | with the <filename>-c</filename> command line option). | ||
216 | The task name specified should not include the | ||
217 | <filename>do_</filename> prefix. | ||
218 | </para> | ||
219 | </glossdef> | ||
220 | </glossentry> | ||
221 | |||
222 | <glossentry id='var-bb-BB_DISKMON_DIRS'><glossterm>BB_DISKMON_DIRS</glossterm> | ||
223 | <glossdef> | ||
224 | <para> | ||
225 | Monitors disk space and available inodes during the build | ||
226 | and allows you to control the build based on these | ||
227 | parameters. | ||
228 | </para> | ||
229 | |||
230 | <para> | ||
231 | Disk space monitoring is disabled by default. | ||
232 | When setting this variable, use the following form: | ||
233 | <literallayout class='monospaced'> | ||
234 | BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]" | ||
235 | |||
236 | where: | ||
237 | |||
238 | <action> is: | ||
239 | ABORT: Immediately abort the build when | ||
240 | a threshold is broken. | ||
241 | STOPTASKS: Stop the build after the currently | ||
242 | executing tasks have finished when | ||
243 | a threshold is broken. | ||
244 | WARN: Issue a warning but continue the | ||
245 | build when a threshold is broken. | ||
246 | Subsequent warnings are issued as | ||
247 | defined by the | ||
248 | <link linkend='var-bb-BB_DISKMON_WARNINTERVAL'>BB_DISKMON_WARNINTERVAL</link> variable, | ||
249 | which must be defined. | ||
250 | |||
251 | <dir> is: | ||
252 | Any directory you choose. You can specify one or | ||
253 | more directories to monitor by separating the | ||
254 | groupings with a space. If two directories are | ||
255 | on the same device, only the first directory | ||
256 | is monitored. | ||
257 | |||
258 | <threshold> is: | ||
259 | Either the minimum available disk space, | ||
260 | the minimum number of free inodes, or | ||
261 | both. You must specify at least one. To | ||
262 | omit one or the other, simply omit the value. | ||
263 | Specify the threshold using G, M, K for Gbytes, | ||
264 | Mbytes, and Kbytes, respectively. If you do | ||
265 | not specify G, M, or K, Kbytes is assumed by | ||
266 | default. Do not use GB, MB, or KB. | ||
267 | </literallayout> | ||
268 | </para> | ||
269 | |||
270 | <para> | ||
271 | Here are some examples: | ||
272 | <literallayout class='monospaced'> | ||
273 | BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" | ||
274 | BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G" | ||
275 | BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K" | ||
276 | </literallayout> | ||
277 | The first example works only if you also set | ||
278 | the <link linkend='var-bb-BB_DISKMON_WARNINTERVAL'><filename>BB_DISKMON_WARNINTERVAL</filename></link> variable. | ||
279 | This example causes the build system to immediately | ||
280 | abort when either the disk space in <filename>${TMPDIR}</filename> drops | ||
281 | below 1 Gbyte or the available free inodes drops below | ||
282 | 100 Kbytes. | ||
283 | Because two directories are provided with the variable, the | ||
284 | build system also issues a | ||
285 | warning when the disk space in the | ||
286 | <filename>${SSTATE_DIR}</filename> directory drops | ||
287 | below 1 Gbyte or the number of free inodes drops | ||
288 | below 100 Kbytes. | ||
289 | Subsequent warnings are issued during intervals as | ||
290 | defined by the <filename>BB_DISKMON_WARNINTERVAL</filename> | ||
291 | variable. | ||
292 | </para> | ||
293 | |||
294 | <para> | ||
295 | The second example stops the build after all currently | ||
296 | executing tasks complete when the minimum disk space | ||
297 | in the <filename>${TMPDIR}</filename> | ||
298 | directory drops below 1 Gbyte. | ||
299 | No disk monitoring occurs for the free inodes in this case. | ||
300 | </para> | ||
301 | |||
302 | <para> | ||
303 | The final example immediately aborts the build when the | ||
304 | number of free inodes in the <filename>${TMPDIR}</filename> directory | ||
305 | drops below 100 Kbytes. | ||
306 | No disk space monitoring for the directory itself occurs | ||
307 | in this case. | ||
308 | </para> | ||
309 | </glossdef> | ||
310 | </glossentry> | ||
311 | |||
312 | <glossentry id='var-bb-BB_DISKMON_WARNINTERVAL'><glossterm>BB_DISKMON_WARNINTERVAL</glossterm> | ||
313 | <glossdef> | ||
314 | <para> | ||
315 | Defines the disk space and free inode warning intervals. | ||
316 | </para> | ||
317 | |||
318 | <para> | ||
319 | If you are going to use the | ||
320 | <filename>BB_DISKMON_WARNINTERVAL</filename> variable, you must | ||
321 | also use the | ||
322 | <link linkend='var-bb-BB_DISKMON_DIRS'><filename>BB_DISKMON_DIRS</filename></link> variable | ||
323 | and define its action as "WARN". | ||
324 | During the build, subsequent warnings are issued each time | ||
325 | disk space or number of free inodes further reduces by | ||
326 | the respective interval. | ||
327 | </para> | ||
328 | |||
329 | <para> | ||
330 | If you do not provide a <filename>BB_DISKMON_WARNINTERVAL</filename> | ||
331 | variable and you do use <filename>BB_DISKMON_DIRS</filename> with | ||
332 | the "WARN" action, the disk monitoring interval defaults to | ||
333 | the following: | ||
334 | <literallayout class='monospaced'> | ||
335 | BB_DISKMON_WARNINTERVAL = "50M,5K" | ||
336 | </literallayout> | ||
337 | </para> | ||
338 | |||
339 | <para> | ||
340 | When specifying the variable in your configuration file, | ||
341 | use the following form: | ||
342 | <literallayout class='monospaced'> | ||
343 | BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>" | ||
344 | |||
345 | where: | ||
346 | |||
347 | <disk_space_interval> is: | ||
348 | An interval of memory expressed in either | ||
349 | G, M, or K for Gbytes, Mbytes, or Kbytes, | ||
350 | respectively. You cannot use GB, MB, or KB. | ||
351 | |||
352 | <disk_inode_interval> is: | ||
353 | An interval of free inodes expressed in either | ||
354 | G, M, or K for Gbytes, Mbytes, or Kbytes, | ||
355 | respectively. You cannot use GB, MB, or KB. | ||
356 | </literallayout> | ||
357 | </para> | ||
358 | |||
359 | <para> | ||
360 | Here is an example: | ||
361 | <literallayout class='monospaced'> | ||
362 | BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K" | ||
363 | BB_DISKMON_WARNINTERVAL = "50M,5K" | ||
364 | </literallayout> | ||
365 | These variables cause BitBake to | ||
366 | issue subsequent warnings each time the available | ||
367 | disk space further reduces by 50 Mbytes or the number | ||
368 | of free inodes further reduces by 5 Kbytes in the | ||
369 | <filename>${SSTATE_DIR}</filename> directory. | ||
370 | Subsequent warnings based on the interval occur each time | ||
371 | a respective interval is reached beyond the initial warning | ||
372 | (i.e. 1 Gbytes and 100 Kbytes). | ||
373 | </para> | ||
374 | </glossdef> | ||
375 | </glossentry> | ||
376 | |||
377 | <glossentry id='var-bb-BB_ENV_WHITELIST'><glossterm>BB_ENV_WHITELIST</glossterm> | ||
378 | <glossdef> | ||
379 | <para> | ||
380 | Specifies the internal whitelist of variables to allow | ||
381 | through from the external environment into BitBake's | ||
382 | datastore. | ||
383 | If the value of this variable is not specified | ||
384 | (which is the default), the following list is used: | ||
385 | <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link>, | ||
386 | <link linkend='var-bb-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link>, | ||
387 | <link linkend='var-bb-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link>, | ||
388 | and | ||
389 | <link linkend='var-bb-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link>. | ||
390 | <note> | ||
391 | You must set this variable in the external environment | ||
392 | in order for it to work. | ||
393 | </note> | ||
394 | </para> | ||
395 | </glossdef> | ||
396 | </glossentry> | ||
397 | |||
398 | <glossentry id='var-bb-BB_ENV_EXTRAWHITE'><glossterm>BB_ENV_EXTRAWHITE</glossterm> | ||
399 | <glossdef> | ||
400 | <para> | ||
401 | Specifies an additional set of variables to allow through | ||
402 | (whitelist) from the external environment into BitBake's | ||
403 | datastore. | ||
404 | This list of variables are on top of the internal list | ||
405 | set in | ||
406 | <link linkend='var-bb-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link>. | ||
407 | <note> | ||
408 | You must set this variable in the external | ||
409 | environment in order for it to work. | ||
410 | </note> | ||
411 | </para> | ||
412 | </glossdef> | ||
413 | </glossentry> | ||
414 | |||
415 | <glossentry id='var-bb-BB_FETCH_PREMIRRORONLY'><glossterm>BB_FETCH_PREMIRRORONLY</glossterm> | ||
416 | <glossdef> | ||
417 | <para> | ||
418 | When set to "1", causes BitBake's fetcher module to only | ||
419 | search | ||
420 | <link linkend='var-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link> | ||
421 | for files. | ||
422 | BitBake will not search the main | ||
423 | <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link> | ||
424 | or | ||
425 | <link linkend='var-bb-MIRRORS'><filename>MIRRORS</filename></link>. | ||
426 | </para> | ||
427 | </glossdef> | ||
428 | </glossentry> | ||
429 | |||
430 | <glossentry id='var-bb-BB_FILENAME'><glossterm>BB_FILENAME</glossterm> | ||
431 | <glossdef> | ||
432 | <para> | ||
433 | Contains the filename of the recipe that owns the currently | ||
434 | running task. | ||
435 | For example, if the <filename>do_fetch</filename> task that | ||
436 | resides in the <filename>my-recipe.bb</filename> is | ||
437 | executing, the <filename>BB_FILENAME</filename> variable | ||
438 | contains "/foo/path/my-recipe.bb". | ||
439 | </para> | ||
440 | </glossdef> | ||
441 | </glossentry> | ||
442 | |||
443 | <glossentry id='var-bb-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm> | ||
444 | <glossdef> | ||
445 | <para> | ||
446 | Causes tarballs of the Git repositories, including the | ||
447 | Git metadata, to be placed in the | ||
448 | <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link> | ||
449 | directory. | ||
450 | Anyone wishing to create a source mirror would want to | ||
451 | enable this variable. | ||
452 | </para> | ||
453 | |||
454 | <para> | ||
455 | For performance reasons, creating and placing tarballs of | ||
456 | the Git repositories is not the default action by BitBake. | ||
457 | <literallayout class='monospaced'> | ||
458 | BB_GENERATE_MIRROR_TARBALLS = "1" | ||
459 | </literallayout> | ||
460 | </para> | ||
461 | </glossdef> | ||
462 | </glossentry> | ||
463 | |||
464 | <glossentry id='var-bb-BB_HASHCONFIG_WHITELIST'><glossterm>BB_HASHCONFIG_WHITELIST</glossterm> | ||
465 | <glossdef> | ||
466 | <para> | ||
467 | Lists variables that are excluded from base configuration | ||
468 | checksum, which is used to determine if the cache can | ||
469 | be reused. | ||
470 | </para> | ||
471 | |||
472 | <para> | ||
473 | One of the ways BitBake determines whether to re-parse the | ||
474 | main metadata is through checksums of the variables in the | ||
475 | datastore of the base configuration data. | ||
476 | There are variables that you typically want to exclude when | ||
477 | checking whether or not to re-parse and thus rebuild the | ||
478 | cache. | ||
479 | As an example, you would usually exclude | ||
480 | <filename>TIME</filename> and <filename>DATE</filename> | ||
481 | because these variables are always changing. | ||
482 | If you did not exclude them, BitBake would never reuse the | ||
483 | cache. | ||
484 | </para> | ||
485 | </glossdef> | ||
486 | </glossentry> | ||
487 | |||
488 | <glossentry id='var-bb-BB_HASHBASE_WHITELIST'><glossterm>BB_HASHBASE_WHITELIST</glossterm> | ||
489 | <glossdef> | ||
490 | <para> | ||
491 | Lists variables that are excluded from checksum and | ||
492 | dependency data. | ||
493 | Variables that are excluded can therefore change without | ||
494 | affecting the checksum mechanism. | ||
495 | A common example would be the variable for the path of | ||
496 | the build. | ||
497 | BitBake's output should not (and usually does not) depend | ||
498 | on the directory in which it was built. | ||
499 | </para> | ||
500 | </glossdef> | ||
501 | </glossentry> | ||
502 | |||
503 | <glossentry id='var-bb-BB_HASHCHECK_FUNCTION'><glossterm>BB_HASHCHECK_FUNCTION</glossterm> | ||
504 | <glossdef> | ||
505 | <para> | ||
506 | Specifies the name of the function to call during the | ||
507 | "setscene" part of the task's execution in order to | ||
508 | validate the list of task hashes. | ||
509 | The function returns the list of setscene tasks that should | ||
510 | be executed. | ||
511 | </para> | ||
512 | |||
513 | <para> | ||
514 | At this point in the execution of the code, the objective | ||
515 | is to quickly verify if a given setscene function is likely | ||
516 | to work or not. | ||
517 | It's easier to check the list of setscene functions in | ||
518 | one pass than to call many individual tasks. | ||
519 | The returned list need not be completely accurate. | ||
520 | A given setscene task can still later fail. | ||
521 | However, the more accurate the data returned, the more | ||
522 | efficient the build will be. | ||
523 | </para> | ||
524 | </glossdef> | ||
525 | </glossentry> | ||
526 | |||
527 | <glossentry id='var-bb-BB_INVALIDCONF'><glossterm>BB_INVALIDCONF</glossterm> | ||
528 | <glossdef> | ||
529 | <para> | ||
530 | Used in combination with the | ||
531 | <filename>ConfigParsed</filename> event to trigger | ||
532 | re-parsing the base metadata (i.e. all the | ||
533 | recipes). | ||
534 | The <filename>ConfigParsed</filename> event can set the | ||
535 | variable to trigger the re-parse. | ||
536 | You must be careful to avoid recursive loops with this | ||
537 | functionality. | ||
538 | </para> | ||
539 | </glossdef> | ||
540 | </glossentry> | ||
541 | |||
542 | <glossentry id='var-bb-BB_LOGCONFIG'><glossterm>BB_LOGCONFIG</glossterm> | ||
543 | <glossdef> | ||
544 | <para> | ||
545 | Specifies the name of a config file that contains the user | ||
546 | logging configuration. See | ||
547 | <link linkend="logging">Logging</link> for additional | ||
548 | information | ||
549 | </para> | ||
550 | </glossdef> | ||
551 | </glossentry> | ||
552 | |||
553 | <glossentry id='var-bb-BB_LOGFMT'><glossterm>BB_LOGFMT</glossterm> | ||
554 | <glossdef> | ||
555 | <para> | ||
556 | Specifies the name of the log files saved into | ||
557 | <filename>${</filename><link linkend='var-bb-T'><filename>T</filename></link><filename>}</filename>. | ||
558 | By default, the <filename>BB_LOGFMT</filename> variable | ||
559 | is undefined and the log file names get created using the | ||
560 | following form: | ||
561 | <literallayout class='monospaced'> | ||
562 | log.{task}.{pid} | ||
563 | </literallayout> | ||
564 | If you want to force log files to take a specific name, | ||
565 | you can set this variable in a configuration file. | ||
566 | </para> | ||
567 | </glossdef> | ||
568 | </glossentry> | ||
569 | |||
570 | <glossentry id='var-bb-BB_NICE_LEVEL'><glossterm>BB_NICE_LEVEL</glossterm> | ||
571 | <glossdef> | ||
572 | <para> | ||
573 | Allows BitBake to run at a specific priority | ||
574 | (i.e. nice level). | ||
575 | System permissions usually mean that BitBake can reduce its | ||
576 | priority but not raise it again. | ||
577 | See | ||
578 | <link linkend='var-bb-BB_TASK_NICE_LEVEL'><filename>BB_TASK_NICE_LEVEL</filename></link> | ||
579 | for additional information. | ||
580 | </para> | ||
581 | </glossdef> | ||
582 | </glossentry> | ||
583 | |||
584 | <glossentry id='var-bb-BB_NO_NETWORK'><glossterm>BB_NO_NETWORK</glossterm> | ||
585 | <glossdef> | ||
586 | <para> | ||
587 | Disables network access in the BitBake fetcher modules. | ||
588 | With this access disabled, any command that attempts to | ||
589 | access the network becomes an error. | ||
590 | </para> | ||
591 | |||
592 | <para> | ||
593 | Disabling network access is useful for testing source | ||
594 | mirrors, running builds when not connected to the Internet, | ||
595 | and when operating in certain kinds of firewall | ||
596 | environments. | ||
597 | </para> | ||
598 | </glossdef> | ||
599 | </glossentry> | ||
600 | |||
601 | <glossentry id='var-bb-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm> | ||
602 | <glossdef> | ||
603 | <para> | ||
604 | The maximum number of tasks BitBake should run in parallel | ||
605 | at any one time. | ||
606 | If your host development system supports multiple cores, | ||
607 | a good rule of thumb is to set this variable to twice the | ||
608 | number of cores. | ||
609 | </para> | ||
610 | </glossdef> | ||
611 | </glossentry> | ||
612 | |||
613 | <glossentry id='var-bb-BB_NUMBER_PARSE_THREADS'><glossterm>BB_NUMBER_PARSE_THREADS</glossterm> | ||
614 | <glossdef> | ||
615 | <para> | ||
616 | Sets the number of threads BitBake uses when parsing. | ||
617 | By default, the number of threads is equal to the number | ||
618 | of cores on the system. | ||
619 | </para> | ||
620 | </glossdef> | ||
621 | </glossentry> | ||
622 | |||
623 | <glossentry id='var-bb-BB_ORIGENV'><glossterm>BB_ORIGENV</glossterm> | ||
624 | <glossdef> | ||
625 | <para> | ||
626 | Contains a copy of the original external environment in | ||
627 | which BitBake was run. | ||
628 | The copy is taken before any whitelisted variable values | ||
629 | are filtered into BitBake's datastore. | ||
630 | <note> | ||
631 | The contents of this variable is a datastore object | ||
632 | that can be queried using the normal datastore | ||
633 | operations. | ||
634 | </note> | ||
635 | </para> | ||
636 | </glossdef> | ||
637 | </glossentry> | ||
638 | |||
639 | <glossentry id='var-bb-BB_PRESERVE_ENV'><glossterm>BB_PRESERVE_ENV</glossterm> | ||
640 | <glossdef> | ||
641 | <para> | ||
642 | Disables whitelisting and instead allows all variables | ||
643 | through from the external environment into BitBake's | ||
644 | datastore. | ||
645 | <note> | ||
646 | You must set this variable in the external | ||
647 | environment in order for it to work. | ||
648 | </note> | ||
649 | </para> | ||
650 | </glossdef> | ||
651 | </glossentry> | ||
652 | |||
653 | <glossentry id='var-bb-BB_RUNFMT'><glossterm>BB_RUNFMT</glossterm> | ||
654 | <glossdef> | ||
655 | <para> | ||
656 | Specifies the name of the executable script files | ||
657 | (i.e. run files) saved into | ||
658 | <filename>${</filename><link linkend='var-bb-T'><filename>T</filename></link><filename>}</filename>. | ||
659 | By default, the <filename>BB_RUNFMT</filename> variable | ||
660 | is undefined and the run file names get created using the | ||
661 | following form: | ||
662 | <literallayout class='monospaced'> | ||
663 | run.{task}.{pid} | ||
664 | </literallayout> | ||
665 | If you want to force run files to take a specific name, | ||
666 | you can set this variable in a configuration file. | ||
667 | </para> | ||
668 | </glossdef> | ||
669 | </glossentry> | ||
670 | |||
671 | <glossentry id='var-bb-BB_RUNTASK'><glossterm>BB_RUNTASK</glossterm> | ||
672 | <glossdef> | ||
673 | <para> | ||
674 | Contains the name of the currently executing task. | ||
675 | The value includes the "do_" prefix. | ||
676 | For example, if the currently executing task is | ||
677 | <filename>do_config</filename>, the value is | ||
678 | "do_config". | ||
679 | </para> | ||
680 | </glossdef> | ||
681 | </glossentry> | ||
682 | |||
683 | <glossentry id='var-bb-BB_SCHEDULER'><glossterm>BB_SCHEDULER</glossterm> | ||
684 | <glossdef> | ||
685 | <para> | ||
686 | Selects the name of the scheduler to use for the | ||
687 | scheduling of BitBake tasks. | ||
688 | Three options exist: | ||
689 | <itemizedlist> | ||
690 | <listitem><para><emphasis>basic</emphasis> - | ||
691 | The basic framework from which everything derives. | ||
692 | Using this option causes tasks to be ordered | ||
693 | numerically as they are parsed. | ||
694 | </para></listitem> | ||
695 | <listitem><para><emphasis>speed</emphasis> - | ||
696 | Executes tasks first that have more tasks | ||
697 | depending on them. | ||
698 | The "speed" option is the default. | ||
699 | </para></listitem> | ||
700 | <listitem><para><emphasis>completion</emphasis> - | ||
701 | Causes the scheduler to try to complete a given | ||
702 | recipe once its build has started. | ||
703 | </para></listitem> | ||
704 | </itemizedlist> | ||
705 | </para> | ||
706 | </glossdef> | ||
707 | </glossentry> | ||
708 | |||
709 | <glossentry id='var-bb-BB_SCHEDULERS'><glossterm>BB_SCHEDULERS</glossterm> | ||
710 | <glossdef> | ||
711 | <para> | ||
712 | Defines custom schedulers to import. | ||
713 | Custom schedulers need to be derived from the | ||
714 | <filename>RunQueueScheduler</filename> class. | ||
715 | </para> | ||
716 | |||
717 | <para> | ||
718 | For information how to select a scheduler, see the | ||
719 | <link linkend='var-bb-BB_SCHEDULER'><filename>BB_SCHEDULER</filename></link> | ||
720 | variable. | ||
721 | </para> | ||
722 | </glossdef> | ||
723 | </glossentry> | ||
724 | |||
725 | <glossentry id='var-bb-BB_SETSCENE_DEPVALID'><glossterm>BB_SETSCENE_DEPVALID</glossterm> | ||
726 | <glossdef> | ||
727 | <para> | ||
728 | Specifies a function BitBake calls that determines | ||
729 | whether BitBake requires a setscene dependency to be met. | ||
730 | </para> | ||
731 | |||
732 | <para> | ||
733 | When running a setscene task, BitBake needs to | ||
734 | know which dependencies of that setscene task also need | ||
735 | to be run. | ||
736 | Whether dependencies also need to be run is highly | ||
737 | dependent on the metadata. | ||
738 | The function specified by this variable returns a | ||
739 | "True" or "False" depending on whether the dependency needs | ||
740 | to be met. | ||
741 | </para> | ||
742 | </glossdef> | ||
743 | </glossentry> | ||
744 | |||
745 | <glossentry id='var-bb-BB_SETSCENE_VERIFY_FUNCTION2'><glossterm>BB_SETSCENE_VERIFY_FUNCTION2</glossterm> | ||
746 | <glossdef> | ||
747 | <para> | ||
748 | Specifies a function to call that verifies the list of | ||
749 | planned task execution before the main task execution | ||
750 | happens. | ||
751 | The function is called once BitBake has a list of setscene | ||
752 | tasks that have run and either succeeded or failed. | ||
753 | </para> | ||
754 | |||
755 | <para> | ||
756 | The function allows for a task list check to see if they | ||
757 | make sense. | ||
758 | Even if BitBake was planning to skip a task, the | ||
759 | returned value of the function can force BitBake to run | ||
760 | the task, which is necessary under certain metadata | ||
761 | defined circumstances. | ||
762 | </para> | ||
763 | </glossdef> | ||
764 | </glossentry> | ||
765 | |||
766 | <glossentry id='var-bb-BB_SIGNATURE_EXCLUDE_FLAGS'><glossterm>BB_SIGNATURE_EXCLUDE_FLAGS</glossterm> | ||
767 | <glossdef> | ||
768 | <para> | ||
769 | Lists variable flags (varflags) | ||
770 | that can be safely excluded from checksum | ||
771 | and dependency data for keys in the datastore. | ||
772 | When generating checksum or dependency data for keys in the | ||
773 | datastore, the flags set against that key are normally | ||
774 | included in the checksum. | ||
775 | </para> | ||
776 | |||
777 | <para> | ||
778 | For more information on varflags, see the | ||
779 | "<link linkend='variable-flags'>Variable Flags</link>" | ||
780 | section. | ||
781 | </para> | ||
782 | </glossdef> | ||
783 | </glossentry> | ||
784 | |||
785 | <glossentry id='var-bb-BB_SIGNATURE_HANDLER'><glossterm>BB_SIGNATURE_HANDLER</glossterm> | ||
786 | <glossdef> | ||
787 | <para> | ||
788 | Defines the name of the signature handler BitBake uses. | ||
789 | The signature handler defines the way stamp files are | ||
790 | created and handled, if and how the signature is | ||
791 | incorporated into the stamps, and how the signature | ||
792 | itself is generated. | ||
793 | </para> | ||
794 | |||
795 | <para> | ||
796 | A new signature handler can be added by injecting a class | ||
797 | derived from the | ||
798 | <filename>SignatureGenerator</filename> class into the | ||
799 | global namespace. | ||
800 | </para> | ||
801 | </glossdef> | ||
802 | </glossentry> | ||
803 | |||
804 | <glossentry id='var-bb-BB_SRCREV_POLICY'><glossterm>BB_SRCREV_POLICY</glossterm> | ||
805 | <glossdef> | ||
806 | <para> | ||
807 | Defines the behavior of the fetcher when it interacts with | ||
808 | source control systems and dynamic source revisions. | ||
809 | The <filename>BB_SRCREV_POLICY</filename> variable is | ||
810 | useful when working without a network. | ||
811 | </para> | ||
812 | |||
813 | <para> | ||
814 | The variable can be set using one of two policies: | ||
815 | <itemizedlist> | ||
816 | <listitem><para><emphasis>cache</emphasis> - | ||
817 | Retains the value the system obtained previously | ||
818 | rather than querying the source control system | ||
819 | each time. | ||
820 | </para></listitem> | ||
821 | <listitem><para><emphasis>clear</emphasis> - | ||
822 | Queries the source controls system every time. | ||
823 | With this policy, there is no cache. | ||
824 | The "clear" policy is the default. | ||
825 | </para></listitem> | ||
826 | </itemizedlist> | ||
827 | </para> | ||
828 | </glossdef> | ||
829 | </glossentry> | ||
830 | |||
831 | <glossentry id='var-bb-BB_STAMP_POLICY'><glossterm>BB_STAMP_POLICY</glossterm> | ||
832 | <glossdef> | ||
833 | <para> | ||
834 | Defines the mode used for how timestamps of stamp files | ||
835 | are compared. | ||
836 | You can set the variable to one of the following modes: | ||
837 | <itemizedlist> | ||
838 | <listitem><para><emphasis>perfile</emphasis> - | ||
839 | Timestamp comparisons are only made | ||
840 | between timestamps of a specific recipe. | ||
841 | This is the default mode. | ||
842 | </para></listitem> | ||
843 | <listitem><para><emphasis>full</emphasis> - | ||
844 | Timestamp comparisons are made for all | ||
845 | dependencies. | ||
846 | </para></listitem> | ||
847 | <listitem><para><emphasis>whitelist</emphasis> - | ||
848 | Identical to "full" mode except timestamp | ||
849 | comparisons are made for recipes listed in the | ||
850 | <link linkend='var-bb-BB_STAMP_WHITELIST'><filename>BB_STAMP_WHITELIST</filename></link> | ||
851 | variable. | ||
852 | </para></listitem> | ||
853 | </itemizedlist> | ||
854 | <note> | ||
855 | Stamp policies are largely obsolete with the | ||
856 | introduction of setscene tasks. | ||
857 | </note> | ||
858 | </para> | ||
859 | </glossdef> | ||
860 | </glossentry> | ||
861 | |||
862 | <glossentry id='var-bb-BB_STAMP_WHITELIST'><glossterm>BB_STAMP_WHITELIST</glossterm> | ||
863 | <glossdef> | ||
864 | <para> | ||
865 | Lists files whose stamp file timestamps are compared when | ||
866 | the stamp policy mode is set to "whitelist". | ||
867 | For information on stamp policies, see the | ||
868 | <link linkend='var-bb-BB_STAMP_POLICY'><filename>BB_STAMP_POLICY</filename></link> | ||
869 | variable. | ||
870 | </para> | ||
871 | </glossdef> | ||
872 | </glossentry> | ||
873 | |||
874 | <glossentry id='var-bb-BB_STRICT_CHECKSUM'><glossterm>BB_STRICT_CHECKSUM</glossterm> | ||
875 | <glossdef> | ||
876 | <para> | ||
877 | Sets a more strict checksum mechanism for non-local URLs. | ||
878 | Setting this variable to a value causes BitBake | ||
879 | to report an error if it encounters a non-local URL | ||
880 | that does not have at least one checksum specified. | ||
881 | </para> | ||
882 | </glossdef> | ||
883 | </glossentry> | ||
884 | |||
885 | <glossentry id='var-bb-BB_TASK_IONICE_LEVEL'><glossterm>BB_TASK_IONICE_LEVEL</glossterm> | ||
886 | <glossdef> | ||
887 | <para> | ||
888 | Allows adjustment of a task's Input/Output priority. | ||
889 | During Autobuilder testing, random failures can occur | ||
890 | for tasks due to I/O starvation. | ||
891 | These failures occur during various QEMU runtime timeouts. | ||
892 | You can use the <filename>BB_TASK_IONICE_LEVEL</filename> | ||
893 | variable to adjust the I/O priority of these tasks. | ||
894 | <note> | ||
895 | This variable works similarly to the | ||
896 | <link linkend='var-bb-BB_TASK_NICE_LEVEL'><filename>BB_TASK_NICE_LEVEL</filename></link> | ||
897 | variable except with a task's I/O priorities. | ||
898 | </note> | ||
899 | </para> | ||
900 | |||
901 | <para> | ||
902 | Set the variable as follows: | ||
903 | <literallayout class='monospaced'> | ||
904 | BB_TASK_IONICE_LEVEL = "<replaceable>class</replaceable>.<replaceable>prio</replaceable>" | ||
905 | </literallayout> | ||
906 | For <replaceable>class</replaceable>, the default value is | ||
907 | "2", which is a best effort. | ||
908 | You can use "1" for realtime and "3" for idle. | ||
909 | If you want to use realtime, you must have superuser | ||
910 | privileges. | ||
911 | </para> | ||
912 | |||
913 | <para> | ||
914 | For <replaceable>prio</replaceable>, you can use any | ||
915 | value from "0", which is the highest priority, to "7", | ||
916 | which is the lowest. | ||
917 | The default value is "4". | ||
918 | You do not need any special privileges to use this range | ||
919 | of priority values. | ||
920 | <note> | ||
921 | In order for your I/O priority settings to take effect, | ||
922 | you need the Completely Fair Queuing (CFQ) Scheduler | ||
923 | selected for the backing block device. | ||
924 | To select the scheduler, use the following command form | ||
925 | where <replaceable>device</replaceable> is the device | ||
926 | (e.g. sda, sdb, and so forth): | ||
927 | <literallayout class='monospaced'> | ||
928 | $ sudo sh -c “echo cfq > /sys/block/<replaceable>device</replaceable>/queu/scheduler | ||
929 | </literallayout> | ||
930 | </note> | ||
931 | </para> | ||
932 | </glossdef> | ||
933 | </glossentry> | ||
934 | |||
935 | <glossentry id='var-bb-BB_TASK_NICE_LEVEL'><glossterm>BB_TASK_NICE_LEVEL</glossterm> | ||
936 | <glossdef> | ||
937 | <para> | ||
938 | Allows specific tasks to change their priority | ||
939 | (i.e. nice level). | ||
940 | </para> | ||
941 | |||
942 | <para> | ||
943 | You can use this variable in combination with task | ||
944 | overrides to raise or lower priorities of specific tasks. | ||
945 | For example, on the | ||
946 | <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> | ||
947 | autobuilder, QEMU emulation in images is given a higher | ||
948 | priority as compared to build tasks to ensure that images | ||
949 | do not suffer timeouts on loaded systems. | ||
950 | </para> | ||
951 | </glossdef> | ||
952 | </glossentry> | ||
953 | |||
954 | <glossentry id='var-bb-BB_TASKHASH'><glossterm>BB_TASKHASH</glossterm> | ||
955 | <glossdef> | ||
956 | <para> | ||
957 | Within an executing task, this variable holds the hash | ||
958 | of the task as returned by the currently enabled | ||
959 | signature generator. | ||
960 | </para> | ||
961 | </glossdef> | ||
962 | </glossentry> | ||
963 | |||
964 | <glossentry id='var-bb-BB_VERBOSE_LOGS'><glossterm>BB_VERBOSE_LOGS</glossterm> | ||
965 | <glossdef> | ||
966 | <para> | ||
967 | Controls how verbose BitBake is during builds. | ||
968 | If set, shell scripts echo commands and shell script output | ||
969 | appears on standard out (stdout). | ||
970 | </para> | ||
971 | </glossdef> | ||
972 | </glossentry> | ||
973 | |||
974 | <glossentry id='var-bb-BB_WORKERCONTEXT'><glossterm>BB_WORKERCONTEXT</glossterm> | ||
975 | <glossdef> | ||
976 | <para> | ||
977 | Specifies if the current context is executing a task. | ||
978 | BitBake sets this variable to "1" when a task is | ||
979 | being executed. | ||
980 | The value is not set when the task is in server context | ||
981 | during parsing or event handling. | ||
982 | </para> | ||
983 | </glossdef> | ||
984 | </glossentry> | ||
985 | |||
986 | |||
987 | <glossentry id='var-bb-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm> | ||
988 | <glossdef> | ||
989 | <para> | ||
990 | Allows you to extend a recipe so that it builds variants | ||
991 | of the software. | ||
992 | Some examples of these variants for recipes from the | ||
993 | OpenEmbedded-Core metadata are "natives" such as | ||
994 | <filename>quilt-native</filename>, which is a copy of | ||
995 | Quilt built to run on the build system; "crosses" such | ||
996 | as <filename>gcc-cross</filename>, which is a compiler | ||
997 | built to run on the build machine but produces binaries | ||
998 | that run on the target <filename>MACHINE</filename>; | ||
999 | "nativesdk", which targets the SDK machine instead of | ||
1000 | <filename>MACHINE</filename>; and "mulitlibs" in the form | ||
1001 | "<filename>multilib:</filename><replaceable>multilib_name</replaceable>". | ||
1002 | </para> | ||
1003 | |||
1004 | <para> | ||
1005 | To build a different variant of the recipe with a minimal | ||
1006 | amount of code, it usually is as simple as adding the | ||
1007 | variable to your recipe. | ||
1008 | Here are two examples. | ||
1009 | The "native" variants are from the OpenEmbedded-Core | ||
1010 | metadata: | ||
1011 | <literallayout class='monospaced'> | ||
1012 | BBCLASSEXTEND =+ "native nativesdk" | ||
1013 | BBCLASSEXTEND =+ "multilib:<replaceable>multilib_name</replaceable>" | ||
1014 | </literallayout> | ||
1015 | <note> | ||
1016 | <para> | ||
1017 | Internally, the <filename>BBCLASSEXTEND</filename> | ||
1018 | mechanism generates recipe variants by rewriting | ||
1019 | variable values and applying overrides such as | ||
1020 | <filename>_class-native</filename>. | ||
1021 | For example, to generate a native version of a recipe, | ||
1022 | a | ||
1023 | <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> | ||
1024 | on "foo" is rewritten to a <filename>DEPENDS</filename> | ||
1025 | on "foo-native". | ||
1026 | </para> | ||
1027 | |||
1028 | <para> | ||
1029 | Even when using <filename>BBCLASSEXTEND</filename>, the | ||
1030 | recipe is only parsed once. | ||
1031 | Parsing once adds some limitations. | ||
1032 | For example, it is not possible to | ||
1033 | include a different file depending on the variant, | ||
1034 | since <filename>include</filename> statements are | ||
1035 | processed when the recipe is parsed. | ||
1036 | </para> | ||
1037 | </note> | ||
1038 | </para> | ||
1039 | </glossdef> | ||
1040 | </glossentry> | ||
1041 | |||
1042 | <glossentry id='var-bb-BBDEBUG'><glossterm>BBDEBUG</glossterm> | ||
1043 | <glossdef> | ||
1044 | <para> | ||
1045 | Sets the BitBake debug output level to a specific value | ||
1046 | as incremented by the <filename>-D</filename> command line | ||
1047 | option. | ||
1048 | <note> | ||
1049 | You must set this variable in the external environment | ||
1050 | in order for it to work. | ||
1051 | </note> | ||
1052 | </para> | ||
1053 | </glossdef> | ||
1054 | </glossentry> | ||
1055 | |||
1056 | <glossentry id='var-bb-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm> | ||
1057 | <glossdef> | ||
1058 | <para>Lists the names of configured layers. | ||
1059 | These names are used to find the other <filename>BBFILE_*</filename> | ||
1060 | variables. | ||
1061 | Typically, each layer appends its name to this variable in its | ||
1062 | <filename>conf/layer.conf</filename> file. | ||
1063 | </para> | ||
1064 | </glossdef> | ||
1065 | </glossentry> | ||
1066 | |||
1067 | <glossentry id='var-bb-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm> | ||
1068 | <glossdef> | ||
1069 | <para>Variable that expands to match files from | ||
1070 | <link linkend='var-bb-BBFILES'><filename>BBFILES</filename></link> | ||
1071 | in a particular layer. | ||
1072 | This variable is used in the <filename>conf/layer.conf</filename> file and must | ||
1073 | be suffixed with the name of the specific layer (e.g. | ||
1074 | <filename>BBFILE_PATTERN_emenlow</filename>).</para> | ||
1075 | </glossdef> | ||
1076 | </glossentry> | ||
1077 | |||
1078 | <glossentry id='var-bb-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm> | ||
1079 | <glossdef> | ||
1080 | <para>Assigns the priority for recipe files in each layer.</para> | ||
1081 | <para>This variable is useful in situations where the same recipe appears in | ||
1082 | more than one layer. | ||
1083 | Setting this variable allows you to prioritize a | ||
1084 | layer against other layers that contain the same recipe - effectively | ||
1085 | letting you control the precedence for the multiple layers. | ||
1086 | The precedence established through this variable stands regardless of a | ||
1087 | recipe's version | ||
1088 | (<link linkend='var-bb-PV'><filename>PV</filename></link> variable). | ||
1089 | For example, a layer that has a recipe with a higher <filename>PV</filename> value but for | ||
1090 | which the <filename>BBFILE_PRIORITY</filename> is set to have a lower precedence still has a | ||
1091 | lower precedence.</para> | ||
1092 | <para>A larger value for the <filename>BBFILE_PRIORITY</filename> variable results in a higher | ||
1093 | precedence. | ||
1094 | For example, the value 6 has a higher precedence than the value 5. | ||
1095 | If not specified, the <filename>BBFILE_PRIORITY</filename> variable is set based on layer | ||
1096 | dependencies (see the | ||
1097 | <filename><link linkend='var-bb-LAYERDEPENDS'>LAYERDEPENDS</link></filename> variable for | ||
1098 | more information. | ||
1099 | The default priority, if unspecified | ||
1100 | for a layer with no dependencies, is the lowest defined priority + 1 | ||
1101 | (or 1 if no priorities are defined).</para> | ||
1102 | <tip> | ||
1103 | You can use the command <filename>bitbake-layers show-layers</filename> to list | ||
1104 | all configured layers along with their priorities. | ||
1105 | </tip> | ||
1106 | </glossdef> | ||
1107 | </glossentry> | ||
1108 | |||
1109 | <glossentry id='var-bb-BBFILES'><glossterm>BBFILES</glossterm> | ||
1110 | <glossdef> | ||
1111 | <para> | ||
1112 | A space-separated list of recipe files BitBake uses to | ||
1113 | build software. | ||
1114 | </para> | ||
1115 | |||
1116 | <para> | ||
1117 | When specifying recipe files, you can pattern match using | ||
1118 | Python's | ||
1119 | <ulink url='https://docs.python.org/3/library/glob.html'><filename>glob</filename></ulink> | ||
1120 | syntax. | ||
1121 | For details on the syntax, see the documentation by | ||
1122 | following the previous link. | ||
1123 | </para> | ||
1124 | </glossdef> | ||
1125 | </glossentry> | ||
1126 | |||
1127 | <glossentry id='var-BBFILES_DYNAMIC'><glossterm>BBFILES_DYNAMIC</glossterm> | ||
1128 | <info> | ||
1129 | BBFILES_DYNAMIC[doc] = "Activates content depending on presence of identified layers." | ||
1130 | </info> | ||
1131 | <glossdef> | ||
1132 | <para role="glossdeffirst"> | ||
1133 | Activates content depending on presence of identified layers. | ||
1134 | You identify the layers by the collections that the layers | ||
1135 | define. | ||
1136 | </para> | ||
1137 | |||
1138 | <para> | ||
1139 | Use the <filename>BBFILES_DYNAMIC</filename> variable to | ||
1140 | avoid <filename>.bbappend</filename> files whose | ||
1141 | corresponding <filename>.bb</filename> file is in a layer | ||
1142 | that attempts to modify other layers through | ||
1143 | <filename>.bbappend</filename> but does not want to | ||
1144 | introduce a hard dependency on those other layers. | ||
1145 | </para> | ||
1146 | |||
1147 | <para> | ||
1148 | Additionally you can prefix the rule with "!" to add | ||
1149 | <filename>.bbappend</filename> and <filename>.bb</filename> files | ||
1150 | in case a layer is not present. | ||
1151 | Use this avoid hard dependency on those other layers. | ||
1152 | </para> | ||
1153 | |||
1154 | <para> | ||
1155 | Use the following form for | ||
1156 | <filename>BBFILES_DYNAMIC</filename>: | ||
1157 | <literallayout class='monospaced'> | ||
1158 | <replaceable>collection_name</replaceable>:<replaceable>filename_pattern</replaceable> | ||
1159 | </literallayout> | ||
1160 | The following example identifies two collection names and | ||
1161 | two filename patterns: | ||
1162 | <literallayout class='monospaced'> | ||
1163 | BBFILES_DYNAMIC += "\ | ||
1164 | clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \ | ||
1165 | core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \ | ||
1166 | " | ||
1167 | </literallayout> | ||
1168 | When the collection name is prefixed with "!" it will add the file pattern in case | ||
1169 | the layer is absent: | ||
1170 | <literallayout class='monospaced'> | ||
1171 | BBFILES_DYNAMIC += "\ | ||
1172 | !clang-layer:${LAYERDIR}/backfill/meta-clang/*/*/*.bb \ | ||
1173 | " | ||
1174 | </literallayout> | ||
1175 | |||
1176 | This next example shows an error message that occurs | ||
1177 | because invalid entries are found, which cause parsing to | ||
1178 | abort: | ||
1179 | <literallayout class='monospaced'> | ||
1180 | ERROR: BBFILES_DYNAMIC entries must be of the form {!}<collection name>:<filename pattern>, not: | ||
1181 | /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend | ||
1182 | /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend | ||
1183 | </literallayout> | ||
1184 | </para> | ||
1185 | </glossdef> | ||
1186 | </glossentry> | ||
1187 | |||
1188 | <glossentry id='var-bb-BBINCLUDED'><glossterm>BBINCLUDED</glossterm> | ||
1189 | <glossdef> | ||
1190 | <para> | ||
1191 | Contains a space-separated list of all of all files that | ||
1192 | BitBake's parser included during parsing of the current | ||
1193 | file. | ||
1194 | </para> | ||
1195 | </glossdef> | ||
1196 | </glossentry> | ||
1197 | |||
1198 | <glossentry id='var-bb-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm> | ||
1199 | <glossdef> | ||
1200 | <para> | ||
1201 | If set to a value, enables printing the task log when | ||
1202 | reporting a failed task. | ||
1203 | </para> | ||
1204 | </glossdef> | ||
1205 | </glossentry> | ||
1206 | |||
1207 | <glossentry id='var-bb-BBINCLUDELOGS_LINES'><glossterm>BBINCLUDELOGS_LINES</glossterm> | ||
1208 | <glossdef> | ||
1209 | <para> | ||
1210 | If | ||
1211 | <link linkend='var-bb-BBINCLUDELOGS'><filename>BBINCLUDELOGS</filename></link> | ||
1212 | is set, specifies the maximum number of lines from the | ||
1213 | task log file to print when reporting a failed task. | ||
1214 | If you do not set <filename>BBINCLUDELOGS_LINES</filename>, | ||
1215 | the entire log is printed. | ||
1216 | </para> | ||
1217 | </glossdef> | ||
1218 | </glossentry> | ||
1219 | |||
1220 | <glossentry id='var-bb-BBLAYERS'><glossterm>BBLAYERS</glossterm> | ||
1221 | <glossdef> | ||
1222 | <para>Lists the layers to enable during the build. | ||
1223 | This variable is defined in the <filename>bblayers.conf</filename> configuration | ||
1224 | file in the build directory. | ||
1225 | Here is an example: | ||
1226 | <literallayout class='monospaced'> | ||
1227 | BBLAYERS = " \ | ||
1228 | /home/scottrif/poky/meta \ | ||
1229 | /home/scottrif/poky/meta-yocto \ | ||
1230 | /home/scottrif/poky/meta-yocto-bsp \ | ||
1231 | /home/scottrif/poky/meta-mykernel \ | ||
1232 | " | ||
1233 | |||
1234 | </literallayout> | ||
1235 | This example enables four layers, one of which is a custom, user-defined layer | ||
1236 | named <filename>meta-mykernel</filename>. | ||
1237 | </para> | ||
1238 | </glossdef> | ||
1239 | </glossentry> | ||
1240 | |||
1241 | <glossentry id='var-bb-BBLAYERS_FETCH_DIR'><glossterm>BBLAYERS_FETCH_DIR</glossterm> | ||
1242 | <glossdef> | ||
1243 | <para> | ||
1244 | Sets the base location where layers are stored. | ||
1245 | This setting is used in conjunction with | ||
1246 | <filename>bitbake-layers layerindex-fetch</filename> and | ||
1247 | tells <filename>bitbake-layers</filename> where to place | ||
1248 | the fetched layers. | ||
1249 | </para> | ||
1250 | </glossdef> | ||
1251 | </glossentry> | ||
1252 | |||
1253 | <glossentry id='var-bb-BBMASK'><glossterm>BBMASK</glossterm> | ||
1254 | <glossdef> | ||
1255 | <para> | ||
1256 | Prevents BitBake from processing recipes and recipe | ||
1257 | append files. | ||
1258 | </para> | ||
1259 | |||
1260 | <para> | ||
1261 | You can use the <filename>BBMASK</filename> variable | ||
1262 | to "hide" these <filename>.bb</filename> and | ||
1263 | <filename>.bbappend</filename> files. | ||
1264 | BitBake ignores any recipe or recipe append files that | ||
1265 | match any of the expressions. | ||
1266 | It is as if BitBake does not see them at all. | ||
1267 | Consequently, matching files are not parsed or otherwise | ||
1268 | used by BitBake. | ||
1269 | </para> | ||
1270 | |||
1271 | <para> | ||
1272 | The values you provide are passed to Python's regular | ||
1273 | expression compiler. | ||
1274 | Consequently, the syntax follows Python's Regular | ||
1275 | Expression (re) syntax. | ||
1276 | The expressions are compared against the full paths to | ||
1277 | the files. | ||
1278 | For complete syntax information, see Python's | ||
1279 | documentation at | ||
1280 | <ulink url='http://docs.python.org/3/library/re.html#re'></ulink>. | ||
1281 | </para> | ||
1282 | |||
1283 | <para> | ||
1284 | The following example uses a complete regular expression | ||
1285 | to tell BitBake to ignore all recipe and recipe append | ||
1286 | files in the <filename>meta-ti/recipes-misc/</filename> | ||
1287 | directory: | ||
1288 | <literallayout class='monospaced'> | ||
1289 | BBMASK = "meta-ti/recipes-misc/" | ||
1290 | </literallayout> | ||
1291 | If you want to mask out multiple directories or recipes, | ||
1292 | you can specify multiple regular expression fragments. | ||
1293 | This next example masks out multiple directories and | ||
1294 | individual recipes: | ||
1295 | <literallayout class='monospaced'> | ||
1296 | BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/" | ||
1297 | BBMASK += "/meta-oe/recipes-support/" | ||
1298 | BBMASK += "/meta-foo/.*/openldap" | ||
1299 | BBMASK += "opencv.*\.bbappend" | ||
1300 | BBMASK += "lzma" | ||
1301 | </literallayout> | ||
1302 | <note> | ||
1303 | When specifying a directory name, use the trailing | ||
1304 | slash character to ensure you match just that directory | ||
1305 | name. | ||
1306 | </note> | ||
1307 | </para> | ||
1308 | </glossdef> | ||
1309 | </glossentry> | ||
1310 | |||
1311 | <glossentry id='var-bb-BBMULTICONFIG'><glossterm>BBMULTICONFIG</glossterm> | ||
1312 | <info> | ||
1313 | BBMULTICONFIG[doc] = "Enables BitBake to perform multiple configuration builds and lists each separate configuration (multiconfig)." | ||
1314 | </info> | ||
1315 | <glossdef> | ||
1316 | <para role="glossdeffirst"> | ||
1317 | <!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> --> | ||
1318 | Enables BitBake to perform multiple configuration builds | ||
1319 | and lists each separate configuration (multiconfig). | ||
1320 | You can use this variable to cause BitBake to build | ||
1321 | multiple targets where each target has a separate | ||
1322 | configuration. | ||
1323 | Define <filename>BBMULTICONFIG</filename> in your | ||
1324 | <filename>conf/local.conf</filename> configuration file. | ||
1325 | </para> | ||
1326 | |||
1327 | <para> | ||
1328 | As an example, the following line specifies three | ||
1329 | multiconfigs, each having a separate configuration file: | ||
1330 | <literallayout class='monospaced'> | ||
1331 | BBMULTIFONFIG = "configA configB configC" | ||
1332 | </literallayout> | ||
1333 | Each configuration file you use must reside in the | ||
1334 | build directory within a directory named | ||
1335 | <filename>conf/multiconfig</filename> (e.g. | ||
1336 | <replaceable>build_directory</replaceable><filename>/conf/multiconfig/configA.conf</filename>). | ||
1337 | </para> | ||
1338 | |||
1339 | <para> | ||
1340 | For information on how to use | ||
1341 | <filename>BBMULTICONFIG</filename> in an environment that | ||
1342 | supports building targets with multiple configurations, | ||
1343 | see the | ||
1344 | "<link linkend='executing-a-multiple-configuration-build'>Executing a Multiple Configuration Build</link>" | ||
1345 | section. | ||
1346 | </para> | ||
1347 | </glossdef> | ||
1348 | </glossentry> | ||
1349 | |||
1350 | <glossentry id='var-bb-BBPATH'><glossterm>BBPATH</glossterm> | ||
1351 | <glossdef> | ||
1352 | <para> | ||
1353 | Used by BitBake to locate class | ||
1354 | (<filename>.bbclass</filename>) and configuration | ||
1355 | (<filename>.conf</filename>) files. | ||
1356 | This variable is analogous to the | ||
1357 | <filename>PATH</filename> variable. | ||
1358 | </para> | ||
1359 | |||
1360 | <para> | ||
1361 | If you run BitBake from a directory outside of the | ||
1362 | build directory, | ||
1363 | you must be sure to set | ||
1364 | <filename>BBPATH</filename> to point to the | ||
1365 | build directory. | ||
1366 | Set the variable as you would any environment variable | ||
1367 | and then run BitBake: | ||
1368 | <literallayout class='monospaced'> | ||
1369 | $ BBPATH="<replaceable>build_directory</replaceable>" | ||
1370 | $ export BBPATH | ||
1371 | $ bitbake <replaceable>target</replaceable> | ||
1372 | </literallayout> | ||
1373 | </para> | ||
1374 | </glossdef> | ||
1375 | </glossentry> | ||
1376 | |||
1377 | <glossentry id='var-bb-BBSERVER'><glossterm>BBSERVER</glossterm> | ||
1378 | <glossdef> | ||
1379 | <para> | ||
1380 | Points to the server that runs memory-resident BitBake. | ||
1381 | The variable is only used when you employ memory-resident | ||
1382 | BitBake. | ||
1383 | </para> | ||
1384 | </glossdef> | ||
1385 | </glossentry> | ||
1386 | |||
1387 | <glossentry id='var-bb-BBTARGETS'><glossterm>BBTARGETS</glossterm> | ||
1388 | <glossdef> | ||
1389 | <para> | ||
1390 | Allows you to use a configuration file to add to the list | ||
1391 | of command-line target recipes you want to build. | ||
1392 | </para> | ||
1393 | </glossdef> | ||
1394 | </glossentry> | ||
1395 | |||
1396 | <glossentry id='var-bb-BBVERSIONS'><glossterm>BBVERSIONS</glossterm> | ||
1397 | <glossdef> | ||
1398 | <para> | ||
1399 | Allows a single recipe to build multiple versions of a | ||
1400 | project from a single recipe file. | ||
1401 | You also able to specify conditional metadata | ||
1402 | using the | ||
1403 | <link linkend='var-bb-OVERRIDES'><filename>OVERRIDES</filename></link> | ||
1404 | mechanism for a single version or for an optionally named | ||
1405 | range of versions. | ||
1406 | </para> | ||
1407 | |||
1408 | <para> | ||
1409 | For more information on <filename>BBVERSIONS</filename>, | ||
1410 | see the | ||
1411 | "<link linkend='variants-class-extension-mechanism'>Variants - Class Extension Mechanism</link>" | ||
1412 | section. | ||
1413 | </para> | ||
1414 | </glossdef> | ||
1415 | </glossentry> | ||
1416 | |||
1417 | <glossentry id='var-bb-BITBAKE_UI'><glossterm>BITBAKE_UI</glossterm> | ||
1418 | <glossdef> | ||
1419 | <para> | ||
1420 | Used to specify the UI module to use when running BitBake. | ||
1421 | Using this variable is equivalent to using the | ||
1422 | <filename>-u</filename> command-line option. | ||
1423 | <note> | ||
1424 | You must set this variable in the external environment | ||
1425 | in order for it to work. | ||
1426 | </note> | ||
1427 | </para> | ||
1428 | </glossdef> | ||
1429 | </glossentry> | ||
1430 | |||
1431 | <glossentry id='var-bb-BUILDNAME'><glossterm>BUILDNAME</glossterm> | ||
1432 | <glossdef> | ||
1433 | <para> | ||
1434 | A name assigned to the build. | ||
1435 | The name defaults to a datetime stamp of when the build was | ||
1436 | started but can be defined by the metadata. | ||
1437 | </para> | ||
1438 | </glossdef> | ||
1439 | </glossentry> | ||
1440 | |||
1441 | <glossentry id='var-bb-BZRDIR'><glossterm>BZRDIR</glossterm> | ||
1442 | <glossdef> | ||
1443 | <para> | ||
1444 | The directory in which files checked out of a Bazaar | ||
1445 | system are stored. | ||
1446 | </para> | ||
1447 | </glossdef> | ||
1448 | </glossentry> | ||
1449 | |||
1450 | </glossdiv> | ||
1451 | |||
1452 | <glossdiv id='var-bb-glossary-c'><title>C</title> | ||
1453 | |||
1454 | <glossentry id='var-bb-CACHE'><glossterm>CACHE</glossterm> | ||
1455 | <glossdef> | ||
1456 | <para> | ||
1457 | Specifies the directory BitBake uses to store a cache | ||
1458 | of the metadata so it does not need to be parsed every | ||
1459 | time BitBake is started. | ||
1460 | </para> | ||
1461 | </glossdef> | ||
1462 | </glossentry> | ||
1463 | |||
1464 | <glossentry id='var-bb-CVSDIR'><glossterm>CVSDIR</glossterm> | ||
1465 | <glossdef> | ||
1466 | <para> | ||
1467 | The directory in which files checked out under the | ||
1468 | CVS system are stored. | ||
1469 | </para> | ||
1470 | </glossdef> | ||
1471 | </glossentry> | ||
1472 | |||
1473 | </glossdiv> | ||
1474 | |||
1475 | <glossdiv id='var-bb-glossary-d'><title>D</title> | ||
1476 | |||
1477 | <glossentry id='var-bb-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm> | ||
1478 | <glossdef> | ||
1479 | <para> | ||
1480 | Specifies a weak bias for recipe selection priority. | ||
1481 | </para> | ||
1482 | <para> | ||
1483 | The most common usage of this is variable is to set | ||
1484 | it to "-1" within a recipe for a development version of a | ||
1485 | piece of software. | ||
1486 | Using the variable in this way causes the stable version | ||
1487 | of the recipe to build by default in the absence of | ||
1488 | <filename><link linkend='var-bb-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename> | ||
1489 | being used to build the development version. | ||
1490 | </para> | ||
1491 | <note> | ||
1492 | The bias provided by <filename>DEFAULT_PREFERENCE</filename> | ||
1493 | is weak and is overridden by | ||
1494 | <filename><link linkend='var-bb-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename> | ||
1495 | if that variable is different between two layers | ||
1496 | that contain different versions of the same recipe. | ||
1497 | </note> | ||
1498 | </glossdef> | ||
1499 | </glossentry> | ||
1500 | |||
1501 | <glossentry id='var-bb-DEPENDS'><glossterm>DEPENDS</glossterm> | ||
1502 | <glossdef> | ||
1503 | <para> | ||
1504 | Lists a recipe's build-time dependencies | ||
1505 | (i.e. other recipe files). | ||
1506 | </para> | ||
1507 | |||
1508 | <para> | ||
1509 | Consider this simple example for two recipes named "a" and | ||
1510 | "b" that produce similarly named packages. | ||
1511 | In this example, the <filename>DEPENDS</filename> | ||
1512 | statement appears in the "a" recipe: | ||
1513 | <literallayout class='monospaced'> | ||
1514 | DEPENDS = "b" | ||
1515 | </literallayout> | ||
1516 | Here, the dependency is such that the | ||
1517 | <filename>do_configure</filename> task for recipe "a" | ||
1518 | depends on the <filename>do_populate_sysroot</filename> | ||
1519 | task of recipe "b". | ||
1520 | This means anything that recipe "b" puts into sysroot | ||
1521 | is available when recipe "a" is configuring itself. | ||
1522 | </para> | ||
1523 | |||
1524 | <para> | ||
1525 | For information on runtime dependencies, see the | ||
1526 | <link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link> | ||
1527 | variable. | ||
1528 | </para> | ||
1529 | </glossdef> | ||
1530 | </glossentry> | ||
1531 | |||
1532 | <glossentry id='var-bb-DESCRIPTION'><glossterm>DESCRIPTION</glossterm> | ||
1533 | <glossdef> | ||
1534 | <para> | ||
1535 | A long description for the recipe. | ||
1536 | </para> | ||
1537 | </glossdef> | ||
1538 | </glossentry> | ||
1539 | |||
1540 | <glossentry id='var-bb-DL_DIR'><glossterm>DL_DIR</glossterm> | ||
1541 | <glossdef> | ||
1542 | <para> | ||
1543 | The central download directory used by the build process to | ||
1544 | store downloads. | ||
1545 | By default, <filename>DL_DIR</filename> gets files | ||
1546 | suitable for mirroring for everything except Git | ||
1547 | repositories. | ||
1548 | If you want tarballs of Git repositories, use the | ||
1549 | <link linkend='var-bb-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link> | ||
1550 | variable. | ||
1551 | </para> | ||
1552 | </glossdef> | ||
1553 | |||
1554 | </glossentry> | ||
1555 | </glossdiv> | ||
1556 | |||
1557 | <glossdiv id='var-bb-glossary-e'><title>E</title> | ||
1558 | |||
1559 | <glossentry id='var-bb-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm> | ||
1560 | <glossdef> | ||
1561 | <para> | ||
1562 | Directs BitBake to exclude a recipe from world builds (i.e. | ||
1563 | <filename>bitbake world</filename>). | ||
1564 | During world builds, BitBake locates, parses and builds all | ||
1565 | recipes found in every layer exposed in the | ||
1566 | <filename>bblayers.conf</filename> configuration file. | ||
1567 | </para> | ||
1568 | |||
1569 | <para> | ||
1570 | To exclude a recipe from a world build using this variable, | ||
1571 | set the variable to "1" in the recipe. | ||
1572 | </para> | ||
1573 | |||
1574 | <note> | ||
1575 | Recipes added to <filename>EXCLUDE_FROM_WORLD</filename> | ||
1576 | may still be built during a world build in order to satisfy | ||
1577 | dependencies of other recipes. | ||
1578 | Adding a recipe to <filename>EXCLUDE_FROM_WORLD</filename> | ||
1579 | only ensures that the recipe is not explicitly added | ||
1580 | to the list of build targets in a world build. | ||
1581 | </note> | ||
1582 | </glossdef> | ||
1583 | </glossentry> | ||
1584 | |||
1585 | </glossdiv> | ||
1586 | |||
1587 | <glossdiv id='var-bb-glossary-f'><title>F</title> | ||
1588 | |||
1589 | <glossentry id='var-bb-FAKEROOT'><glossterm>FAKEROOT</glossterm> | ||
1590 | <glossdef> | ||
1591 | <para> | ||
1592 | Contains the command to use when running a shell script | ||
1593 | in a fakeroot environment. | ||
1594 | The <filename>FAKEROOT</filename> variable is obsolete | ||
1595 | and has been replaced by the other | ||
1596 | <filename>FAKEROOT*</filename> variables. | ||
1597 | See these entries in the glossary for more information. | ||
1598 | </para> | ||
1599 | </glossdef> | ||
1600 | </glossentry> | ||
1601 | |||
1602 | <glossentry id='var-bb-FAKEROOTBASEENV'><glossterm>FAKEROOTBASEENV</glossterm> | ||
1603 | <glossdef> | ||
1604 | <para> | ||
1605 | Lists environment variables to set when executing | ||
1606 | the command defined by | ||
1607 | <link linkend='var-bb-FAKEROOTCMD'><filename>FAKEROOTCMD</filename></link> | ||
1608 | that starts the bitbake-worker process | ||
1609 | in the fakeroot environment. | ||
1610 | </para> | ||
1611 | </glossdef> | ||
1612 | </glossentry> | ||
1613 | |||
1614 | <glossentry id='var-bb-FAKEROOTCMD'><glossterm>FAKEROOTCMD</glossterm> | ||
1615 | <glossdef> | ||
1616 | <para> | ||
1617 | Contains the command that starts the bitbake-worker | ||
1618 | process in the fakeroot environment. | ||
1619 | </para> | ||
1620 | </glossdef> | ||
1621 | </glossentry> | ||
1622 | |||
1623 | <glossentry id='var-bb-FAKEROOTDIRS'><glossterm>FAKEROOTDIRS</glossterm> | ||
1624 | <glossdef> | ||
1625 | <para> | ||
1626 | Lists directories to create before running a task in | ||
1627 | the fakeroot environment. | ||
1628 | </para> | ||
1629 | </glossdef> | ||
1630 | </glossentry> | ||
1631 | |||
1632 | <glossentry id='var-bb-FAKEROOTENV'><glossterm>FAKEROOTENV</glossterm> | ||
1633 | <glossdef> | ||
1634 | <para> | ||
1635 | Lists environment variables to set when running a task | ||
1636 | in the fakeroot environment. | ||
1637 | For additional information on environment variables and | ||
1638 | the fakeroot environment, see the | ||
1639 | <link linkend='var-bb-FAKEROOTBASEENV'><filename>FAKEROOTBASEENV</filename></link> | ||
1640 | variable. | ||
1641 | </para> | ||
1642 | </glossdef> | ||
1643 | </glossentry> | ||
1644 | |||
1645 | <glossentry id='var-bb-FAKEROOTNOENV'><glossterm>FAKEROOTNOENV</glossterm> | ||
1646 | <glossdef> | ||
1647 | <para> | ||
1648 | Lists environment variables to set when running a task | ||
1649 | that is not in the fakeroot environment. | ||
1650 | For additional information on environment variables and | ||
1651 | the fakeroot environment, see the | ||
1652 | <link linkend='var-bb-FAKEROOTENV'><filename>FAKEROOTENV</filename></link> | ||
1653 | variable. | ||
1654 | </para> | ||
1655 | </glossdef> | ||
1656 | </glossentry> | ||
1657 | |||
1658 | <glossentry id='var-bb-FETCHCMD'><glossterm>FETCHCMD</glossterm> | ||
1659 | <glossdef> | ||
1660 | <para> | ||
1661 | Defines the command the BitBake fetcher module | ||
1662 | executes when running fetch operations. | ||
1663 | You need to use an override suffix when you use the | ||
1664 | variable (e.g. <filename>FETCHCMD_git</filename> | ||
1665 | or <filename>FETCHCMD_svn</filename>). | ||
1666 | </para> | ||
1667 | </glossdef> | ||
1668 | </glossentry> | ||
1669 | |||
1670 | <glossentry id='var-bb-FILE'><glossterm>FILE</glossterm> | ||
1671 | <glossdef> | ||
1672 | <para> | ||
1673 | Points at the current file. | ||
1674 | BitBake sets this variable during the parsing process | ||
1675 | to identify the file being parsed. | ||
1676 | BitBake also sets this variable when a recipe is being | ||
1677 | executed to identify the recipe file. | ||
1678 | </para> | ||
1679 | </glossdef> | ||
1680 | </glossentry> | ||
1681 | |||
1682 | <glossentry id='var-bb-FILESPATH'><glossterm>FILESPATH</glossterm> | ||
1683 | <glossdef> | ||
1684 | <para> | ||
1685 | Specifies directories BitBake uses when searching for | ||
1686 | patches and files. | ||
1687 | The "local" fetcher module uses these directories when | ||
1688 | handling <filename>file://</filename> URLs. | ||
1689 | The variable behaves like a shell <filename>PATH</filename> | ||
1690 | environment variable. | ||
1691 | The value is a colon-separated list of directories that | ||
1692 | are searched left-to-right in order. | ||
1693 | </para> | ||
1694 | </glossdef> | ||
1695 | </glossentry> | ||
1696 | |||
1697 | </glossdiv> | ||
1698 | |||
1699 | |||
1700 | <glossdiv id='var-bb-glossary-g'><title>G</title> | ||
1701 | |||
1702 | <glossentry id='var-bb-GITDIR'><glossterm>GITDIR</glossterm> | ||
1703 | <glossdef> | ||
1704 | <para> | ||
1705 | The directory in which a local copy of a Git repository | ||
1706 | is stored when it is cloned. | ||
1707 | </para> | ||
1708 | </glossdef> | ||
1709 | </glossentry> | ||
1710 | |||
1711 | </glossdiv> | ||
1712 | |||
1713 | |||
1714 | <glossdiv id='var-bb-glossary-h'><title>H</title> | ||
1715 | |||
1716 | <glossentry id='var-bb-HGDIR'><glossterm>HGDIR</glossterm> | ||
1717 | <glossdef> | ||
1718 | <para> | ||
1719 | The directory in which files checked out of a Mercurial | ||
1720 | system are stored. | ||
1721 | </para> | ||
1722 | </glossdef> | ||
1723 | </glossentry> | ||
1724 | |||
1725 | <glossentry id='var-bb-HOMEPAGE'><glossterm>HOMEPAGE</glossterm> | ||
1726 | <glossdef> | ||
1727 | <para>Website where more information about the software the recipe is building | ||
1728 | can be found.</para> | ||
1729 | </glossdef> | ||
1730 | </glossentry> | ||
1731 | |||
1732 | </glossdiv> | ||
1733 | |||
1734 | <glossdiv id='var-bb-glossary-i'><title>I</title> | ||
1735 | |||
1736 | <glossentry id='var-bb-INHERIT'><glossterm>INHERIT</glossterm> | ||
1737 | <glossdef> | ||
1738 | <para> | ||
1739 | Causes the named class or classes to be inherited globally. | ||
1740 | Anonymous functions in the class or classes | ||
1741 | are not executed for the | ||
1742 | base configuration and in each individual recipe. | ||
1743 | The OpenEmbedded build system ignores changes to | ||
1744 | <filename>INHERIT</filename> in individual recipes. | ||
1745 | </para> | ||
1746 | |||
1747 | <para> | ||
1748 | For more information on <filename>INHERIT</filename>, see | ||
1749 | the | ||
1750 | "<link linkend="inherit-configuration-directive"><filename>INHERIT</filename> Configuration Directive</link>" | ||
1751 | section. | ||
1752 | </para> | ||
1753 | </glossdef> | ||
1754 | </glossentry> | ||
1755 | |||
1756 | </glossdiv> | ||
1757 | |||
1758 | <!-- | ||
1759 | <glossdiv id='var-glossary-j'><title>J</title> | ||
1760 | </glossdiv> | ||
1761 | |||
1762 | <glossdiv id='var-glossary-k'><title>K</title> | ||
1763 | </glossdiv> | ||
1764 | --> | ||
1765 | |||
1766 | <glossdiv id='var-bb-glossary-l'><title>L</title> | ||
1767 | |||
1768 | <glossentry id='var-bb-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm> | ||
1769 | <glossdef> | ||
1770 | <para>Lists the layers, separated by spaces, upon which this recipe depends. | ||
1771 | Optionally, you can specify a specific layer version for a dependency | ||
1772 | by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3" | ||
1773 | to be compared against | ||
1774 | <link linkend='var-bb-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename> | ||
1775 | in this case). | ||
1776 | BitBake produces an error if any dependency is missing or | ||
1777 | the version numbers do not match exactly (if specified).</para> | ||
1778 | <para> | ||
1779 | You use this variable in the <filename>conf/layer.conf</filename> file. | ||
1780 | You must also use the specific layer name as a suffix | ||
1781 | to the variable (e.g. <filename>LAYERDEPENDS_mylayer</filename>).</para> | ||
1782 | </glossdef> | ||
1783 | </glossentry> | ||
1784 | |||
1785 | <glossentry id='var-bb-LAYERDIR'><glossterm>LAYERDIR</glossterm> | ||
1786 | <glossdef> | ||
1787 | <para>When used inside the <filename>layer.conf</filename> configuration | ||
1788 | file, this variable provides the path of the current layer. | ||
1789 | This variable is not available outside of <filename>layer.conf</filename> | ||
1790 | and references are expanded immediately when parsing of the file completes.</para> | ||
1791 | </glossdef> | ||
1792 | </glossentry> | ||
1793 | |||
1794 | <glossentry id='var-bb-LAYERDIR_RE'><glossterm>LAYERDIR_RE</glossterm> | ||
1795 | <glossdef> | ||
1796 | <para>When used inside the <filename>layer.conf</filename> configuration | ||
1797 | file, this variable provides the path of the current layer, | ||
1798 | escaped for use in a regular expression | ||
1799 | (<link linkend='var-bb-BBFILE_PATTERN'><filename>BBFILE_PATTERN</filename></link>). | ||
1800 | This variable is not available outside of <filename>layer.conf</filename> | ||
1801 | and references are expanded immediately when parsing of the file completes.</para> | ||
1802 | </glossdef> | ||
1803 | </glossentry> | ||
1804 | |||
1805 | <glossentry id='var-bb-LAYERVERSION'><glossterm>LAYERVERSION</glossterm> | ||
1806 | <glossdef> | ||
1807 | <para>Optionally specifies the version of a layer as a single number. | ||
1808 | You can use this variable within | ||
1809 | <link linkend='var-bb-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link> | ||
1810 | for another layer in order to depend on a specific version | ||
1811 | of the layer.</para> | ||
1812 | <para> | ||
1813 | You use this variable in the <filename>conf/layer.conf</filename> file. | ||
1814 | You must also use the specific layer name as a suffix | ||
1815 | to the variable (e.g. <filename>LAYERDEPENDS_mylayer</filename>).</para> | ||
1816 | </glossdef> | ||
1817 | </glossentry> | ||
1818 | |||
1819 | <glossentry id='var-bb-LICENSE'><glossterm>LICENSE</glossterm> | ||
1820 | <glossdef> | ||
1821 | <para> | ||
1822 | The list of source licenses for the recipe. | ||
1823 | </para> | ||
1824 | </glossdef> | ||
1825 | </glossentry> | ||
1826 | |||
1827 | </glossdiv> | ||
1828 | |||
1829 | <glossdiv id='var-bb-glossary-m'><title>M</title> | ||
1830 | |||
1831 | <glossentry id='var-bb-MIRRORS'><glossterm>MIRRORS</glossterm> | ||
1832 | <glossdef> | ||
1833 | <para> | ||
1834 | Specifies additional paths from which BitBake gets source code. | ||
1835 | When the build system searches for source code, it first | ||
1836 | tries the local download directory. | ||
1837 | If that location fails, the build system tries locations | ||
1838 | defined by | ||
1839 | <link linkend='var-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link>, | ||
1840 | the upstream source, and then locations specified by | ||
1841 | <filename>MIRRORS</filename> in that order. | ||
1842 | </para> | ||
1843 | </glossdef> | ||
1844 | </glossentry> | ||
1845 | |||
1846 | <glossentry id='var-bb-MULTI_PROVIDER_WHITELIST'><glossterm>MULTI_PROVIDER_WHITELIST</glossterm> | ||
1847 | <glossdef> | ||
1848 | <para> | ||
1849 | Allows you to suppress BitBake warnings caused when | ||
1850 | building two separate recipes that provide the same | ||
1851 | output. | ||
1852 | </para> | ||
1853 | |||
1854 | <para> | ||
1855 | BitBake normally issues a warning when building two | ||
1856 | different recipes where each provides the same output. | ||
1857 | This scenario is usually something the user does not | ||
1858 | want. | ||
1859 | However, cases do exist where it makes sense, particularly | ||
1860 | in the <filename>virtual/*</filename> namespace. | ||
1861 | You can use this variable to suppress BitBake's warnings. | ||
1862 | </para> | ||
1863 | |||
1864 | <para> | ||
1865 | To use the variable, list provider names (e.g. | ||
1866 | recipe names, <filename>virtual/kernel</filename>, | ||
1867 | and so forth). | ||
1868 | </para> | ||
1869 | </glossdef> | ||
1870 | </glossentry> | ||
1871 | |||
1872 | </glossdiv> | ||
1873 | |||
1874 | <!-- | ||
1875 | <glossdiv id='var-glossary-n'><title>N</title> | ||
1876 | </glossdiv> | ||
1877 | --> | ||
1878 | |||
1879 | <glossdiv id='var-bb-glossary-o'><title>O</title> | ||
1880 | |||
1881 | <glossentry id='var-bb-OVERRIDES'><glossterm>OVERRIDES</glossterm> | ||
1882 | <glossdef> | ||
1883 | <para> | ||
1884 | BitBake uses <filename>OVERRIDES</filename> to control | ||
1885 | what variables are overridden after BitBake parses | ||
1886 | recipes and configuration files. | ||
1887 | </para> | ||
1888 | |||
1889 | <para> | ||
1890 | Following is a simple example that uses an overrides | ||
1891 | list based on machine architectures: | ||
1892 | <literallayout class='monospaced'> | ||
1893 | OVERRIDES = "arm:x86:mips:powerpc" | ||
1894 | </literallayout> | ||
1895 | You can find information on how to use | ||
1896 | <filename>OVERRIDES</filename> in the | ||
1897 | "<link linkend='conditional-syntax-overrides'>Conditional Syntax (Overrides)</link>" | ||
1898 | section. | ||
1899 | </para> | ||
1900 | </glossdef> | ||
1901 | </glossentry> | ||
1902 | </glossdiv> | ||
1903 | |||
1904 | <glossdiv id='var-bb-glossary-p'><title>P</title> | ||
1905 | |||
1906 | <glossentry id='var-bb-P4DIR'><glossterm>P4DIR</glossterm> | ||
1907 | <glossdef> | ||
1908 | <para> | ||
1909 | The directory in which a local copy of a Perforce depot | ||
1910 | is stored when it is fetched. | ||
1911 | </para> | ||
1912 | </glossdef> | ||
1913 | </glossentry> | ||
1914 | |||
1915 | <glossentry id='var-bb-PACKAGES'><glossterm>PACKAGES</glossterm> | ||
1916 | <glossdef> | ||
1917 | <para>The list of packages the recipe creates. | ||
1918 | </para> | ||
1919 | </glossdef> | ||
1920 | </glossentry> | ||
1921 | |||
1922 | <glossentry id='var-bb-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm> | ||
1923 | <glossdef> | ||
1924 | <para> | ||
1925 | A promise that your recipe satisfies runtime dependencies | ||
1926 | for optional modules that are found in other recipes. | ||
1927 | <filename>PACKAGES_DYNAMIC</filename> | ||
1928 | does not actually satisfy the dependencies, it only states that | ||
1929 | they should be satisfied. | ||
1930 | For example, if a hard, runtime dependency | ||
1931 | (<link linkend='var-bb-RDEPENDS'><filename>RDEPENDS</filename></link>) | ||
1932 | of another package is satisfied during the build | ||
1933 | through the <filename>PACKAGES_DYNAMIC</filename> | ||
1934 | variable, but a package with the module name is never actually | ||
1935 | produced, then the other package will be broken. | ||
1936 | </para> | ||
1937 | </glossdef> | ||
1938 | </glossentry> | ||
1939 | |||
1940 | <glossentry id='var-bb-PE'><glossterm>PE</glossterm> | ||
1941 | <glossdef> | ||
1942 | <para> | ||
1943 | The epoch of the recipe. | ||
1944 | By default, this variable is unset. | ||
1945 | The variable is used to make upgrades possible when the | ||
1946 | versioning scheme changes in some backwards incompatible | ||
1947 | way. | ||
1948 | </para> | ||
1949 | </glossdef> | ||
1950 | </glossentry> | ||
1951 | |||
1952 | <glossentry id='var-bb-PERSISTENT_DIR'><glossterm>PERSISTENT_DIR</glossterm> | ||
1953 | <glossdef> | ||
1954 | <para> | ||
1955 | Specifies the directory BitBake uses to store data that | ||
1956 | should be preserved between builds. | ||
1957 | In particular, the data stored is the data that uses | ||
1958 | BitBake's persistent data API and the data used by the | ||
1959 | PR Server and PR Service. | ||
1960 | </para> | ||
1961 | </glossdef> | ||
1962 | </glossentry> | ||
1963 | |||
1964 | <glossentry id='var-bb-PF'><glossterm>PF</glossterm> | ||
1965 | <glossdef> | ||
1966 | <para> | ||
1967 | Specifies the recipe or package name and includes all version and revision | ||
1968 | numbers (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and | ||
1969 | <filename>bash-4.2-r1/</filename>). | ||
1970 | </para> | ||
1971 | </glossdef> | ||
1972 | </glossentry> | ||
1973 | |||
1974 | <glossentry id='var-bb-PN'><glossterm>PN</glossterm> | ||
1975 | <glossdef> | ||
1976 | <para>The recipe name.</para> | ||
1977 | </glossdef> | ||
1978 | </glossentry> | ||
1979 | |||
1980 | <glossentry id='var-bb-PR'><glossterm>PR</glossterm> | ||
1981 | <glossdef> | ||
1982 | <para>The revision of the recipe. | ||
1983 | </para> | ||
1984 | </glossdef> | ||
1985 | </glossentry> | ||
1986 | |||
1987 | <glossentry id='var-bb-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm> | ||
1988 | <glossdef> | ||
1989 | <para> | ||
1990 | Determines which recipe should be given preference when | ||
1991 | multiple recipes provide the same item. | ||
1992 | You should always suffix the variable with the name of the | ||
1993 | provided item, and you should set it to the | ||
1994 | <link linkend='var-bb-PN'><filename>PN</filename></link> | ||
1995 | of the recipe to which you want to give precedence. | ||
1996 | Some examples: | ||
1997 | <literallayout class='monospaced'> | ||
1998 | PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" | ||
1999 | PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" | ||
2000 | PREFERRED_PROVIDER_virtual/libgl ?= "mesa" | ||
2001 | </literallayout> | ||
2002 | </para> | ||
2003 | </glossdef> | ||
2004 | </glossentry> | ||
2005 | |||
2006 | <glossentry id='var-bb-PREFERRED_PROVIDERS'><glossterm>PREFERRED_PROVIDERS</glossterm> | ||
2007 | <glossdef> | ||
2008 | <para> | ||
2009 | Determines which recipe should be given preference for | ||
2010 | cases where multiple recipes provide the same item. | ||
2011 | Functionally, | ||
2012 | <filename>PREFERRED_PROVIDERS</filename> is identical to | ||
2013 | <link linkend='var-bb-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link>. | ||
2014 | However, the <filename>PREFERRED_PROVIDERS</filename> | ||
2015 | variable lets you define preferences for multiple | ||
2016 | situations using the following form: | ||
2017 | <literallayout class='monospaced'> | ||
2018 | PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..." | ||
2019 | </literallayout> | ||
2020 | This form is a convenient replacement for the following: | ||
2021 | <literallayout class='monospaced'> | ||
2022 | PREFERRED_PROVIDER_xxx = "yyy" | ||
2023 | PREFERRED_PROVIDER_aaa = "bbb" | ||
2024 | </literallayout> | ||
2025 | </para> | ||
2026 | </glossdef> | ||
2027 | </glossentry> | ||
2028 | |||
2029 | <glossentry id='var-bb-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm> | ||
2030 | <glossdef> | ||
2031 | <para> | ||
2032 | If there are multiple versions of recipes available, this | ||
2033 | variable determines which recipe should be given preference. | ||
2034 | You must always suffix the variable with the | ||
2035 | <link linkend='var-bb-PN'><filename>PN</filename></link> | ||
2036 | you want to select, and you should set | ||
2037 | <link linkend='var-bb-PV'><filename>PV</filename></link> | ||
2038 | accordingly for precedence. | ||
2039 | </para> | ||
2040 | |||
2041 | <para> | ||
2042 | The <filename>PREFERRED_VERSION</filename> variable | ||
2043 | supports limited wildcard use through the | ||
2044 | "<filename>%</filename>" character. | ||
2045 | You can use the character to match any number of | ||
2046 | characters, which can be useful when specifying versions | ||
2047 | that contain long revision numbers that potentially change. | ||
2048 | Here are two examples: | ||
2049 | <literallayout class='monospaced'> | ||
2050 | PREFERRED_VERSION_python = "2.7.3" | ||
2051 | PREFERRED_VERSION_linux-yocto = "4.12%" | ||
2052 | </literallayout> | ||
2053 | <note><title>Important</title> | ||
2054 | The use of the "<filename>%</filename>" character | ||
2055 | is limited in that it only works at the end of the | ||
2056 | string. | ||
2057 | You cannot use the wildcard character in any other | ||
2058 | location of the string. | ||
2059 | </note> | ||
2060 | </para> | ||
2061 | </glossdef> | ||
2062 | </glossentry> | ||
2063 | |||
2064 | <glossentry id='var-bb-PREMIRRORS'><glossterm>PREMIRRORS</glossterm> | ||
2065 | <glossdef> | ||
2066 | <para> | ||
2067 | Specifies additional paths from which BitBake gets source code. | ||
2068 | When the build system searches for source code, it first | ||
2069 | tries the local download directory. | ||
2070 | If that location fails, the build system tries locations | ||
2071 | defined by <filename>PREMIRRORS</filename>, the upstream | ||
2072 | source, and then locations specified by | ||
2073 | <link linkend='var-bb-MIRRORS'><filename>MIRRORS</filename></link> | ||
2074 | in that order. | ||
2075 | </para> | ||
2076 | |||
2077 | <para> | ||
2078 | Typically, you would add a specific server for the | ||
2079 | build system to attempt before any others by adding | ||
2080 | something like the following to your configuration: | ||
2081 | <literallayout class='monospaced'> | ||
2082 | PREMIRRORS_prepend = "\ | ||
2083 | git://.*/.* http://www.yoctoproject.org/sources/ \n \ | ||
2084 | ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ | ||
2085 | http://.*/.* http://www.yoctoproject.org/sources/ \n \ | ||
2086 | https://.*/.* http://www.yoctoproject.org/sources/ \n" | ||
2087 | </literallayout> | ||
2088 | These changes cause the build system to intercept | ||
2089 | Git, FTP, HTTP, and HTTPS requests and direct them to | ||
2090 | the <filename>http://</filename> sources mirror. | ||
2091 | You can use <filename>file://</filename> URLs to point | ||
2092 | to local directories or network shares as well. | ||
2093 | </para> | ||
2094 | </glossdef> | ||
2095 | </glossentry> | ||
2096 | |||
2097 | <glossentry id='var-bb-PROVIDES'><glossterm>PROVIDES</glossterm> | ||
2098 | <glossdef> | ||
2099 | <para> | ||
2100 | A list of aliases by which a particular recipe can be | ||
2101 | known. | ||
2102 | By default, a recipe's own | ||
2103 | <filename><link linkend='var-bb-PN'>PN</link></filename> | ||
2104 | is implicitly already in its <filename>PROVIDES</filename> | ||
2105 | list. | ||
2106 | If a recipe uses <filename>PROVIDES</filename>, the | ||
2107 | additional aliases are synonyms for the recipe and can | ||
2108 | be useful satisfying dependencies of other recipes during | ||
2109 | the build as specified by | ||
2110 | <filename><link linkend='var-bb-DEPENDS'>DEPENDS</link></filename>. | ||
2111 | </para> | ||
2112 | |||
2113 | <para> | ||
2114 | Consider the following example | ||
2115 | <filename>PROVIDES</filename> statement from a recipe | ||
2116 | file <filename>libav_0.8.11.bb</filename>: | ||
2117 | <literallayout class='monospaced'> | ||
2118 | PROVIDES += "libpostproc" | ||
2119 | </literallayout> | ||
2120 | The <filename>PROVIDES</filename> statement results in | ||
2121 | the "libav" recipe also being known as "libpostproc". | ||
2122 | </para> | ||
2123 | |||
2124 | <para> | ||
2125 | In addition to providing recipes under alternate names, | ||
2126 | the <filename>PROVIDES</filename> mechanism is also used | ||
2127 | to implement virtual targets. | ||
2128 | A virtual target is a name that corresponds to some | ||
2129 | particular functionality (e.g. a Linux kernel). | ||
2130 | Recipes that provide the functionality in question list the | ||
2131 | virtual target in <filename>PROVIDES</filename>. | ||
2132 | Recipes that depend on the functionality in question can | ||
2133 | include the virtual target in | ||
2134 | <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> | ||
2135 | to leave the choice of provider open. | ||
2136 | </para> | ||
2137 | |||
2138 | <para> | ||
2139 | Conventionally, virtual targets have names on the form | ||
2140 | "virtual/function" (e.g. "virtual/kernel"). | ||
2141 | The slash is simply part of the name and has no | ||
2142 | syntactical significance. | ||
2143 | </para> | ||
2144 | </glossdef> | ||
2145 | </glossentry> | ||
2146 | |||
2147 | <glossentry id='var-bb-PRSERV_HOST'><glossterm>PRSERV_HOST</glossterm> | ||
2148 | <glossdef> | ||
2149 | <para> | ||
2150 | The network based | ||
2151 | <link linkend='var-bb-PR'><filename>PR</filename></link> | ||
2152 | service host and port. | ||
2153 | </para> | ||
2154 | |||
2155 | <para> | ||
2156 | Following is an example of how the <filename>PRSERV_HOST</filename> variable is | ||
2157 | set: | ||
2158 | <literallayout class='monospaced'> | ||
2159 | PRSERV_HOST = "localhost:0" | ||
2160 | </literallayout> | ||
2161 | You must set the variable if you want to automatically | ||
2162 | start a local PR service. | ||
2163 | You can set <filename>PRSERV_HOST</filename> to other | ||
2164 | values to use a remote PR service. | ||
2165 | </para> | ||
2166 | </glossdef> | ||
2167 | </glossentry> | ||
2168 | |||
2169 | <glossentry id='var-bb-PV'><glossterm>PV</glossterm> | ||
2170 | <glossdef> | ||
2171 | <para>The version of the recipe. | ||
2172 | </para> | ||
2173 | </glossdef> | ||
2174 | </glossentry> | ||
2175 | |||
2176 | </glossdiv> | ||
2177 | |||
2178 | <!-- | ||
2179 | <glossdiv id='var-glossary-q'><title>Q</title> | ||
2180 | </glossdiv> | ||
2181 | --> | ||
2182 | |||
2183 | <glossdiv id='var-bb-glossary-r'><title>R</title> | ||
2184 | |||
2185 | <glossentry id='var-bb-RDEPENDS'><glossterm>RDEPENDS</glossterm> | ||
2186 | <glossdef> | ||
2187 | <para> | ||
2188 | Lists a package's runtime dependencies (i.e. other packages) | ||
2189 | that must be installed in order for the built package to run | ||
2190 | correctly. | ||
2191 | If a package in this list cannot be found during the build, | ||
2192 | you will get a build error. | ||
2193 | </para> | ||
2194 | |||
2195 | <para> | ||
2196 | Because the <filename>RDEPENDS</filename> variable applies | ||
2197 | to packages being built, you should always use the variable | ||
2198 | in a form with an attached package name. | ||
2199 | For example, suppose you are building a development package | ||
2200 | that depends on the <filename>perl</filename> package. | ||
2201 | In this case, you would use the following | ||
2202 | <filename>RDEPENDS</filename> statement: | ||
2203 | <literallayout class='monospaced'> | ||
2204 | RDEPENDS_${PN}-dev += "perl" | ||
2205 | </literallayout> | ||
2206 | In the example, the development package depends on | ||
2207 | the <filename>perl</filename> package. | ||
2208 | Thus, the <filename>RDEPENDS</filename> variable has the | ||
2209 | <filename>${PN}-dev</filename> package name as part of the | ||
2210 | variable. | ||
2211 | </para> | ||
2212 | |||
2213 | <para> | ||
2214 | BitBake supports specifying versioned dependencies. | ||
2215 | Although the syntax varies depending on the packaging | ||
2216 | format, BitBake hides these differences from you. | ||
2217 | Here is the general syntax to specify versions with | ||
2218 | the <filename>RDEPENDS</filename> variable: | ||
2219 | <literallayout class='monospaced'> | ||
2220 | RDEPENDS_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)" | ||
2221 | </literallayout> | ||
2222 | For <filename>operator</filename>, you can specify the | ||
2223 | following: | ||
2224 | <literallayout class='monospaced'> | ||
2225 | = | ||
2226 | < | ||
2227 | > | ||
2228 | <= | ||
2229 | >= | ||
2230 | </literallayout> | ||
2231 | For example, the following sets up a dependency on version | ||
2232 | 1.2 or greater of the package <filename>foo</filename>: | ||
2233 | <literallayout class='monospaced'> | ||
2234 | RDEPENDS_${PN} = "foo (>= 1.2)" | ||
2235 | </literallayout> | ||
2236 | </para> | ||
2237 | |||
2238 | <para> | ||
2239 | For information on build-time dependencies, see the | ||
2240 | <link linkend='var-bb-DEPENDS'><filename>DEPENDS</filename></link> | ||
2241 | variable. | ||
2242 | </para> | ||
2243 | </glossdef> | ||
2244 | </glossentry> | ||
2245 | |||
2246 | <glossentry id='var-bb-REPODIR'><glossterm>REPODIR</glossterm> | ||
2247 | <glossdef> | ||
2248 | <para> | ||
2249 | The directory in which a local copy of a | ||
2250 | <filename>google-repo</filename> directory is stored | ||
2251 | when it is synced. | ||
2252 | </para> | ||
2253 | </glossdef> | ||
2254 | </glossentry> | ||
2255 | |||
2256 | <glossentry id='var-bb-RPROVIDES'><glossterm>RPROVIDES</glossterm> | ||
2257 | <glossdef> | ||
2258 | <para> | ||
2259 | A list of package name aliases that a package also provides. | ||
2260 | These aliases are useful for satisfying runtime dependencies | ||
2261 | of other packages both during the build and on the target | ||
2262 | (as specified by | ||
2263 | <filename><link linkend='var-bb-RDEPENDS'>RDEPENDS</link></filename>). | ||
2264 | </para> | ||
2265 | <para> | ||
2266 | As with all package-controlling variables, you must always | ||
2267 | use the variable in conjunction with a package name override. | ||
2268 | Here is an example: | ||
2269 | <literallayout class='monospaced'> | ||
2270 | RPROVIDES_${PN} = "widget-abi-2" | ||
2271 | </literallayout> | ||
2272 | </para> | ||
2273 | </glossdef> | ||
2274 | </glossentry> | ||
2275 | |||
2276 | <glossentry id='var-bb-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm> | ||
2277 | <glossdef> | ||
2278 | <para> | ||
2279 | A list of packages that extends the usability of a package | ||
2280 | being built. | ||
2281 | The package being built does not depend on this list of | ||
2282 | packages in order to successfully build, but needs them for | ||
2283 | the extended usability. | ||
2284 | To specify runtime dependencies for packages, see the | ||
2285 | <filename><link linkend='var-bb-RDEPENDS'>RDEPENDS</link></filename> | ||
2286 | variable. | ||
2287 | </para> | ||
2288 | |||
2289 | <para> | ||
2290 | BitBake supports specifying versioned recommends. | ||
2291 | Although the syntax varies depending on the packaging | ||
2292 | format, BitBake hides these differences from you. | ||
2293 | Here is the general syntax to specify versions with | ||
2294 | the <filename>RRECOMMENDS</filename> variable: | ||
2295 | <literallayout class='monospaced'> | ||
2296 | RRECOMMENDS_${PN} = "<replaceable>package</replaceable> (<replaceable>operator</replaceable> <replaceable>version</replaceable>)" | ||
2297 | </literallayout> | ||
2298 | For <filename>operator</filename>, you can specify the | ||
2299 | following: | ||
2300 | <literallayout class='monospaced'> | ||
2301 | = | ||
2302 | < | ||
2303 | > | ||
2304 | <= | ||
2305 | >= | ||
2306 | </literallayout> | ||
2307 | For example, the following sets up a recommend on version | ||
2308 | 1.2 or greater of the package <filename>foo</filename>: | ||
2309 | <literallayout class='monospaced'> | ||
2310 | RRECOMMENDS_${PN} = "foo (>= 1.2)" | ||
2311 | </literallayout> | ||
2312 | </para> | ||
2313 | </glossdef> | ||
2314 | </glossentry> | ||
2315 | |||
2316 | </glossdiv> | ||
2317 | |||
2318 | <glossdiv id='var-bb-glossary-s'><title>S</title> | ||
2319 | |||
2320 | <glossentry id='var-bb-SECTION'><glossterm>SECTION</glossterm> | ||
2321 | <glossdef> | ||
2322 | <para>The section in which packages should be categorized.</para> | ||
2323 | </glossdef> | ||
2324 | </glossentry> | ||
2325 | |||
2326 | <glossentry id='var-bb-SRC_URI'><glossterm>SRC_URI</glossterm> | ||
2327 | <glossdef> | ||
2328 | <para> | ||
2329 | The list of source files - local or remote. | ||
2330 | This variable tells BitBake which bits | ||
2331 | to pull for the build and how to pull them. | ||
2332 | For example, if the recipe or append file needs to | ||
2333 | fetch a single tarball from the Internet, the recipe or | ||
2334 | append file uses a <filename>SRC_URI</filename> | ||
2335 | entry that specifies that tarball. | ||
2336 | On the other hand, if the recipe or append file needs to | ||
2337 | fetch a tarball and include a custom file, the recipe or | ||
2338 | append file needs an <filename>SRC_URI</filename> variable | ||
2339 | that specifies all those sources.</para> | ||
2340 | <para>The following list explains the available URI protocols: | ||
2341 | <itemizedlist> | ||
2342 | <listitem><para><emphasis><filename>file://</filename> -</emphasis> | ||
2343 | Fetches files, which are usually files shipped with | ||
2344 | the metadata, | ||
2345 | from the local machine. | ||
2346 | The path is relative to the | ||
2347 | <link linkend='var-bb-FILESPATH'><filename>FILESPATH</filename></link> | ||
2348 | variable.</para></listitem> | ||
2349 | <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a | ||
2350 | Bazaar revision control repository.</para></listitem> | ||
2351 | <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a | ||
2352 | Git revision control repository.</para></listitem> | ||
2353 | <listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from | ||
2354 | an OSC (OpenSUSE Build service) revision control repository.</para></listitem> | ||
2355 | <listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from | ||
2356 | a repo (Git) repository.</para></listitem> | ||
2357 | <listitem><para><emphasis><filename>http://</filename> -</emphasis> Fetches files from | ||
2358 | the Internet using HTTP.</para></listitem> | ||
2359 | <listitem><para><emphasis><filename>https://</filename> -</emphasis> Fetches files | ||
2360 | from the Internet using HTTPS.</para></listitem> | ||
2361 | <listitem><para><emphasis><filename>ftp://</filename> -</emphasis> Fetches files | ||
2362 | from the Internet using FTP.</para></listitem> | ||
2363 | <listitem><para><emphasis><filename>cvs://</filename> -</emphasis> Fetches files from | ||
2364 | a CVS revision control repository.</para></listitem> | ||
2365 | <listitem><para><emphasis><filename>hg://</filename> -</emphasis> Fetches files from | ||
2366 | a Mercurial (<filename>hg</filename>) revision control repository.</para></listitem> | ||
2367 | <listitem><para><emphasis><filename>p4://</filename> -</emphasis> Fetches files from | ||
2368 | a Perforce (<filename>p4</filename>) revision control repository.</para></listitem> | ||
2369 | <listitem><para><emphasis><filename>ssh://</filename> -</emphasis> Fetches files from | ||
2370 | a secure shell.</para></listitem> | ||
2371 | <listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from | ||
2372 | a Subversion (<filename>svn</filename>) revision control repository.</para></listitem> | ||
2373 | </itemizedlist> | ||
2374 | </para> | ||
2375 | <para>Here are some additional options worth mentioning: | ||
2376 | <itemizedlist> | ||
2377 | <listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls | ||
2378 | whether or not to unpack the file if it is an archive. | ||
2379 | The default action is to unpack the file.</para></listitem> | ||
2380 | <listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file | ||
2381 | (or extracts its contents) into the specified | ||
2382 | subdirectory. | ||
2383 | This option is useful for unusual tarballs or other archives that | ||
2384 | do not have their files already in a subdirectory within the archive. | ||
2385 | </para></listitem> | ||
2386 | <listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a | ||
2387 | name to be used for association with <filename>SRC_URI</filename> checksums | ||
2388 | when you have more than one file specified in <filename>SRC_URI</filename>. | ||
2389 | </para></listitem> | ||
2390 | <listitem><para><emphasis><filename>downloadfilename</filename> -</emphasis> Specifies | ||
2391 | the filename used when storing the downloaded file.</para></listitem> | ||
2392 | </itemizedlist> | ||
2393 | </para> | ||
2394 | </glossdef> | ||
2395 | </glossentry> | ||
2396 | |||
2397 | <glossentry id='var-bb-SRCDATE'><glossterm>SRCDATE</glossterm> | ||
2398 | <glossdef> | ||
2399 | <para> | ||
2400 | The date of the source code used to build the package. | ||
2401 | This variable applies only if the source was fetched from a Source Code Manager (SCM). | ||
2402 | </para> | ||
2403 | </glossdef> | ||
2404 | </glossentry> | ||
2405 | |||
2406 | <glossentry id='var-bb-SRCREV'><glossterm>SRCREV</glossterm> | ||
2407 | <glossdef> | ||
2408 | <para> | ||
2409 | The revision of the source code used to build the package. | ||
2410 | This variable applies only when using Subversion, Git, Mercurial and Bazaar. | ||
2411 | If you want to build a fixed revision and you want | ||
2412 | to avoid performing a query on the remote repository every time | ||
2413 | BitBake parses your recipe, you should specify a <filename>SRCREV</filename> that is a | ||
2414 | full revision identifier and not just a tag. | ||
2415 | </para> | ||
2416 | </glossdef> | ||
2417 | </glossentry> | ||
2418 | |||
2419 | <glossentry id='var-bb-SRCREV_FORMAT'><glossterm>SRCREV_FORMAT</glossterm> | ||
2420 | <glossdef> | ||
2421 | <para> | ||
2422 | Helps construct valid | ||
2423 | <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link> | ||
2424 | values when multiple source controlled URLs are used in | ||
2425 | <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>. | ||
2426 | </para> | ||
2427 | |||
2428 | <para> | ||
2429 | The system needs help constructing these values under these | ||
2430 | circumstances. | ||
2431 | Each component in the <filename>SRC_URI</filename> | ||
2432 | is assigned a name and these are referenced | ||
2433 | in the <filename>SRCREV_FORMAT</filename> variable. | ||
2434 | Consider an example with URLs named "machine" and "meta". | ||
2435 | In this case, <filename>SRCREV_FORMAT</filename> could look | ||
2436 | like "machine_meta" and those names would have the SCM | ||
2437 | versions substituted into each position. | ||
2438 | Only one <filename>AUTOINC</filename> placeholder is added | ||
2439 | and if needed. | ||
2440 | And, this placeholder is placed at the start of the | ||
2441 | returned string. | ||
2442 | </para> | ||
2443 | </glossdef> | ||
2444 | </glossentry> | ||
2445 | |||
2446 | <glossentry id='var-bb-STAMP'><glossterm>STAMP</glossterm> | ||
2447 | <glossdef> | ||
2448 | <para> | ||
2449 | Specifies the base path used to create recipe stamp files. | ||
2450 | The path to an actual stamp file is constructed by evaluating this | ||
2451 | string and then appending additional information. | ||
2452 | </para> | ||
2453 | </glossdef> | ||
2454 | </glossentry> | ||
2455 | |||
2456 | <glossentry id='var-bb-STAMPCLEAN'><glossterm>STAMPCLEAN</glossterm> | ||
2457 | <glossdef> | ||
2458 | <para> | ||
2459 | Specifies the base path used to create recipe stamp files. | ||
2460 | Unlike the | ||
2461 | <link linkend='var-bb-STAMP'><filename>STAMP</filename></link> | ||
2462 | variable, <filename>STAMPCLEAN</filename> can contain | ||
2463 | wildcards to match the range of files a clean operation | ||
2464 | should remove. | ||
2465 | BitBake uses a clean operation to remove any other stamps | ||
2466 | it should be removing when creating a new stamp. | ||
2467 | </para> | ||
2468 | </glossdef> | ||
2469 | </glossentry> | ||
2470 | |||
2471 | <glossentry id='var-bb-SUMMARY'><glossterm>SUMMARY</glossterm> | ||
2472 | <glossdef> | ||
2473 | <para> | ||
2474 | A short summary for the recipe, which is 72 characters or less. | ||
2475 | </para> | ||
2476 | </glossdef> | ||
2477 | </glossentry> | ||
2478 | |||
2479 | <glossentry id='var-bb-SVNDIR'><glossterm>SVNDIR</glossterm> | ||
2480 | <glossdef> | ||
2481 | <para> | ||
2482 | The directory in which files checked out of a Subversion | ||
2483 | system are stored. | ||
2484 | </para> | ||
2485 | </glossdef> | ||
2486 | </glossentry> | ||
2487 | |||
2488 | </glossdiv> | ||
2489 | |||
2490 | <glossdiv id='var-bb-glossary-t'><title>T</title> | ||
2491 | |||
2492 | <glossentry id='var-bb-T'><glossterm>T</glossterm> | ||
2493 | <glossdef> | ||
2494 | <para>Points to a directory were BitBake places | ||
2495 | temporary files, which consist mostly of task logs and | ||
2496 | scripts, when building a particular recipe. | ||
2497 | </para> | ||
2498 | </glossdef> | ||
2499 | </glossentry> | ||
2500 | |||
2501 | <glossentry id='var-bb-TOPDIR'><glossterm>TOPDIR</glossterm> | ||
2502 | <glossdef> | ||
2503 | <para> | ||
2504 | Points to the build directory. | ||
2505 | BitBake automatically sets this variable. | ||
2506 | </para> | ||
2507 | </glossdef> | ||
2508 | </glossentry> | ||
2509 | |||
2510 | </glossdiv> | ||
2511 | |||
2512 | <!-- | ||
2513 | <glossdiv id='var-glossary-u'><title>U</title> | ||
2514 | </glossdiv> | ||
2515 | |||
2516 | <glossdiv id='var-glossary-v'><title>V</title> | ||
2517 | </glossdiv> | ||
2518 | |||
2519 | <glossdiv id='var-glossary-w'><title>W</title> | ||
2520 | </glossdiv> | ||
2521 | |||
2522 | <glossdiv id='var-glossary-x'><title>X</title> | ||
2523 | </glossdiv> | ||
2524 | |||
2525 | <glossdiv id='var-glossary-y'><title>Y</title> | ||
2526 | </glossdiv> | ||
2527 | |||
2528 | <glossdiv id='var-glossary-z'><title>Z</title> | ||
2529 | </glossdiv> | ||
2530 | --> | ||
2531 | |||
2532 | |||
2533 | </glossary> | ||
2534 | </chapter> | ||
2535 | <!-- | ||
2536 | vim: expandtab tw=80 ts=4 | ||
2537 | --> | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-style.css b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-style.css deleted file mode 100644 index 65da2a4e31..0000000000 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-style.css +++ /dev/null | |||
@@ -1,984 +0,0 @@ | |||
1 | /* | ||
2 | Generic XHTML / DocBook XHTML CSS Stylesheet. | ||
3 | |||
4 | Browser wrangling and typographic design by | ||
5 | Oyvind Kolas / pippin@gimp.org | ||
6 | |||
7 | Customised for Poky by | ||
8 | Matthew Allum / mallum@o-hand.com | ||
9 | |||
10 | Thanks to: | ||
11 | Liam R. E. Quin | ||
12 | William Skaggs | ||
13 | Jakub Steiner | ||
14 | |||
15 | Structure | ||
16 | --------- | ||
17 | |||
18 | The stylesheet is divided into the following sections: | ||
19 | |||
20 | Positioning | ||
21 | Margins, paddings, width, font-size, clearing. | ||
22 | Decorations | ||
23 | Borders, style | ||
24 | Colors | ||
25 | Colors | ||
26 | Graphics | ||
27 | Graphical backgrounds | ||
28 | Nasty IE tweaks | ||
29 | Workarounds needed to make it work in internet explorer, | ||
30 | currently makes the stylesheet non validating, but up until | ||
31 | this point it is validating. | ||
32 | Mozilla extensions | ||
33 | Transparency for footer | ||
34 | Rounded corners on boxes | ||
35 | |||
36 | */ | ||
37 | |||
38 | |||
39 | /*************** / | ||
40 | / Positioning / | ||
41 | / ***************/ | ||
42 | |||
43 | body { | ||
44 | font-family: Verdana, Sans, sans-serif; | ||
45 | |||
46 | min-width: 640px; | ||
47 | width: 80%; | ||
48 | margin: 0em auto; | ||
49 | padding: 2em 5em 5em 5em; | ||
50 | color: #333; | ||
51 | } | ||
52 | |||
53 | h1,h2,h3,h4,h5,h6,h7 { | ||
54 | font-family: Arial, Sans; | ||
55 | color: #00557D; | ||
56 | clear: both; | ||
57 | } | ||
58 | |||
59 | h1 { | ||
60 | font-size: 2em; | ||
61 | text-align: left; | ||
62 | padding: 0em 0em 0em 0em; | ||
63 | margin: 2em 0em 0em 0em; | ||
64 | } | ||
65 | |||
66 | h2.subtitle { | ||
67 | margin: 0.10em 0em 3.0em 0em; | ||
68 | padding: 0em 0em 0em 0em; | ||
69 | font-size: 1.8em; | ||
70 | padding-left: 20%; | ||
71 | font-weight: normal; | ||
72 | font-style: italic; | ||
73 | } | ||
74 | |||
75 | h2 { | ||
76 | margin: 2em 0em 0.66em 0em; | ||
77 | padding: 0.5em 0em 0em 0em; | ||
78 | font-size: 1.5em; | ||
79 | font-weight: bold; | ||
80 | } | ||
81 | |||
82 | h3.subtitle { | ||
83 | margin: 0em 0em 1em 0em; | ||
84 | padding: 0em 0em 0em 0em; | ||
85 | font-size: 142.14%; | ||
86 | text-align: right; | ||
87 | } | ||
88 | |||
89 | h3 { | ||
90 | margin: 1em 0em 0.5em 0em; | ||
91 | padding: 1em 0em 0em 0em; | ||
92 | font-size: 140%; | ||
93 | font-weight: bold; | ||
94 | } | ||
95 | |||
96 | h4 { | ||
97 | margin: 1em 0em 0.5em 0em; | ||
98 | padding: 1em 0em 0em 0em; | ||
99 | font-size: 120%; | ||
100 | font-weight: bold; | ||
101 | } | ||
102 | |||
103 | h5 { | ||
104 | margin: 1em 0em 0.5em 0em; | ||
105 | padding: 1em 0em 0em 0em; | ||
106 | font-size: 110%; | ||
107 | font-weight: bold; | ||
108 | } | ||
109 | |||
110 | h6 { | ||
111 | margin: 1em 0em 0em 0em; | ||
112 | padding: 1em 0em 0em 0em; | ||
113 | font-size: 110%; | ||
114 | font-weight: bold; | ||
115 | } | ||
116 | |||
117 | .authorgroup { | ||
118 | background-color: transparent; | ||
119 | background-repeat: no-repeat; | ||
120 | padding-top: 256px; | ||
121 | background-image: url("figures/bitbake-title.png"); | ||
122 | background-position: left top; | ||
123 | margin-top: -256px; | ||
124 | padding-right: 50px; | ||
125 | margin-left: 0px; | ||
126 | text-align: right; | ||
127 | width: 740px; | ||
128 | } | ||
129 | |||
130 | h3.author { | ||
131 | margin: 0em 0me 0em 0em; | ||
132 | padding: 0em 0em 0em 0em; | ||
133 | font-weight: normal; | ||
134 | font-size: 100%; | ||
135 | color: #333; | ||
136 | clear: both; | ||
137 | } | ||
138 | |||
139 | .author tt.email { | ||
140 | font-size: 66%; | ||
141 | } | ||
142 | |||
143 | .titlepage hr { | ||
144 | width: 0em; | ||
145 | clear: both; | ||
146 | } | ||
147 | |||
148 | .revhistory { | ||
149 | padding-top: 2em; | ||
150 | clear: both; | ||
151 | } | ||
152 | |||
153 | .toc, | ||
154 | .list-of-tables, | ||
155 | .list-of-examples, | ||
156 | .list-of-figures { | ||
157 | padding: 1.33em 0em 2.5em 0em; | ||
158 | color: #00557D; | ||
159 | } | ||
160 | |||
161 | .toc p, | ||
162 | .list-of-tables p, | ||
163 | .list-of-figures p, | ||
164 | .list-of-examples p { | ||
165 | padding: 0em 0em 0em 0em; | ||
166 | padding: 0em 0em 0.3em; | ||
167 | margin: 1.5em 0em 0em 0em; | ||
168 | } | ||
169 | |||
170 | .toc p b, | ||
171 | .list-of-tables p b, | ||
172 | .list-of-figures p b, | ||
173 | .list-of-examples p b{ | ||
174 | font-size: 100.0%; | ||
175 | font-weight: bold; | ||
176 | } | ||
177 | |||
178 | .toc dl, | ||
179 | .list-of-tables dl, | ||
180 | .list-of-figures dl, | ||
181 | .list-of-examples dl { | ||
182 | margin: 0em 0em 0.5em 0em; | ||
183 | padding: 0em 0em 0em 0em; | ||
184 | } | ||
185 | |||
186 | .toc dt { | ||
187 | margin: 0em 0em 0em 0em; | ||
188 | padding: 0em 0em 0em 0em; | ||
189 | } | ||
190 | |||
191 | .toc dd { | ||
192 | margin: 0em 0em 0em 2.6em; | ||
193 | padding: 0em 0em 0em 0em; | ||
194 | } | ||
195 | |||
196 | div.glossary dl, | ||
197 | div.variablelist dl { | ||
198 | } | ||
199 | |||
200 | .glossary dl dt, | ||
201 | .variablelist dl dt, | ||
202 | .variablelist dl dt span.term { | ||
203 | font-weight: normal; | ||
204 | width: 20em; | ||
205 | text-align: right; | ||
206 | } | ||
207 | |||
208 | .variablelist dl dt { | ||
209 | margin-top: 0.5em; | ||
210 | } | ||
211 | |||
212 | .glossary dl dd, | ||
213 | .variablelist dl dd { | ||
214 | margin-top: -1em; | ||
215 | margin-left: 25.5em; | ||
216 | } | ||
217 | |||
218 | .glossary dd p, | ||
219 | .variablelist dd p { | ||
220 | margin-top: 0em; | ||
221 | margin-bottom: 1em; | ||
222 | } | ||
223 | |||
224 | |||
225 | div.calloutlist table td { | ||
226 | padding: 0em 0em 0em 0em; | ||
227 | margin: 0em 0em 0em 0em; | ||
228 | } | ||
229 | |||
230 | div.calloutlist table td p { | ||
231 | margin-top: 0em; | ||
232 | margin-bottom: 1em; | ||
233 | } | ||
234 | |||
235 | div p.copyright { | ||
236 | text-align: left; | ||
237 | } | ||
238 | |||
239 | div.legalnotice p.legalnotice-title { | ||
240 | margin-bottom: 0em; | ||
241 | } | ||
242 | |||
243 | p { | ||
244 | line-height: 1.5em; | ||
245 | margin-top: 0em; | ||
246 | |||
247 | } | ||
248 | |||
249 | dl { | ||
250 | padding-top: 0em; | ||
251 | } | ||
252 | |||
253 | hr { | ||
254 | border: solid 1px; | ||
255 | } | ||
256 | |||
257 | |||
258 | .mediaobject, | ||
259 | .mediaobjectco { | ||
260 | text-align: center; | ||
261 | } | ||
262 | |||
263 | img { | ||
264 | border: none; | ||
265 | } | ||
266 | |||
267 | ul { | ||
268 | padding: 0em 0em 0em 1.5em; | ||
269 | } | ||
270 | |||
271 | ul li { | ||
272 | padding: 0em 0em 0em 0em; | ||
273 | } | ||
274 | |||
275 | ul li p { | ||
276 | text-align: left; | ||
277 | } | ||
278 | |||
279 | table { | ||
280 | width :100%; | ||
281 | } | ||
282 | |||
283 | th { | ||
284 | padding: 0.25em; | ||
285 | text-align: left; | ||
286 | font-weight: normal; | ||
287 | vertical-align: top; | ||
288 | } | ||
289 | |||
290 | td { | ||
291 | padding: 0.25em; | ||
292 | vertical-align: top; | ||
293 | } | ||
294 | |||
295 | p a[id] { | ||
296 | margin: 0px; | ||
297 | padding: 0px; | ||
298 | display: inline; | ||
299 | background-image: none; | ||
300 | } | ||
301 | |||
302 | a { | ||
303 | text-decoration: underline; | ||
304 | color: #444; | ||
305 | } | ||
306 | |||
307 | pre { | ||
308 | overflow: auto; | ||
309 | } | ||
310 | |||
311 | a:hover { | ||
312 | text-decoration: underline; | ||
313 | /*font-weight: bold;*/ | ||
314 | } | ||
315 | |||
316 | /* This style defines how the permalink character | ||
317 | appears by itself and when hovered over with | ||
318 | the mouse. */ | ||
319 | |||
320 | [alt='Permalink'] { color: #eee; } | ||
321 | [alt='Permalink']:hover { color: black; } | ||
322 | |||
323 | |||
324 | div.informalfigure, | ||
325 | div.informalexample, | ||
326 | div.informaltable, | ||
327 | div.figure, | ||
328 | div.table, | ||
329 | div.example { | ||
330 | margin: 1em 0em; | ||
331 | padding: 1em; | ||
332 | page-break-inside: avoid; | ||
333 | } | ||
334 | |||
335 | |||
336 | div.informalfigure p.title b, | ||
337 | div.informalexample p.title b, | ||
338 | div.informaltable p.title b, | ||
339 | div.figure p.title b, | ||
340 | div.example p.title b, | ||
341 | div.table p.title b{ | ||
342 | padding-top: 0em; | ||
343 | margin-top: 0em; | ||
344 | font-size: 100%; | ||
345 | font-weight: normal; | ||
346 | } | ||
347 | |||
348 | .mediaobject .caption, | ||
349 | .mediaobject .caption p { | ||
350 | text-align: center; | ||
351 | font-size: 80%; | ||
352 | padding-top: 0.5em; | ||
353 | padding-bottom: 0.5em; | ||
354 | } | ||
355 | |||
356 | .epigraph { | ||
357 | padding-left: 55%; | ||
358 | margin-bottom: 1em; | ||
359 | } | ||
360 | |||
361 | .epigraph p { | ||
362 | text-align: left; | ||
363 | } | ||
364 | |||
365 | .epigraph .quote { | ||
366 | font-style: italic; | ||
367 | } | ||
368 | .epigraph .attribution { | ||
369 | font-style: normal; | ||
370 | text-align: right; | ||
371 | } | ||
372 | |||
373 | span.application { | ||
374 | font-style: italic; | ||
375 | } | ||
376 | |||
377 | .programlisting { | ||
378 | font-family: monospace; | ||
379 | font-size: 80%; | ||
380 | white-space: pre; | ||
381 | margin: 1.33em 0em; | ||
382 | padding: 1.33em; | ||
383 | } | ||
384 | |||
385 | .tip, | ||
386 | .warning, | ||
387 | .caution, | ||
388 | .note { | ||
389 | margin-top: 1em; | ||
390 | margin-bottom: 1em; | ||
391 | |||
392 | } | ||
393 | |||
394 | /* force full width of table within div */ | ||
395 | .tip table, | ||
396 | .warning table, | ||
397 | .caution table, | ||
398 | .note table { | ||
399 | border: none; | ||
400 | width: 100%; | ||
401 | } | ||
402 | |||
403 | |||
404 | .tip table th, | ||
405 | .warning table th, | ||
406 | .caution table th, | ||
407 | .note table th { | ||
408 | padding: 0.8em 0.0em 0.0em 0.0em; | ||
409 | margin : 0em 0em 0em 0em; | ||
410 | } | ||
411 | |||
412 | .tip p, | ||
413 | .warning p, | ||
414 | .caution p, | ||
415 | .note p { | ||
416 | margin-top: 0.5em; | ||
417 | margin-bottom: 0.5em; | ||
418 | padding-right: 1em; | ||
419 | text-align: left; | ||
420 | } | ||
421 | |||
422 | .acronym { | ||
423 | text-transform: uppercase; | ||
424 | } | ||
425 | |||
426 | b.keycap, | ||
427 | .keycap { | ||
428 | padding: 0.09em 0.3em; | ||
429 | margin: 0em; | ||
430 | } | ||
431 | |||
432 | .itemizedlist li { | ||
433 | clear: none; | ||
434 | } | ||
435 | |||
436 | .filename { | ||
437 | font-size: medium; | ||
438 | font-family: Courier, monospace; | ||
439 | } | ||
440 | |||
441 | |||
442 | div.navheader, div.heading{ | ||
443 | position: absolute; | ||
444 | left: 0em; | ||
445 | top: 0em; | ||
446 | width: 100%; | ||
447 | background-color: #cdf; | ||
448 | width: 100%; | ||
449 | } | ||
450 | |||
451 | div.navfooter, div.footing{ | ||
452 | position: fixed; | ||
453 | left: 0em; | ||
454 | bottom: 0em; | ||
455 | background-color: #eee; | ||
456 | width: 100%; | ||
457 | } | ||
458 | |||
459 | |||
460 | div.navheader td, | ||
461 | div.navfooter td { | ||
462 | font-size: 66%; | ||
463 | } | ||
464 | |||
465 | div.navheader table th { | ||
466 | /*font-family: Georgia, Times, serif;*/ | ||
467 | /*font-size: x-large;*/ | ||
468 | font-size: 80%; | ||
469 | } | ||
470 | |||
471 | div.navheader table { | ||
472 | border-left: 0em; | ||
473 | border-right: 0em; | ||
474 | border-top: 0em; | ||
475 | width: 100%; | ||
476 | } | ||
477 | |||
478 | div.navfooter table { | ||
479 | border-left: 0em; | ||
480 | border-right: 0em; | ||
481 | border-bottom: 0em; | ||
482 | width: 100%; | ||
483 | } | ||
484 | |||
485 | div.navheader table td a, | ||
486 | div.navfooter table td a { | ||
487 | color: #777; | ||
488 | text-decoration: none; | ||
489 | } | ||
490 | |||
491 | /* normal text in the footer */ | ||
492 | div.navfooter table td { | ||
493 | color: black; | ||
494 | } | ||
495 | |||
496 | div.navheader table td a:visited, | ||
497 | div.navfooter table td a:visited { | ||
498 | color: #444; | ||
499 | } | ||
500 | |||
501 | |||
502 | /* links in header and footer */ | ||
503 | div.navheader table td a:hover, | ||
504 | div.navfooter table td a:hover { | ||
505 | text-decoration: underline; | ||
506 | background-color: transparent; | ||
507 | color: #33a; | ||
508 | } | ||
509 | |||
510 | div.navheader hr, | ||
511 | div.navfooter hr { | ||
512 | display: none; | ||
513 | } | ||
514 | |||
515 | |||
516 | .qandaset tr.question td p { | ||
517 | margin: 0em 0em 1em 0em; | ||
518 | padding: 0em 0em 0em 0em; | ||
519 | } | ||
520 | |||
521 | .qandaset tr.answer td p { | ||
522 | margin: 0em 0em 1em 0em; | ||
523 | padding: 0em 0em 0em 0em; | ||
524 | } | ||
525 | .answer td { | ||
526 | padding-bottom: 1.5em; | ||
527 | } | ||
528 | |||
529 | .emphasis { | ||
530 | font-weight: bold; | ||
531 | } | ||
532 | |||
533 | |||
534 | /************* / | ||
535 | / decorations / | ||
536 | / *************/ | ||
537 | |||
538 | .titlepage { | ||
539 | } | ||
540 | |||
541 | .part .title { | ||
542 | } | ||
543 | |||
544 | .subtitle { | ||
545 | border: none; | ||
546 | } | ||
547 | |||
548 | /* | ||
549 | h1 { | ||
550 | border: none; | ||
551 | } | ||
552 | |||
553 | h2 { | ||
554 | border-top: solid 0.2em; | ||
555 | border-bottom: solid 0.06em; | ||
556 | } | ||
557 | |||
558 | h3 { | ||
559 | border-top: 0em; | ||
560 | border-bottom: solid 0.06em; | ||
561 | } | ||
562 | |||
563 | h4 { | ||
564 | border: 0em; | ||
565 | border-bottom: solid 0.06em; | ||
566 | } | ||
567 | |||
568 | h5 { | ||
569 | border: 0em; | ||
570 | } | ||
571 | */ | ||
572 | |||
573 | .programlisting { | ||
574 | border: solid 1px; | ||
575 | } | ||
576 | |||
577 | div.figure, | ||
578 | div.table, | ||
579 | div.informalfigure, | ||
580 | div.informaltable, | ||
581 | div.informalexample, | ||
582 | div.example { | ||
583 | border: 1px solid; | ||
584 | } | ||
585 | |||
586 | |||
587 | |||
588 | .tip, | ||
589 | .warning, | ||
590 | .caution, | ||
591 | .note { | ||
592 | border: 1px solid; | ||
593 | } | ||
594 | |||
595 | .tip table th, | ||
596 | .warning table th, | ||
597 | .caution table th, | ||
598 | .note table th { | ||
599 | border-bottom: 1px solid; | ||
600 | } | ||
601 | |||
602 | .question td { | ||
603 | border-top: 1px solid black; | ||
604 | } | ||
605 | |||
606 | .answer { | ||
607 | } | ||
608 | |||
609 | |||
610 | b.keycap, | ||
611 | .keycap { | ||
612 | border: 1px solid; | ||
613 | } | ||
614 | |||
615 | |||
616 | div.navheader, div.heading{ | ||
617 | border-bottom: 1px solid; | ||
618 | } | ||
619 | |||
620 | |||
621 | div.navfooter, div.footing{ | ||
622 | border-top: 1px solid; | ||
623 | } | ||
624 | |||
625 | /********* / | ||
626 | / colors / | ||
627 | / *********/ | ||
628 | |||
629 | body { | ||
630 | color: #333; | ||
631 | background: white; | ||
632 | } | ||
633 | |||
634 | a { | ||
635 | background: transparent; | ||
636 | } | ||
637 | |||
638 | a:hover { | ||
639 | background-color: #dedede; | ||
640 | } | ||
641 | |||
642 | |||
643 | h1, | ||
644 | h2, | ||
645 | h3, | ||
646 | h4, | ||
647 | h5, | ||
648 | h6, | ||
649 | h7, | ||
650 | h8 { | ||
651 | background-color: transparent; | ||
652 | } | ||
653 | |||
654 | hr { | ||
655 | border-color: #aaa; | ||
656 | } | ||
657 | |||
658 | |||
659 | .tip, .warning, .caution, .note { | ||
660 | border-color: #fff; | ||
661 | } | ||
662 | |||
663 | |||
664 | .tip table th, | ||
665 | .warning table th, | ||
666 | .caution table th, | ||
667 | .note table th { | ||
668 | border-bottom-color: #fff; | ||
669 | } | ||
670 | |||
671 | |||
672 | .warning { | ||
673 | background-color: #f0f0f2; | ||
674 | } | ||
675 | |||
676 | .caution { | ||
677 | background-color: #f0f0f2; | ||
678 | } | ||
679 | |||
680 | .tip { | ||
681 | background-color: #f0f0f2; | ||
682 | } | ||
683 | |||
684 | .note { | ||
685 | background-color: #f0f0f2; | ||
686 | } | ||
687 | |||
688 | .glossary dl dt, | ||
689 | .variablelist dl dt, | ||
690 | .variablelist dl dt span.term { | ||
691 | color: #044; | ||
692 | } | ||
693 | |||
694 | div.figure, | ||
695 | div.table, | ||
696 | div.example, | ||
697 | div.informalfigure, | ||
698 | div.informaltable, | ||
699 | div.informalexample { | ||
700 | border-color: #aaa; | ||
701 | } | ||
702 | |||
703 | pre.programlisting { | ||
704 | color: black; | ||
705 | background-color: #fff; | ||
706 | border-color: #aaa; | ||
707 | border-width: 2px; | ||
708 | } | ||
709 | |||
710 | .guimenu, | ||
711 | .guilabel, | ||
712 | .guimenuitem { | ||
713 | background-color: #eee; | ||
714 | } | ||
715 | |||
716 | |||
717 | b.keycap, | ||
718 | .keycap { | ||
719 | background-color: #eee; | ||
720 | border-color: #999; | ||
721 | } | ||
722 | |||
723 | |||
724 | div.navheader { | ||
725 | border-color: black; | ||
726 | } | ||
727 | |||
728 | |||
729 | div.navfooter { | ||
730 | border-color: black; | ||
731 | } | ||
732 | |||
733 | |||
734 | /*********** / | ||
735 | / graphics / | ||
736 | / ***********/ | ||
737 | |||
738 | /* | ||
739 | body { | ||
740 | background-image: url("images/body_bg.jpg"); | ||
741 | background-attachment: fixed; | ||
742 | } | ||
743 | |||
744 | .navheader, | ||
745 | .note, | ||
746 | .tip { | ||
747 | background-image: url("images/note_bg.jpg"); | ||
748 | background-attachment: fixed; | ||
749 | } | ||
750 | |||
751 | .warning, | ||
752 | .caution { | ||
753 | background-image: url("images/warning_bg.jpg"); | ||
754 | background-attachment: fixed; | ||
755 | } | ||
756 | |||
757 | .figure, | ||
758 | .informalfigure, | ||
759 | .example, | ||
760 | .informalexample, | ||
761 | .table, | ||
762 | .informaltable { | ||
763 | background-image: url("images/figure_bg.jpg"); | ||
764 | background-attachment: fixed; | ||
765 | } | ||
766 | |||
767 | */ | ||
768 | h1, | ||
769 | h2, | ||
770 | h3, | ||
771 | h4, | ||
772 | h5, | ||
773 | h6, | ||
774 | h7{ | ||
775 | } | ||
776 | |||
777 | /* | ||
778 | Example of how to stick an image as part of the title. | ||
779 | |||
780 | div.article .titlepage .title | ||
781 | { | ||
782 | background-image: url("figures/white-on-black.png"); | ||
783 | background-position: center; | ||
784 | background-repeat: repeat-x; | ||
785 | } | ||
786 | */ | ||
787 | |||
788 | div.preface .titlepage .title, | ||
789 | div.colophon .title, | ||
790 | div.chapter .titlepage .title, | ||
791 | div.article .titlepage .title | ||
792 | { | ||
793 | } | ||
794 | |||
795 | div.section div.section .titlepage .title, | ||
796 | div.sect2 .titlepage .title { | ||
797 | background: none; | ||
798 | } | ||
799 | |||
800 | |||
801 | h1.title { | ||
802 | background-color: transparent; | ||
803 | background-repeat: no-repeat; | ||
804 | height: 256px; | ||
805 | text-indent: -9000px; | ||
806 | overflow:hidden; | ||
807 | } | ||
808 | |||
809 | h2.subtitle { | ||
810 | background-color: transparent; | ||
811 | text-indent: -9000px; | ||
812 | overflow:hidden; | ||
813 | width: 0px; | ||
814 | display: none; | ||
815 | } | ||
816 | |||
817 | /*************************************** / | ||
818 | / pippin.gimp.org specific alterations / | ||
819 | / ***************************************/ | ||
820 | |||
821 | /* | ||
822 | div.heading, div.navheader { | ||
823 | color: #777; | ||
824 | font-size: 80%; | ||
825 | padding: 0; | ||
826 | margin: 0; | ||
827 | text-align: left; | ||
828 | position: absolute; | ||
829 | top: 0px; | ||
830 | left: 0px; | ||
831 | width: 100%; | ||
832 | height: 50px; | ||
833 | background: url('/gfx/heading_bg.png') transparent; | ||
834 | background-repeat: repeat-x; | ||
835 | background-attachment: fixed; | ||
836 | border: none; | ||
837 | } | ||
838 | |||
839 | div.heading a { | ||
840 | color: #444; | ||
841 | } | ||
842 | |||
843 | div.footing, div.navfooter { | ||
844 | border: none; | ||
845 | color: #ddd; | ||
846 | font-size: 80%; | ||
847 | text-align:right; | ||
848 | |||
849 | width: 100%; | ||
850 | padding-top: 10px; | ||
851 | position: absolute; | ||
852 | bottom: 0px; | ||
853 | left: 0px; | ||
854 | |||
855 | background: url('/gfx/footing_bg.png') transparent; | ||
856 | } | ||
857 | */ | ||
858 | |||
859 | |||
860 | |||
861 | /****************** / | ||
862 | / nasty ie tweaks / | ||
863 | / ******************/ | ||
864 | |||
865 | /* | ||
866 | div.heading, div.navheader { | ||
867 | width:expression(document.body.clientWidth + "px"); | ||
868 | } | ||
869 | |||
870 | div.footing, div.navfooter { | ||
871 | width:expression(document.body.clientWidth + "px"); | ||
872 | margin-left:expression("-5em"); | ||
873 | } | ||
874 | body { | ||
875 | padding:expression("4em 5em 0em 5em"); | ||
876 | } | ||
877 | */ | ||
878 | |||
879 | /**************************************** / | ||
880 | / mozilla vendor specific css extensions / | ||
881 | / ****************************************/ | ||
882 | /* | ||
883 | div.navfooter, div.footing{ | ||
884 | -moz-opacity: 0.8em; | ||
885 | } | ||
886 | |||
887 | div.figure, | ||
888 | div.table, | ||
889 | div.informalfigure, | ||
890 | div.informaltable, | ||
891 | div.informalexample, | ||
892 | div.example, | ||
893 | .tip, | ||
894 | .warning, | ||
895 | .caution, | ||
896 | .note { | ||
897 | -moz-border-radius: 0.5em; | ||
898 | } | ||
899 | |||
900 | b.keycap, | ||
901 | .keycap { | ||
902 | -moz-border-radius: 0.3em; | ||
903 | } | ||
904 | */ | ||
905 | |||
906 | table tr td table tr td { | ||
907 | display: none; | ||
908 | } | ||
909 | |||
910 | |||
911 | hr { | ||
912 | display: none; | ||
913 | } | ||
914 | |||
915 | table { | ||
916 | border: 0em; | ||
917 | } | ||
918 | |||
919 | .photo { | ||
920 | float: right; | ||
921 | margin-left: 1.5em; | ||
922 | margin-bottom: 1.5em; | ||
923 | margin-top: 0em; | ||
924 | max-width: 17em; | ||
925 | border: 1px solid gray; | ||
926 | padding: 3px; | ||
927 | background: white; | ||
928 | } | ||
929 | .seperator { | ||
930 | padding-top: 2em; | ||
931 | clear: both; | ||
932 | } | ||
933 | |||
934 | #validators { | ||
935 | margin-top: 5em; | ||
936 | text-align: right; | ||
937 | color: #777; | ||
938 | } | ||
939 | @media print { | ||
940 | body { | ||
941 | font-size: 8pt; | ||
942 | } | ||
943 | .noprint { | ||
944 | display: none; | ||
945 | } | ||
946 | } | ||
947 | |||
948 | |||
949 | .tip, | ||
950 | .note { | ||
951 | background: #f0f0f2; | ||
952 | color: #333; | ||
953 | padding: 20px; | ||
954 | margin: 20px; | ||
955 | } | ||
956 | |||
957 | .tip h3, | ||
958 | .note h3 { | ||
959 | padding: 0em; | ||
960 | margin: 0em; | ||
961 | font-size: 2em; | ||
962 | font-weight: bold; | ||
963 | color: #333; | ||
964 | } | ||
965 | |||
966 | .tip a, | ||
967 | .note a { | ||
968 | color: #333; | ||
969 | text-decoration: underline; | ||
970 | } | ||
971 | |||
972 | .footnote { | ||
973 | font-size: small; | ||
974 | color: #333; | ||
975 | } | ||
976 | |||
977 | /* Changes the announcement text */ | ||
978 | .tip h3, | ||
979 | .warning h3, | ||
980 | .caution h3, | ||
981 | .note h3 { | ||
982 | font-size:large; | ||
983 | color: #00557D; | ||
984 | } | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual.xml deleted file mode 100644 index d793265c9a..0000000000 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual.xml +++ /dev/null | |||
@@ -1,88 +0,0 @@ | |||
1 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" | ||
2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> | ||
3 | |||
4 | <book id='bitbake-user-manual' lang='en' | ||
5 | xmlns:xi="http://www.w3.org/2003/XInclude" | ||
6 | xmlns="http://docbook.org/ns/docbook" | ||
7 | > | ||
8 | <bookinfo> | ||
9 | |||
10 | <mediaobject> | ||
11 | <imageobject> | ||
12 | <imagedata fileref='figures/bitbake-title.png' | ||
13 | format='SVG' | ||
14 | align='left' scalefit='1' width='100%'/> | ||
15 | </imageobject> | ||
16 | </mediaobject> | ||
17 | |||
18 | <title> | ||
19 | BitBake User Manual | ||
20 | </title> | ||
21 | |||
22 | <authorgroup> | ||
23 | <author> | ||
24 | <firstname>Richard Purdie, Chris Larson, and </firstname> <surname>Phil Blundell</surname> | ||
25 | <affiliation> | ||
26 | <orgname>BitBake Community</orgname> | ||
27 | </affiliation> | ||
28 | <email>bitbake-devel@lists.openembedded.org</email> | ||
29 | </author> | ||
30 | </authorgroup> | ||
31 | |||
32 | <!-- | ||
33 | # Add in some revision history if we want it here. | ||
34 | <revhistory> | ||
35 | <revision> | ||
36 | <revnumber>x.x</revnumber> | ||
37 | <date>dd month year</date> | ||
38 | <revremark>Some relevent comment</revremark> | ||
39 | </revision> | ||
40 | <revision> | ||
41 | <revnumber>x.x</revnumber> | ||
42 | <date>dd month year</date> | ||
43 | <revremark>Some relevent comment</revremark> | ||
44 | </revision> | ||
45 | <revision> | ||
46 | <revnumber>x.x</revnumber> | ||
47 | <date>dd month year</date> | ||
48 | <revremark>Some relevent comment</revremark> | ||
49 | </revision> | ||
50 | <revision> | ||
51 | <revnumber>x.x</revnumber> | ||
52 | <date>dd month year</date> | ||
53 | <revremark>Some relevent comment</revremark> | ||
54 | </revision> | ||
55 | </revhistory> | ||
56 | --> | ||
57 | |||
58 | <copyright> | ||
59 | <year>2004-2018</year> | ||
60 | <holder>Richard Purdie</holder> | ||
61 | <holder>Chris Larson</holder> | ||
62 | <holder>and Phil Blundell</holder> | ||
63 | </copyright> | ||
64 | |||
65 | <legalnotice> | ||
66 | <para> | ||
67 | This work is licensed under the Creative Commons Attribution License. | ||
68 | To view a copy of this license, visit | ||
69 | <ulink url="http://creativecommons.org/licenses/by/2.5/">http://creativecommons.org/licenses/by/2.5/</ulink> | ||
70 | or send a letter to Creative Commons, 444 Castro Street, | ||
71 | Suite 900, Mountain View, California 94041, USA. | ||
72 | </para> | ||
73 | </legalnotice> | ||
74 | </bookinfo> | ||
75 | |||
76 | <xi:include href="bitbake-user-manual-intro.xml"/> | ||
77 | |||
78 | <xi:include href="bitbake-user-manual-execution.xml"/> | ||
79 | |||
80 | <xi:include href="bitbake-user-manual-metadata.xml"/> | ||
81 | |||
82 | <xi:include href="bitbake-user-manual-fetching.xml"/> | ||
83 | |||
84 | <xi:include href="bitbake-user-manual-ref-variables.xml"/> | ||
85 | |||
86 | <xi:include href="bitbake-user-manual-hello.xml"/> | ||
87 | |||
88 | </book> | ||
diff --git a/bitbake/doc/bitbake-user-manual/html.css b/bitbake/doc/bitbake-user-manual/html.css deleted file mode 100644 index 6eedfd3189..0000000000 --- a/bitbake/doc/bitbake-user-manual/html.css +++ /dev/null | |||
@@ -1,281 +0,0 @@ | |||
1 | /* Feuille de style DocBook du projet Traduc.org */ | ||
2 | /* DocBook CSS stylesheet of the Traduc.org project */ | ||
3 | |||
4 | /* (c) Jean-Philippe Guérard - 14 août 2004 */ | ||
5 | /* (c) Jean-Philippe Guérard - 14 August 2004 */ | ||
6 | |||
7 | /* Cette feuille de style est libre, vous pouvez la */ | ||
8 | /* redistribuer et la modifier selon les termes de la Licence */ | ||
9 | /* Art Libre. Vous trouverez un exemplaire de cette Licence sur */ | ||
10 | /* http://tigreraye.org/Petit-guide-du-traducteur.html#licence-art-libre */ | ||
11 | |||
12 | /* This work of art is free, you can redistribute it and/or */ | ||
13 | /* modify it according to terms of the Free Art license. You */ | ||
14 | /* will find a specimen of this license on the Copyleft */ | ||
15 | /* Attitude web site: http://artlibre.org as well as on other */ | ||
16 | /* sites. */ | ||
17 | /* Please note that the French version of this licence as shown */ | ||
18 | /* on http://tigreraye.org/Petit-guide-du-traducteur.html#licence-art-libre */ | ||
19 | /* is only official licence of this document. The English */ | ||
20 | /* is only provided to help you understand this licence. */ | ||
21 | |||
22 | /* La dernière version de cette feuille de style est toujours */ | ||
23 | /* disponible sur : http://tigreraye.org/style.css */ | ||
24 | /* Elle est également disponible sur : */ | ||
25 | /* http://www.traduc.org/docs/HOWTO/lecture/style.css */ | ||
26 | |||
27 | /* The latest version of this stylesheet is available from: */ | ||
28 | /* http://tigreraye.org/style.css */ | ||
29 | /* It is also available on: */ | ||
30 | /* http://www.traduc.org/docs/HOWTO/lecture/style.css */ | ||
31 | |||
32 | /* N'hésitez pas à envoyer vos commentaires et corrections à */ | ||
33 | /* Jean-Philippe Guérard <jean-philippe.guerard@tigreraye.org> */ | ||
34 | |||
35 | /* Please send feedback and bug reports to */ | ||
36 | /* Jean-Philippe Guérard <jean-philippe.guerard@tigreraye.org> */ | ||
37 | |||
38 | /* $Id: style.css,v 1.14 2004/09/10 20:12:09 fevrier Exp fevrier $ */ | ||
39 | |||
40 | /* Présentation générale du document */ | ||
41 | /* Overall document presentation */ | ||
42 | |||
43 | body { | ||
44 | /* | ||
45 | font-family: Apolline, "URW Palladio L", Garamond, jGaramond, | ||
46 | "Bitstream Cyberbit", "Palatino Linotype", serif; | ||
47 | */ | ||
48 | margin: 7%; | ||
49 | background-color: white; | ||
50 | } | ||
51 | |||
52 | /* Taille du texte */ | ||
53 | /* Text size */ | ||
54 | |||
55 | * { font-size: 100%; } | ||
56 | |||
57 | /* Gestion des textes mis en relief imbriqués */ | ||
58 | /* Embedded emphasis */ | ||
59 | |||
60 | em { font-style: italic; } | ||
61 | em em { font-style: normal; } | ||
62 | em em em { font-style: italic; } | ||
63 | |||
64 | /* Titres */ | ||
65 | /* Titles */ | ||
66 | |||
67 | h1 { font-size: 200%; font-weight: 900; } | ||
68 | h2 { font-size: 160%; font-weight: 900; } | ||
69 | h3 { font-size: 130%; font-weight: bold; } | ||
70 | h4 { font-size: 115%; font-weight: bold; } | ||
71 | h5 { font-size: 108%; font-weight: bold; } | ||
72 | h6 { font-weight: bold; } | ||
73 | |||
74 | /* Nom de famille en petites majuscules (uniquement en français) */ | ||
75 | /* Last names in small caps (for French only) */ | ||
76 | |||
77 | *[class~="surname"]:lang(fr) { font-variant: small-caps; } | ||
78 | |||
79 | /* Blocs de citation */ | ||
80 | /* Quotation blocs */ | ||
81 | |||
82 | div[class~="blockquote"] { | ||
83 | border: solid 2px #AAA; | ||
84 | padding: 5px; | ||
85 | margin: 5px; | ||
86 | } | ||
87 | |||
88 | div[class~="blockquote"] > table { | ||
89 | border: none; | ||
90 | } | ||
91 | |||
92 | /* Blocs litéraux : fond gris clair */ | ||
93 | /* Literal blocs: light gray background */ | ||
94 | |||
95 | *[class~="literallayout"] { | ||
96 | background: #f0f0f0; | ||
97 | padding: 5px; | ||
98 | margin: 5px; | ||
99 | } | ||
100 | |||
101 | /* Programmes et captures texte : fond bleu clair */ | ||
102 | /* Listing and text screen snapshots: light blue background */ | ||
103 | |||
104 | *[class~="programlisting"], *[class~="screen"] { | ||
105 | background: #f0f0ff; | ||
106 | padding: 5px; | ||
107 | margin: 5px; | ||
108 | } | ||
109 | |||
110 | /* Les textes à remplacer sont surlignés en vert pâle */ | ||
111 | /* Replaceable text in highlighted in pale green */ | ||
112 | |||
113 | *[class~="replaceable"] { | ||
114 | background-color: #98fb98; | ||
115 | font-style: normal; } | ||
116 | |||
117 | /* Tables : fonds gris clair & bords simples */ | ||
118 | /* Tables: light gray background and solid borders */ | ||
119 | |||
120 | *[class~="table"] *[class~="title"] { width:100%; border: 0px; } | ||
121 | |||
122 | table { | ||
123 | border: 1px solid #aaa; | ||
124 | border-collapse: collapse; | ||
125 | padding: 2px; | ||
126 | margin: 5px; | ||
127 | } | ||
128 | |||
129 | /* Listes simples en style table */ | ||
130 | /* Simples lists in table presentation */ | ||
131 | |||
132 | table[class~="simplelist"] { | ||
133 | background-color: #F0F0F0; | ||
134 | margin: 5px; | ||
135 | border: solid 1px #AAA; | ||
136 | } | ||
137 | |||
138 | table[class~="simplelist"] td { | ||
139 | border: solid 1px #AAA; | ||
140 | } | ||
141 | |||
142 | /* Les tables */ | ||
143 | /* Tables */ | ||
144 | |||
145 | *[class~="table"] table { | ||
146 | background-color: #F0F0F0; | ||
147 | border: solid 1px #AAA; | ||
148 | } | ||
149 | *[class~="informaltable"] table { background-color: #F0F0F0; } | ||
150 | |||
151 | th,td { | ||
152 | vertical-align: baseline; | ||
153 | text-align: left; | ||
154 | padding: 0.1em 0.3em; | ||
155 | empty-cells: show; | ||
156 | } | ||
157 | |||
158 | /* Alignement des colonnes */ | ||
159 | /* Colunms alignment */ | ||
160 | |||
161 | td[align=center] , th[align=center] { text-align: center; } | ||
162 | td[align=right] , th[align=right] { text-align: right; } | ||
163 | td[align=left] , th[align=left] { text-align: left; } | ||
164 | td[align=justify] , th[align=justify] { text-align: justify; } | ||
165 | |||
166 | /* Pas de marge autour des images */ | ||
167 | /* No inside margins for images */ | ||
168 | |||
169 | img { border: 0; } | ||
170 | |||
171 | /* Les liens ne sont pas soulignés */ | ||
172 | /* No underlines for links */ | ||
173 | |||
174 | :link , :visited , :active { text-decoration: none; } | ||
175 | |||
176 | /* Prudence : cadre jaune et fond jaune clair */ | ||
177 | /* Caution: yellow border and light yellow background */ | ||
178 | |||
179 | *[class~="caution"] { | ||
180 | border: solid 2px yellow; | ||
181 | background-color: #ffffe0; | ||
182 | padding: 1em 6px 1em ; | ||
183 | margin: 5px; | ||
184 | } | ||
185 | |||
186 | *[class~="caution"] th { | ||
187 | vertical-align: middle | ||
188 | } | ||
189 | |||
190 | *[class~="caution"] table { | ||
191 | background-color: #ffffe0; | ||
192 | border: none; | ||
193 | } | ||
194 | |||
195 | /* Note importante : cadre jaune et fond jaune clair */ | ||
196 | /* Important: yellow border and light yellow background */ | ||
197 | |||
198 | *[class~="important"] { | ||
199 | border: solid 2px yellow; | ||
200 | background-color: #ffffe0; | ||
201 | padding: 1em 6px 1em; | ||
202 | margin: 5px; | ||
203 | } | ||
204 | |||
205 | *[class~="important"] th { | ||
206 | vertical-align: middle | ||
207 | } | ||
208 | |||
209 | *[class~="important"] table { | ||
210 | background-color: #ffffe0; | ||
211 | border: none; | ||
212 | } | ||
213 | |||
214 | /* Mise en évidence : texte légèrement plus grand */ | ||
215 | /* Highlights: slightly larger texts */ | ||
216 | |||
217 | *[class~="highlights"] { | ||
218 | font-size: 110%; | ||
219 | } | ||
220 | |||
221 | /* Note : cadre bleu et fond bleu clair */ | ||
222 | /* Notes: blue border and light blue background */ | ||
223 | |||
224 | *[class~="note"] { | ||
225 | border: solid 2px #7099C5; | ||
226 | background-color: #f0f0ff; | ||
227 | padding: 1em 6px 1em ; | ||
228 | margin: 5px; | ||
229 | } | ||
230 | |||
231 | *[class~="note"] th { | ||
232 | vertical-align: middle | ||
233 | } | ||
234 | |||
235 | *[class~="note"] table { | ||
236 | background-color: #f0f0ff; | ||
237 | border: none; | ||
238 | } | ||
239 | |||
240 | /* Astuce : cadre vert et fond vert clair */ | ||
241 | /* Tip: green border and light green background */ | ||
242 | |||
243 | *[class~="tip"] { | ||
244 | border: solid 2px #00ff00; | ||
245 | background-color: #f0ffff; | ||
246 | padding: 1em 6px 1em ; | ||
247 | margin: 5px; | ||
248 | } | ||
249 | |||
250 | *[class~="tip"] th { | ||
251 | vertical-align: middle; | ||
252 | } | ||
253 | |||
254 | *[class~="tip"] table { | ||
255 | background-color: #f0ffff; | ||
256 | border: none; | ||
257 | } | ||
258 | |||
259 | /* Avertissement : cadre rouge et fond rouge clair */ | ||
260 | /* Warning: red border and light red background */ | ||
261 | |||
262 | *[class~="warning"] { | ||
263 | border: solid 2px #ff0000; | ||
264 | background-color: #fff0f0; | ||
265 | padding: 1em 6px 1em ; | ||
266 | margin: 5px; | ||
267 | } | ||
268 | |||
269 | *[class~="warning"] th { | ||
270 | vertical-align: middle; | ||
271 | } | ||
272 | |||
273 | |||
274 | *[class~="warning"] table { | ||
275 | background-color: #fff0f0; | ||
276 | border: none; | ||
277 | } | ||
278 | |||
279 | /* Fin */ | ||
280 | /* The End */ | ||
281 | |||
diff --git a/bitbake/doc/poky.ent b/bitbake/doc/poky.ent deleted file mode 100644 index 85d9c83bf2..0000000000 --- a/bitbake/doc/poky.ent +++ /dev/null | |||
@@ -1,51 +0,0 @@ | |||
1 | <!ENTITY DISTRO "1.4"> | ||
2 | <!ENTITY DISTRO_NAME "tbd"> | ||
3 | <!ENTITY YOCTO_DOC_VERSION "1.4"> | ||
4 | <!ENTITY POKYVERSION "8.0"> | ||
5 | <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;"> | ||
6 | <!ENTITY COPYRIGHT_YEAR "2010-2013"> | ||
7 | <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org"> | ||
8 | <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org"> | ||
9 | <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org"> | ||
10 | <!ENTITY YOCTO_BUGZILLA_URL "http://bugzilla.yoctoproject.org"> | ||
11 | <!ENTITY YOCTO_WIKI_URL "https://wiki.yoctoproject.org"> | ||
12 | <!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org"> | ||
13 | <!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org"> | ||
14 | <!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org"> | ||
15 | <!ENTITY OE_HOME_URL "http://www.openembedded.org"> | ||
16 | <!ENTITY OE_LISTS_URL "http://lists.linuxtogo.org/cgi-bin/mailman"> | ||
17 | <!ENTITY OE_DOCS_URL "http://docs.openembedded.org"> | ||
18 | <!ENTITY OH_HOME_URL "http://o-hand.com"> | ||
19 | <!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/"> | ||
20 | <!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs"> | ||
21 | <!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/"> | ||
22 | <!ENTITY YOCTO_AB_PORT_URL "&YOCTO_AB_URL;:8010"> | ||
23 | <!ENTITY YOCTO_AB_NIGHTLY_URL "&YOCTO_AB_URL;/nightly/"> | ||
24 | <!ENTITY YOCTO_POKY_URL "&YOCTO_DL_URL;/releases/poky/"> | ||
25 | <!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;"> | ||
26 | <!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/"> | ||
27 | <!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt_installer"> | ||
28 | <!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2"> | ||
29 | <!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines"> | ||
30 | <!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu"> | ||
31 | <!ENTITY YOCTO_PYTHON-i686_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2"> | ||
32 | <!ENTITY YOCTO_PYTHON-x86_64_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2"> | ||
33 | <!ENTITY YOCTO_DOCS_QS_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/yocto-project-qs/yocto-project-qs.html"> | ||
34 | <!ENTITY YOCTO_DOCS_ADT_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/adt-manual/adt-manual.html"> | ||
35 | <!ENTITY YOCTO_DOCS_REF_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/ref-manual/ref-manual.html"> | ||
36 | <!ENTITY YOCTO_DOCS_BSP_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bsp-guide/bsp-guide.html"> | ||
37 | <!ENTITY YOCTO_DOCS_DEV_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/dev-manual/dev-manual.html"> | ||
38 | <!ENTITY YOCTO_DOCS_KERNEL_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-manual/kernel-manual.html"> | ||
39 | <!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;"> | ||
40 | <!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2"> | ||
41 | <!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env"> | ||
42 | <!ENTITY OE_INIT_FILE "oe-init-build-env"> | ||
43 | <!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo \ | ||
44 | build-essential chrpath"> | ||
45 | <!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \ | ||
46 | diffutils diffstat git cpp gcc gcc-c++ eglibc-devel texinfo chrpath \ | ||
47 | ccache"> | ||
48 | <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \ | ||
49 | diffstat texinfo python-curses"> | ||
50 | <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \ | ||
51 | diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath"> | ||
diff --git a/bitbake/doc/template/Vera.xml b/bitbake/doc/template/Vera.xml deleted file mode 100644 index 3c82043e35..0000000000 --- a/bitbake/doc/template/Vera.xml +++ /dev/null | |||
@@ -1 +0,0 @@ | |||
1 | <?xml version="1.0" encoding="UTF-8"?><font-metrics type="TYPE0"><font-name>BitstreamVeraSans</font-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>928</ascender><descender>-235</descender><bbox><left>-183</left><bottom>-235</bottom><right>1287</right><top>928</top></bbox><flags>32</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="600"/><wx w="0"/><wx w="317"/><wx w="317"/><wx w="400"/><wx w="459"/><wx w="837"/><wx w="636"/><wx w="950"/><wx w="779"/><wx w="274"/><wx w="390"/><wx w="390"/><wx w="500"/><wx w="837"/><wx w="317"/><wx w="360"/><wx w="317"/><wx w="336"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="336"/><wx w="336"/><wx w="837"/><wx w="837"/><wx w="837"/><wx w="530"/><wx w="1000"/><wx w="684"/><wx w="686"/><wx w="698"/><wx w="770"/><wx w="631"/><wx w="575"/><wx w="774"/><wx w="751"/><wx w="294"/><wx w="294"/><wx w="655"/><wx w="557"/><wx w="862"/><wx w="748"/><wx w="787"/><wx w="603"/><wx w="787"/><wx w="694"/><wx w="634"/><wx w="610"/><wx w="731"/><wx w="684"/><wx w="988"/><wx w="685"/><wx w="610"/><wx w="685"/><wx w="390"/><wx w="336"/><wx w="390"/><wx w="837"/><wx w="500"/><wx w="500"/><wx w="612"/><wx w="634"/><wx w="549"/><wx w="634"/><wx w="615"/><wx w="352"/><wx w="634"/><wx w="633"/><wx w="277"/><wx w="277"/><wx w="579"/><wx w="277"/><wx w="974"/><wx w="633"/><wx w="611"/><wx w="634"/><wx w="634"/><wx w="411"/><wx w="520"/><wx w="392"/><wx w="633"/><wx w="591"/><wx w="817"/><wx w="591"/><wx w="591"/><wx w="524"/><wx w="636"/><wx w="336"/><wx w="636"/><wx w="837"/><wx w="684"/><wx w="684"/><wx w="698"/><wx w="631"/><wx w="748"/><wx w="787"/><wx w="731"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="549"/><wx w="615"/><wx w="615"/><wx w="615"/><wx w="615"/><wx w="277"/><wx w="277"/><wx w="277"/><wx w="277"/><wx w="633"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="633"/><wx w="633"/><wx w="633"/><wx w="633"/><wx w="500"/><wx w="500"/><wx w="636"/><wx w="636"/><wx w="500"/><wx w="589"/><wx w="636"/><wx w="629"/><wx w="1000"/><wx w="1000"/><wx w="1000"/><wx w="500"/><wx w="500"/><wx w="837"/><wx w="974"/><wx w="787"/><wx w="833"/><wx w="837"/><wx w="837"/><wx w="837"/><wx w="636"/><wx w="636"/><wx w="517"/><wx w="673"/><wx w="756"/><wx w="588"/><wx w="520"/><wx w="471"/><wx w="471"/><wx w="764"/><wx w="981"/><wx w="611"/><wx w="530"/><wx w="400"/><wx w="837"/><wx w="637"/><wx w="636"/><wx w="837"/><wx w="668"/><wx w="611"/><wx w="611"/><wx w="1000"/><wx w="636"/><wx w="684"/><wx w="684"/><wx w="787"/><wx w="1069"/><wx w="1022"/><wx w="500"/><wx w="1000"/><wx w="518"/><wx w="518"/><wx w="317"/><wx w="317"/><wx w="837"/><wx w="494"/><wx w="591"/><wx w="610"/><wx w="166"/><wx w="636"/><wx w="399"/><wx w="399"/><wx w="629"/><wx w="629"/><wx w="500"/><wx w="317"/><wx w="317"/><wx w="518"/><wx w="1341"/><wx w="684"/><wx w="631"/><wx w="684"/><wx w="631"/><wx w="631"/><wx w="294"/><wx w="294"/><wx w="294"/><wx w="294"/><wx w="787"/><wx w="787"/><wx w="787"/><wx w="731"/><wx w="731"/><wx w="731"/><wx w="277"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="562"/><wx w="284"/><wx w="634"/><wx w="520"/><wx w="685"/><wx w="524"/><wx w="336"/><wx w="774"/><wx w="611"/><wx w="610"/><wx w="591"/><wx w="604"/><wx w="634"/><wx w="837"/><wx w="837"/><wx w="400"/><wx w="400"/><wx w="400"/><wx w="969"/><wx w="969"/><wx w="969"/><wx w="774"/><wx w="634"/><wx w="294"/><wx w="634"/><wx w="520"/><wx w="698"/><wx w="549"/><wx w="698"/><wx w="549"/><wx w="634"/><wx w="360"/><wx w="317"/><wx w="636"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="400"/><wx w="500"/><wx w="500"/></cid-widths></multibyte-extras><kerning kpx1="246"><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="169"/><pair kern="-26" kpx2="197"/><pair kern="-35" kpx2="55"/><pair kern="-49" kpx2="60"/><pair kern="-49" kpx2="187"/><pair kern="-21" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-49" kpx2="234"/></kerning><kerning kpx1="235"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="43"><pair kern="-35" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-35" kpx2="197"/><pair kern="-30" kpx2="181"/></kerning><kerning kpx1="16"><pair kern="36" kpx2="246"/><pair kern="-17" kpx2="235"/><pair kern="-21" kpx2="199"/><pair kern="18" kpx2="123"/><pair kern="27" kpx2="208"/><pair kern="-118" kpx2="187"/><pair kern="-49" kpx2="59"/><pair kern="18" kpx2="124"/><pair kern="-21" kpx2="201"/><pair kern="-118" kpx2="60"/><pair kern="36" kpx2="52"/><pair kern="18" kpx2="125"/><pair kern="36" kpx2="42"/><pair kern="-118" kpx2="234"/><pair kern="18" kpx2="122"/><pair kern="27" kpx2="210"/><pair kern="-21" kpx2="36"/><pair kern="18" kpx2="82"/><pair kern="-40" kpx2="58"/><pair kern="-91" kpx2="55"/><pair kern="-17" kpx2="186"/><pair kern="27" kpx2="175"/><pair kern="27" kpx2="50"/><pair kern="27" kpx2="209"/><pair kern="27" kpx2="103"/><pair kern="-21" kpx2="98"/><pair kern="55" kpx2="45"/><pair kern="-21" kpx2="173"/><pair kern="-17" kpx2="92"/><pair kern="-26" kpx2="89"/><pair kern="18" kpx2="121"/><pair kern="-58" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-21" kpx2="174"/></kerning><kerning kpx1="112"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="123"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="251"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="213"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="208"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="187"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="113"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="144"><pair kern="-40" kpx2="180"/><pair kern="-54" kpx2="197"/><pair kern="-44" kpx2="181"/></kerning><kerning kpx1="59"><pair kern="-72" kpx2="100"/><pair kern="-63" kpx2="210"/><pair kern="-17" kpx2="55"/><pair kern="-44" kpx2="114"/><pair kern="-44" kpx2="72"/><pair kern="-63" kpx2="175"/><pair kern="-49" kpx2="16"/><pair kern="-63" kpx2="50"/><pair kern="-63" kpx2="209"/><pair kern="-44" kpx2="112"/><pair kern="-72" kpx2="251"/><pair kern="-63" kpx2="103"/><pair kern="-63" kpx2="208"/><pair kern="-44" kpx2="113"/><pair kern="-40" kpx2="181"/><pair kern="-77" kpx2="180"/><pair kern="-54" kpx2="169"/><pair kern="-21" kpx2="197"/><pair kern="-72" kpx2="38"/><pair kern="-72" kpx2="253"/><pair kern="-44" kpx2="115"/></kerning><kerning kpx1="73"><pair kern="31" kpx2="180"/><pair kern="-17" kpx2="90"/><pair kern="-72" kpx2="17"/><pair kern="-17" kpx2="235"/><pair kern="-35" kpx2="169"/><pair kern="-114" kpx2="197"/><pair kern="-17" kpx2="186"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="87"/><pair kern="-54" kpx2="16"/><pair kern="-35" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="41"><pair kern="-17" kpx2="227"/><pair kern="-54" kpx2="126"/><pair kern="-91" kpx2="107"/><pair kern="-91" kpx2="235"/><pair kern="-54" kpx2="72"/><pair kern="-91" kpx2="199"/><pair kern="-35" kpx2="123"/><pair kern="-54" kpx2="112"/><pair kern="-54" kpx2="113"/><pair kern="-17" kpx2="54"/><pair kern="-21" kpx2="180"/><pair kern="-91" kpx2="105"/><pair kern="-54" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-91" kpx2="201"/><pair kern="-72" kpx2="85"/><pair kern="-91" kpx2="106"/><pair kern="-77" kpx2="29"/><pair kern="-35" kpx2="125"/><pair kern="-54" kpx2="115"/><pair kern="-54" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-91" kpx2="68"/><pair kern="-91" kpx2="36"/><pair kern="-35" kpx2="82"/><pair kern="-91" kpx2="186"/><pair kern="-17" kpx2="55"/><pair kern="-54" kpx2="114"/><pair kern="-54" kpx2="127"/><pair kern="-91" kpx2="108"/><pair kern="-91" kpx2="98"/><pair kern="-72" kpx2="76"/><pair kern="-160" kpx2="17"/><pair kern="-54" kpx2="128"/><pair kern="-91" kpx2="173"/><pair kern="-91" kpx2="109"/><pair kern="-183" kpx2="197"/><pair kern="-91" kpx2="92"/><pair kern="-35" kpx2="121"/><pair kern="-91" kpx2="110"/><pair kern="-91" kpx2="174"/><pair kern="-17" kpx2="249"/></kerning><kerning kpx1="124"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="169"><pair kern="-17" kpx2="90"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="246"/><pair kern="-17" kpx2="235"/><pair kern="-17" kpx2="58"/><pair kern="-17" kpx2="186"/><pair kern="-54" kpx2="55"/><pair kern="-17" kpx2="251"/><pair kern="-72" kpx2="187"/><pair kern="-17" kpx2="39"/><pair kern="73" kpx2="144"/><pair kern="-17" kpx2="45"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="38"/><pair kern="-72" kpx2="60"/><pair kern="-17" kpx2="89"/><pair kern="-17" kpx2="253"/><pair kern="-54" kpx2="57"/><pair kern="-17" kpx2="37"/><pair kern="-17" kpx2="42"/><pair kern="-72" kpx2="234"/></kerning><kerning kpx1="201"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="60"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="85"><pair kern="-21" kpx2="254"/><pair kern="-21" kpx2="72"/><pair kern="-63" kpx2="16"/><pair kern="-21" kpx2="112"/><pair kern="-21" kpx2="123"/><pair kern="-17" kpx2="80"/><pair kern="-21" kpx2="113"/><pair kern="-17" kpx2="71"/><pair kern="-21" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-21" kpx2="252"/><pair kern="-21" kpx2="70"/><pair kern="-17" kpx2="85"/><pair kern="-17" kpx2="29"/><pair kern="-21" kpx2="125"/><pair kern="-21" kpx2="115"/><pair kern="-21" kpx2="111"/><pair kern="-21" kpx2="122"/><pair kern="-21" kpx2="82"/><pair kern="-17" kpx2="75"/><pair kern="-21" kpx2="114"/><pair kern="-26" kpx2="91"/><pair kern="-17" kpx2="81"/><pair kern="41" kpx2="181"/><pair kern="-91" kpx2="17"/><pair kern="-151" kpx2="197"/><pair kern="-17" kpx2="74"/><pair kern="-17" kpx2="84"/><pair kern="-21" kpx2="121"/><pair kern="-17" kpx2="247"/><pair kern="-17" kpx2="120"/></kerning><kerning kpx1="61"><pair kern="-17" kpx2="180"/><pair kern="-17" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="234"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="100"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="122"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="47"><pair kern="-17" kpx2="126"/><pair kern="-91" kpx2="235"/><pair kern="-49" kpx2="104"/><pair kern="-17" kpx2="72"/><pair kern="22" kpx2="199"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-49" kpx2="213"/><pair kern="-35" kpx2="208"/><pair kern="-132" kpx2="187"/><pair kern="-17" kpx2="113"/><pair kern="-202" kpx2="180"/><pair kern="-17" kpx2="129"/><pair kern="-17" kpx2="124"/><pair kern="22" kpx2="201"/><pair kern="-132" kpx2="60"/><pair kern="-49" kpx2="211"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="115"/><pair kern="-132" kpx2="234"/><pair kern="-17" kpx2="88"/><pair kern="-17" kpx2="122"/><pair kern="-35" kpx2="210"/><pair kern="22" kpx2="36"/><pair kern="-17" kpx2="82"/><pair kern="-91" kpx2="58"/><pair kern="-91" kpx2="186"/><pair kern="-137" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-35" kpx2="175"/><pair kern="-17" kpx2="127"/><pair kern="-35" kpx2="50"/><pair kern="-35" kpx2="209"/><pair kern="-35" kpx2="103"/><pair kern="22" kpx2="98"/><pair kern="-262" kpx2="181"/><pair kern="-17" kpx2="128"/><pair kern="22" kpx2="173"/><pair kern="-49" kpx2="212"/><pair kern="-91" kpx2="92"/><pair kern="-17" kpx2="121"/><pair kern="-109" kpx2="57"/><pair kern="22" kpx2="174"/><pair kern="-49" kpx2="56"/></kerning><kerning kpx1="210"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="58"><pair kern="-35" kpx2="126"/><pair kern="-63" kpx2="107"/><pair kern="-17" kpx2="235"/><pair kern="-58" kpx2="72"/><pair kern="-54" kpx2="199"/><pair kern="-40" kpx2="16"/><pair kern="-58" kpx2="112"/><pair kern="-58" kpx2="123"/><pair kern="-58" kpx2="113"/><pair kern="-17" kpx2="180"/><pair kern="-63" kpx2="105"/><pair kern="-35" kpx2="129"/><pair kern="-58" kpx2="124"/><pair kern="-54" kpx2="169"/><pair kern="-54" kpx2="201"/><pair kern="-44" kpx2="85"/><pair kern="-63" kpx2="106"/><pair kern="-58" kpx2="29"/><pair kern="-58" kpx2="125"/><pair kern="-17" kpx2="170"/><pair kern="-58" kpx2="115"/><pair kern="-35" kpx2="88"/><pair kern="-58" kpx2="122"/><pair kern="-63" kpx2="68"/><pair kern="-54" kpx2="36"/><pair kern="-58" kpx2="82"/><pair kern="-17" kpx2="186"/><pair kern="-58" kpx2="114"/><pair kern="-35" kpx2="127"/><pair kern="-63" kpx2="108"/><pair kern="-54" kpx2="98"/><pair kern="-21" kpx2="76"/><pair kern="-114" kpx2="17"/><pair kern="-35" kpx2="128"/><pair kern="-54" kpx2="173"/><pair kern="-63" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-17" kpx2="92"/><pair kern="-58" kpx2="121"/><pair kern="-63" kpx2="110"/><pair kern="-54" kpx2="174"/></kerning><kerning kpx1="82"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="186"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="175"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="209"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="103"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="81"><pair kern="-72" kpx2="180"/><pair kern="-44" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="98"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="212"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="229"><pair kern="-17" kpx2="180"/><pair kern="-17" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="38"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="121"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="57"><pair kern="-67" kpx2="126"/><pair kern="-77" kpx2="107"/><pair kern="-26" kpx2="235"/><pair kern="-77" kpx2="72"/><pair kern="-63" kpx2="199"/><pair kern="-58" kpx2="16"/><pair kern="-77" kpx2="123"/><pair kern="-77" kpx2="112"/><pair kern="-17" kpx2="208"/><pair kern="-77" kpx2="113"/><pair kern="-77" kpx2="105"/><pair kern="-67" kpx2="129"/><pair kern="-77" kpx2="124"/><pair kern="-86" kpx2="169"/><pair kern="-63" kpx2="201"/><pair kern="-77" kpx2="106"/><pair kern="-81" kpx2="29"/><pair kern="-77" kpx2="125"/><pair kern="-54" kpx2="170"/><pair kern="-77" kpx2="115"/><pair kern="-67" kpx2="88"/><pair kern="-77" kpx2="122"/><pair kern="-77" kpx2="68"/><pair kern="-17" kpx2="210"/><pair kern="-63" kpx2="36"/><pair kern="-77" kpx2="82"/><pair kern="-26" kpx2="186"/><pair kern="-77" kpx2="114"/><pair kern="-17" kpx2="175"/><pair kern="-67" kpx2="127"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-77" kpx2="108"/><pair kern="-63" kpx2="98"/><pair kern="-21" kpx2="76"/><pair kern="-128" kpx2="17"/><pair kern="-67" kpx2="128"/><pair kern="-63" kpx2="173"/><pair kern="-77" kpx2="109"/><pair kern="-137" kpx2="197"/><pair kern="-26" kpx2="92"/><pair kern="-77" kpx2="121"/><pair kern="-77" kpx2="110"/><pair kern="-63" kpx2="174"/></kerning><kerning kpx1="37"><pair kern="-17" kpx2="227"/><pair kern="-17" kpx2="246"/><pair kern="-17" kpx2="251"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-17" kpx2="54"/><pair kern="-54" kpx2="180"/><pair kern="-30" kpx2="169"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="170"/><pair kern="-54" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="210"/><pair kern="-35" kpx2="58"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-54" kpx2="181"/><pair kern="-40" kpx2="197"/><pair kern="-17" kpx2="38"/><pair kern="-30" kpx2="57"/><pair kern="-17" kpx2="249"/></kerning><kerning kpx1="120"><pair kern="-72" kpx2="180"/><pair kern="-44" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="249"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="227"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="51"><pair kern="-17" kpx2="126"/><pair kern="-44" kpx2="107"/><pair kern="-35" kpx2="72"/><pair kern="-63" kpx2="199"/><pair kern="-21" kpx2="16"/><pair kern="-35" kpx2="123"/><pair kern="-35" kpx2="112"/><pair kern="-21" kpx2="187"/><pair kern="-35" kpx2="113"/><pair kern="-17" kpx2="86"/><pair kern="18" kpx2="180"/><pair kern="-44" kpx2="105"/><pair kern="-17" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-17" kpx2="169"/><pair kern="-63" kpx2="201"/><pair kern="-17" kpx2="85"/><pair kern="-21" kpx2="60"/><pair kern="-44" kpx2="106"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="115"/><pair kern="-21" kpx2="234"/><pair kern="-17" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-44" kpx2="68"/><pair kern="-63" kpx2="36"/><pair kern="-35" kpx2="82"/><pair kern="-35" kpx2="114"/><pair kern="-17" kpx2="250"/><pair kern="-17" kpx2="127"/><pair kern="-44" kpx2="108"/><pair kern="-63" kpx2="98"/><pair kern="-17" kpx2="81"/><pair kern="-21" kpx2="76"/><pair kern="18" kpx2="181"/><pair kern="-155" kpx2="17"/><pair kern="-17" kpx2="128"/><pair kern="-63" kpx2="173"/><pair kern="-44" kpx2="109"/><pair kern="-160" kpx2="197"/><pair kern="-35" kpx2="121"/><pair kern="-17" kpx2="228"/><pair kern="-44" kpx2="110"/><pair kern="-63" kpx2="174"/><pair kern="-17" kpx2="120"/></kerning><kerning kpx1="104"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="72"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="199"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="54"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="180"><pair kern="-35" kpx2="235"/><pair kern="-35" kpx2="246"/><pair kern="-30" kpx2="43"/><pair kern="-72" kpx2="123"/><pair kern="-35" kpx2="251"/><pair kern="-35" kpx2="208"/><pair kern="-188" kpx2="144"/><pair kern="-58" kpx2="59"/><pair kern="-35" kpx2="73"/><pair kern="-30" kpx2="41"/><pair kern="-72" kpx2="124"/><pair kern="-54" kpx2="85"/><pair kern="-128" kpx2="201"/><pair kern="-17" kpx2="61"/><pair kern="-35" kpx2="100"/><pair kern="-72" kpx2="122"/><pair kern="-30" kpx2="47"/><pair kern="-35" kpx2="210"/><pair kern="-72" kpx2="82"/><pair kern="-35" kpx2="186"/><pair kern="-35" kpx2="175"/><pair kern="-35" kpx2="209"/><pair kern="-35" kpx2="103"/><pair kern="-128" kpx2="98"/><pair kern="-54" kpx2="81"/><pair kern="-17" kpx2="229"/><pair kern="-35" kpx2="38"/><pair kern="-72" kpx2="121"/><pair kern="-30" kpx2="37"/><pair kern="-54" kpx2="120"/><pair kern="-30" kpx2="51"/><pair kern="-128" kpx2="199"/><pair kern="-30" kpx2="53"/><pair kern="-30" kpx2="137"/><pair kern="-35" kpx2="233"/><pair kern="-35" kpx2="253"/><pair kern="-35" kpx2="52"/><pair kern="-72" kpx2="125"/><pair kern="-35" kpx2="42"/><pair kern="-35" kpx2="90"/><pair kern="-128" kpx2="36"/><pair kern="-35" kpx2="50"/><pair kern="-30" kpx2="39"/><pair kern="-30" kpx2="236"/><pair kern="-30" kpx2="45"/><pair kern="-128" kpx2="173"/><pair kern="-35" kpx2="92"/><pair kern="-35" kpx2="89"/><pair kern="-30" kpx2="46"/><pair kern="-128" kpx2="174"/></kerning><kerning kpx1="53"><pair kern="-21" kpx2="107"/><pair kern="-54" kpx2="235"/><pair kern="-40" kpx2="16"/><pair kern="-44" kpx2="112"/><pair kern="-44" kpx2="123"/><pair kern="-49" kpx2="251"/><pair kern="-44" kpx2="113"/><pair kern="-63" kpx2="187"/><pair kern="-44" kpx2="129"/><pair kern="-44" kpx2="124"/><pair kern="-54" kpx2="169"/><pair kern="-63" kpx2="60"/><pair kern="-40" kpx2="201"/><pair kern="-21" kpx2="106"/><pair kern="-30" kpx2="29"/><pair kern="-63" kpx2="234"/><pair kern="-49" kpx2="100"/><pair kern="-44" kpx2="122"/><pair kern="-21" kpx2="68"/><pair kern="-40" kpx2="58"/><pair kern="-44" kpx2="82"/><pair kern="-54" kpx2="186"/><pair kern="-40" kpx2="98"/><pair kern="-63" kpx2="181"/><pair kern="-35" kpx2="17"/><pair kern="-49" kpx2="38"/><pair kern="-44" kpx2="121"/><pair kern="-54" kpx2="57"/><pair kern="-44" kpx2="126"/><pair kern="-44" kpx2="72"/><pair kern="-40" kpx2="199"/><pair kern="-72" kpx2="180"/><pair kern="-21" kpx2="105"/><pair kern="-49" kpx2="253"/><pair kern="-44" kpx2="125"/><pair kern="-44" kpx2="115"/><pair kern="-17" kpx2="170"/><pair kern="-44" kpx2="88"/><pair kern="-40" kpx2="36"/><pair kern="-44" kpx2="114"/><pair kern="-72" kpx2="55"/><pair kern="-44" kpx2="127"/><pair kern="-21" kpx2="108"/><pair kern="-44" kpx2="128"/><pair kern="-40" kpx2="173"/><pair kern="-21" kpx2="109"/><pair kern="-54" kpx2="92"/><pair kern="-17" kpx2="197"/><pair kern="-21" kpx2="110"/><pair kern="-40" kpx2="174"/></kerning><kerning kpx1="137"><pair kern="-54" kpx2="180"/><pair kern="-40" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="233"><pair kern="-44" kpx2="180"/><pair kern="-35" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="253"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="211"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="78"><pair kern="-17" kpx2="107"/><pair kern="-30" kpx2="126"/><pair kern="-35" kpx2="235"/><pair kern="-35" kpx2="72"/><pair kern="-35" kpx2="112"/><pair kern="-35" kpx2="123"/><pair kern="-35" kpx2="113"/><pair kern="-17" kpx2="105"/><pair kern="-30" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-17" kpx2="106"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="115"/><pair kern="-30" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-17" kpx2="68"/><pair kern="-35" kpx2="82"/><pair kern="-35" kpx2="114"/><pair kern="-35" kpx2="186"/><pair kern="-30" kpx2="127"/><pair kern="-17" kpx2="108"/><pair kern="-30" kpx2="128"/><pair kern="-17" kpx2="109"/><pair kern="-35" kpx2="92"/><pair kern="-35" kpx2="121"/><pair kern="-17" kpx2="110"/></kerning><kerning kpx1="52"><pair kern="-21" kpx2="180"/><pair kern="-63" kpx2="197"/><pair kern="27" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="125"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="42"><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="169"/><pair kern="-26" kpx2="197"/><pair kern="-35" kpx2="55"/><pair kern="-49" kpx2="60"/><pair kern="-49" kpx2="187"/><pair kern="-21" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-49" kpx2="234"/></kerning><kerning kpx1="170"><pair kern="-17" kpx2="235"/><pair kern="-35" kpx2="199"/><pair kern="-17" kpx2="251"/><pair kern="-109" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-54" kpx2="59"/><pair kern="-109" kpx2="60"/><pair kern="-35" kpx2="201"/><pair kern="-17" kpx2="253"/><pair kern="-109" kpx2="234"/><pair kern="-17" kpx2="90"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="210"/><pair kern="-35" kpx2="36"/><pair kern="-54" kpx2="58"/><pair kern="-91" kpx2="55"/><pair kern="-17" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-17" kpx2="39"/><pair kern="-35" kpx2="98"/><pair kern="-17" kpx2="45"/><pair kern="-35" kpx2="173"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="89"/><pair kern="-86" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-35" kpx2="174"/></kerning><kerning kpx1="115"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="90"><pair kern="-91" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-104" kpx2="197"/><pair kern="-54" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="36"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="55"><pair kern="-165" kpx2="107"/><pair kern="-155" kpx2="235"/><pair kern="-91" kpx2="16"/><pair kern="-169" kpx2="112"/><pair kern="-169" kpx2="123"/><pair kern="-58" kpx2="251"/><pair kern="-169" kpx2="113"/><pair kern="-165" kpx2="86"/><pair kern="-151" kpx2="129"/><pair kern="-169" kpx2="124"/><pair kern="-91" kpx2="169"/><pair kern="-169" kpx2="252"/><pair kern="-169" kpx2="70"/><pair kern="-146" kpx2="85"/><pair kern="-77" kpx2="201"/><pair kern="-165" kpx2="106"/><pair kern="-109" kpx2="29"/><pair kern="-58" kpx2="100"/><pair kern="-169" kpx2="122"/><pair kern="-165" kpx2="68"/><pair kern="-169" kpx2="82"/><pair kern="-155" kpx2="186"/><pair kern="-165" kpx2="250"/><pair kern="-77" kpx2="98"/><pair kern="-21" kpx2="181"/><pair kern="-118" kpx2="17"/><pair kern="-58" kpx2="38"/><pair kern="-169" kpx2="121"/><pair kern="-165" kpx2="228"/><pair kern="-169" kpx2="254"/><pair kern="-151" kpx2="126"/><pair kern="-169" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-165" kpx2="105"/><pair kern="-58" kpx2="253"/><pair kern="-169" kpx2="125"/><pair kern="-169" kpx2="115"/><pair kern="-54" kpx2="170"/><pair kern="-151" kpx2="88"/><pair kern="-169" kpx2="111"/><pair kern="-165" kpx2="90"/><pair kern="-77" kpx2="36"/><pair kern="-17" kpx2="55"/><pair kern="-169" kpx2="114"/><pair kern="-151" kpx2="127"/><pair kern="-165" kpx2="108"/><pair kern="-30" kpx2="76"/><pair kern="-151" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-165" kpx2="109"/><pair kern="-155" kpx2="92"/><pair kern="-128" kpx2="197"/><pair kern="-165" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="114"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="50"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="91"><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="111"/><pair kern="-30" kpx2="122"/><pair kern="-30" kpx2="82"/><pair kern="-30" kpx2="114"/><pair kern="-30" kpx2="72"/><pair kern="-30" kpx2="112"/><pair kern="-30" kpx2="123"/><pair kern="-30" kpx2="113"/><pair kern="-30" kpx2="124"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-30" kpx2="121"/><pair kern="-30" kpx2="125"/><pair kern="-30" kpx2="115"/></kerning><kerning kpx1="39"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="-17" kpx2="98"/><pair kern="-54" kpx2="187"/><pair kern="-26" kpx2="181"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-17" kpx2="170"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="236"><pair kern="-17" kpx2="180"/><pair kern="-72" kpx2="17"/><pair kern="-91" kpx2="197"/><pair kern="-35" kpx2="29"/></kerning><kerning kpx1="45"><pair kern="-35" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="169"/><pair kern="-54" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-17" kpx2="199"/><pair kern="-35" kpx2="16"/><pair kern="-17" kpx2="174"/><pair kern="-17" kpx2="98"/><pair kern="-30" kpx2="181"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="173"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="197"><pair kern="-35" kpx2="246"/><pair kern="-54" kpx2="235"/><pair kern="-35" kpx2="43"/><pair kern="-35" kpx2="123"/><pair kern="-54" kpx2="251"/><pair kern="-183" kpx2="187"/><pair kern="-54" kpx2="208"/><pair kern="18" kpx2="144"/><pair kern="-35" kpx2="59"/><pair kern="-17" kpx2="73"/><pair kern="-35" kpx2="41"/><pair kern="-35" kpx2="124"/><pair kern="-35" kpx2="85"/><pair kern="-183" kpx2="60"/><pair kern="18" kpx2="201"/><pair kern="-183" kpx2="234"/><pair kern="-54" kpx2="100"/><pair kern="-35" kpx2="122"/><pair kern="-35" kpx2="47"/><pair kern="-54" kpx2="210"/><pair kern="-35" kpx2="82"/><pair kern="-123" kpx2="58"/><pair kern="-54" kpx2="186"/><pair kern="-54" kpx2="175"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-35" kpx2="81"/><pair kern="18" kpx2="98"/><pair kern="-54" kpx2="38"/><pair kern="-35" kpx2="121"/><pair kern="-183" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-35" kpx2="120"/><pair kern="-35" kpx2="51"/><pair kern="18" kpx2="199"/><pair kern="-35" kpx2="53"/><pair kern="-35" kpx2="137"/><pair kern="-35" kpx2="233"/><pair kern="-54" kpx2="253"/><pair kern="-54" kpx2="52"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="42"/><pair kern="-95" kpx2="90"/><pair kern="18" kpx2="36"/><pair kern="-137" kpx2="55"/><pair kern="-54" kpx2="50"/><pair kern="-35" kpx2="39"/><pair kern="-35" kpx2="236"/><pair kern="22" kpx2="45"/><pair kern="18" kpx2="173"/><pair kern="-54" kpx2="92"/><pair kern="-114" kpx2="89"/><pair kern="-35" kpx2="46"/><pair kern="18" kpx2="174"/></kerning><kerning kpx1="92"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="89"><pair kern="-77" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-132" kpx2="197"/><pair kern="-26" kpx2="16"/><pair kern="-54" kpx2="29"/><pair kern="-17" kpx2="181"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="46"><pair kern="-17" kpx2="107"/><pair kern="-72" kpx2="235"/><pair kern="-104" kpx2="16"/><pair kern="-49" kpx2="112"/><pair kern="-49" kpx2="123"/><pair kern="-54" kpx2="251"/><pair kern="-26" kpx2="213"/><pair kern="-49" kpx2="113"/><pair kern="-35" kpx2="187"/><pair kern="-54" kpx2="208"/><pair kern="-49" kpx2="129"/><pair kern="-49" kpx2="124"/><pair kern="-63" kpx2="169"/><pair kern="-35" kpx2="60"/><pair kern="-17" kpx2="201"/><pair kern="-17" kpx2="106"/><pair kern="-35" kpx2="234"/><pair kern="-54" kpx2="100"/><pair kern="-49" kpx2="122"/><pair kern="-17" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-35" kpx2="58"/><pair kern="-49" kpx2="82"/><pair kern="-72" kpx2="186"/><pair kern="-54" kpx2="175"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-17" kpx2="98"/><pair kern="-30" kpx2="181"/><pair kern="-26" kpx2="212"/><pair kern="-54" kpx2="38"/><pair kern="-49" kpx2="121"/><pair kern="-49" kpx2="126"/><pair kern="-26" kpx2="104"/><pair kern="-49" kpx2="72"/><pair kern="-17" kpx2="199"/><pair kern="-30" kpx2="180"/><pair kern="-17" kpx2="105"/><pair kern="-54" kpx2="253"/><pair kern="-26" kpx2="211"/><pair kern="-49" kpx2="125"/><pair kern="-49" kpx2="115"/><pair kern="-49" kpx2="88"/><pair kern="-17" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-49" kpx2="114"/><pair kern="-54" kpx2="50"/><pair kern="-49" kpx2="127"/><pair kern="-17" kpx2="108"/><pair kern="-49" kpx2="128"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="109"/><pair kern="-72" kpx2="92"/><pair kern="-17" kpx2="110"/><pair kern="-17" kpx2="174"/><pair kern="-26" kpx2="56"/></kerning><kerning kpx1="174"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="56"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning></font-metrics> \ No newline at end of file | ||
diff --git a/bitbake/doc/template/VeraMoBd.xml b/bitbake/doc/template/VeraMoBd.xml deleted file mode 100644 index 9b33107a44..0000000000 --- a/bitbake/doc/template/VeraMoBd.xml +++ /dev/null | |||
@@ -1 +0,0 @@ | |||
1 | <?xml version="1.0" encoding="UTF-8"?><font-metrics metrics-version="2" type="TYPE0"><font-name>BitstreamVeraSansMono-Bold</font-name><full-name>Bitstream Vera Sans Mono Bold</full-name><family-name>Bitstream Vera Sans Mono</family-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>759</ascender><descender>-240</descender><bbox><left>-19</left><bottom>-235</bottom><right>605</right><top>928</top></bbox><flags>34</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="602"/><wx w="0"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/></cid-widths></multibyte-extras></font-metrics> \ No newline at end of file | ||
diff --git a/bitbake/doc/template/VeraMono.xml b/bitbake/doc/template/VeraMono.xml deleted file mode 100644 index 3a0a86659c..0000000000 --- a/bitbake/doc/template/VeraMono.xml +++ /dev/null | |||
@@ -1 +0,0 @@ | |||
1 | <?xml version="1.0" encoding="UTF-8"?><font-metrics metrics-version="2" type="TYPE0"><font-name>BitstreamVeraSansMono-Roman</font-name><full-name>Bitstream Vera Sans Mono</full-name><family-name>Bitstream Vera Sans Mono</family-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>759</ascender><descender>-240</descender><bbox><left>-4</left><bottom>-235</bottom><right>605</right><top>928</top></bbox><flags>34</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="602"/><wx w="0"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/></cid-widths></multibyte-extras></font-metrics> \ No newline at end of file | ||
diff --git a/bitbake/doc/template/component.title.xsl b/bitbake/doc/template/component.title.xsl deleted file mode 100644 index faef043268..0000000000 --- a/bitbake/doc/template/component.title.xsl +++ /dev/null | |||
@@ -1,39 +0,0 @@ | |||
1 | <xsl:stylesheet version="1.0" | ||
2 | xmlns:xsl="http://www.w3.org/1999/XSL/Transform" | ||
3 | xmlns:d="http://docbook.org/ns/docbook" | ||
4 | xmlns="http://www.w3.org/1999/xhtml" | ||
5 | exclude-result-prefixes="d"> | ||
6 | |||
7 | <xsl:template name="component.title"> | ||
8 | <xsl:param name="node" select="."/> | ||
9 | |||
10 | <xsl:variable name="level"> | ||
11 | <xsl:choose> | ||
12 | <xsl:when test="ancestor::d:section"> | ||
13 | <xsl:value-of select="count(ancestor::d:section)+1"/> | ||
14 | </xsl:when> | ||
15 | <xsl:when test="ancestor::d:sect5">6</xsl:when> | ||
16 | <xsl:when test="ancestor::d:sect4">5</xsl:when> | ||
17 | <xsl:when test="ancestor::d:sect3">4</xsl:when> | ||
18 | <xsl:when test="ancestor::d:sect2">3</xsl:when> | ||
19 | <xsl:when test="ancestor::d:sect1">2</xsl:when> | ||
20 | <xsl:otherwise>1</xsl:otherwise> | ||
21 | </xsl:choose> | ||
22 | </xsl:variable> | ||
23 | <xsl:element name="h{$level+1}" namespace="http://www.w3.org/1999/xhtml"> | ||
24 | <xsl:attribute name="class">title</xsl:attribute> | ||
25 | <xsl:if test="$generate.id.attributes = 0"> | ||
26 | <xsl:call-template name="anchor"> | ||
27 | <xsl:with-param name="node" select="$node"/> | ||
28 | <xsl:with-param name="conditional" select="0"/> | ||
29 | </xsl:call-template> | ||
30 | </xsl:if> | ||
31 | <xsl:apply-templates select="$node" mode="object.title.markup"> | ||
32 | <xsl:with-param name="allow-anchors" select="1"/> | ||
33 | </xsl:apply-templates> | ||
34 | <xsl:call-template name="permalink"> | ||
35 | <xsl:with-param name="node" select="$node"/> | ||
36 | </xsl:call-template> | ||
37 | </xsl:element> | ||
38 | </xsl:template> | ||
39 | </xsl:stylesheet> | ||
diff --git a/bitbake/doc/template/db-pdf.xsl b/bitbake/doc/template/db-pdf.xsl deleted file mode 100644 index 3dd065a57e..0000000000 --- a/bitbake/doc/template/db-pdf.xsl +++ /dev/null | |||
@@ -1,64 +0,0 @@ | |||
1 | <?xml version='1.0'?> | ||
2 | <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"> | ||
3 | |||
4 | <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl" /> | ||
5 | |||
6 | <!-- check project-plan.sh for how this is generated, needed to tweak | ||
7 | the cover page | ||
8 | --> | ||
9 | <xsl:include href="/tmp/titlepage.xsl"/> | ||
10 | |||
11 | <!-- To force a page break in document, i.e per section add a | ||
12 | <?hard-pagebreak?> tag. | ||
13 | --> | ||
14 | <xsl:template match="processing-instruction('hard-pagebreak')"> | ||
15 | <fo:block break-before='page' /> | ||
16 | </xsl:template> | ||
17 | |||
18 | <!--Fix for defualt indent getting TOC all wierd.. | ||
19 | See http://sources.redhat.com/ml/docbook-apps/2005-q1/msg00455.html | ||
20 | FIXME: must be a better fix | ||
21 | --> | ||
22 | <xsl:param name="body.start.indent" select="'0'"/> | ||
23 | <!--<xsl:param name="title.margin.left" select="'0'"/>--> | ||
24 | |||
25 | <!-- stop long-ish header titles getting wrapped --> | ||
26 | <xsl:param name="header.column.widths">1 10 1</xsl:param> | ||
27 | |||
28 | <!-- customise headers and footers a little --> | ||
29 | |||
30 | <xsl:template name="head.sep.rule"> | ||
31 | <xsl:if test="$header.rule != 0"> | ||
32 | <xsl:attribute name="border-bottom-width">0.5pt</xsl:attribute> | ||
33 | <xsl:attribute name="border-bottom-style">solid</xsl:attribute> | ||
34 | <xsl:attribute name="border-bottom-color">#cccccc</xsl:attribute> | ||
35 | </xsl:if> | ||
36 | </xsl:template> | ||
37 | |||
38 | <xsl:template name="foot.sep.rule"> | ||
39 | <xsl:if test="$footer.rule != 0"> | ||
40 | <xsl:attribute name="border-top-width">0.5pt</xsl:attribute> | ||
41 | <xsl:attribute name="border-top-style">solid</xsl:attribute> | ||
42 | <xsl:attribute name="border-top-color">#cccccc</xsl:attribute> | ||
43 | </xsl:if> | ||
44 | </xsl:template> | ||
45 | |||
46 | <xsl:attribute-set name="header.content.properties"> | ||
47 | <xsl:attribute name="color">#cccccc</xsl:attribute> | ||
48 | </xsl:attribute-set> | ||
49 | |||
50 | <xsl:attribute-set name="footer.content.properties"> | ||
51 | <xsl:attribute name="color">#cccccc</xsl:attribute> | ||
52 | </xsl:attribute-set> | ||
53 | |||
54 | |||
55 | <!-- general settings --> | ||
56 | |||
57 | <xsl:param name="fop1.extensions" select="1"></xsl:param> | ||
58 | <xsl:param name="paper.type" select="'A4'"></xsl:param> | ||
59 | <xsl:param name="section.autolabel" select="1"></xsl:param> | ||
60 | <xsl:param name="body.font.family" select="'verasans'"></xsl:param> | ||
61 | <xsl:param name="title.font.family" select="'verasans'"></xsl:param> | ||
62 | <xsl:param name="monospace.font.family" select="'veramono'"></xsl:param> | ||
63 | |||
64 | </xsl:stylesheet> | ||
diff --git a/bitbake/doc/template/division.title.xsl b/bitbake/doc/template/division.title.xsl deleted file mode 100644 index 9c843bc7c4..0000000000 --- a/bitbake/doc/template/division.title.xsl +++ /dev/null | |||
@@ -1,25 +0,0 @@ | |||
1 | <xsl:stylesheet version="1.0" | ||
2 | xmlns:xsl="http://www.w3.org/1999/XSL/Transform" | ||
3 | xmlns:d="http://docbook.org/ns/docbook" | ||
4 | xmlns="http://www.w3.org/1999/xhtml" | ||
5 | exclude-result-prefixes="d"> | ||
6 | |||
7 | <xsl:template name="division.title"> | ||
8 | <xsl:param name="node" select="."/> | ||
9 | |||
10 | <h1> | ||
11 | <xsl:attribute name="class">title</xsl:attribute> | ||
12 | <xsl:call-template name="anchor"> | ||
13 | <xsl:with-param name="node" select="$node"/> | ||
14 | <xsl:with-param name="conditional" select="0"/> | ||
15 | </xsl:call-template> | ||
16 | <xsl:apply-templates select="$node" mode="object.title.markup"> | ||
17 | <xsl:with-param name="allow-anchors" select="1"/> | ||
18 | </xsl:apply-templates> | ||
19 | <xsl:call-template name="permalink"> | ||
20 | <xsl:with-param name="node" select="$node"/> | ||
21 | </xsl:call-template> | ||
22 | </h1> | ||
23 | </xsl:template> | ||
24 | </xsl:stylesheet> | ||
25 | |||
diff --git a/bitbake/doc/template/fop-config.xml b/bitbake/doc/template/fop-config.xml deleted file mode 100644 index 09cc5ca0f5..0000000000 --- a/bitbake/doc/template/fop-config.xml +++ /dev/null | |||
@@ -1,58 +0,0 @@ | |||
1 | <fop version="1.0"> | ||
2 | |||
3 | <!-- Strict user configuration --> | ||
4 | <strict-configuration>true</strict-configuration> | ||
5 | |||
6 | <!-- Strict FO validation --> | ||
7 | <strict-validation>true</strict-validation> | ||
8 | |||
9 | <!-- | ||
10 | Set the baseDir so common/openedhand.svg references in plans still | ||
11 | work ok. Note, relative file references to current dir should still work. | ||
12 | --> | ||
13 | <base>../template</base> | ||
14 | <font-base>../template</font-base> | ||
15 | |||
16 | <!-- Source resolution in dpi (dots/pixels per inch) for determining the | ||
17 | size of pixels in SVG and bitmap images, default: 72dpi --> | ||
18 | <!-- <source-resolution>72</source-resolution> --> | ||
19 | <!-- Target resolution in dpi (dots/pixels per inch) for specifying the | ||
20 | target resolution for generated bitmaps, default: 72dpi --> | ||
21 | <!-- <target-resolution>72</target-resolution> --> | ||
22 | |||
23 | <!-- default page-height and page-width, in case | ||
24 | value is specified as auto --> | ||
25 | <default-page-settings height="11in" width="8.26in"/> | ||
26 | |||
27 | <!-- <use-cache>false</use-cache> --> | ||
28 | |||
29 | <renderers> | ||
30 | <renderer mime="application/pdf"> | ||
31 | <fonts> | ||
32 | <font metrics-file="VeraMono.xml" | ||
33 | kerning="yes" | ||
34 | embed-url="VeraMono.ttf"> | ||
35 | <font-triplet name="veramono" style="normal" weight="normal"/> | ||
36 | </font> | ||
37 | |||
38 | <font metrics-file="VeraMoBd.xml" | ||
39 | kerning="yes" | ||
40 | embed-url="VeraMoBd.ttf"> | ||
41 | <font-triplet name="veramono" style="normal" weight="bold"/> | ||
42 | </font> | ||
43 | |||
44 | <font metrics-file="Vera.xml" | ||
45 | kerning="yes" | ||
46 | embed-url="Vera.ttf"> | ||
47 | <font-triplet name="verasans" style="normal" weight="normal"/> | ||
48 | <font-triplet name="verasans" style="normal" weight="bold"/> | ||
49 | <font-triplet name="verasans" style="italic" weight="normal"/> | ||
50 | <font-triplet name="verasans" style="italic" weight="bold"/> | ||
51 | </font> | ||
52 | |||
53 | <auto-detect/> | ||
54 | </fonts> | ||
55 | </renderer> | ||
56 | </renderers> | ||
57 | </fop> | ||
58 | |||
diff --git a/bitbake/doc/template/formal.object.heading.xsl b/bitbake/doc/template/formal.object.heading.xsl deleted file mode 100644 index 4f3900d165..0000000000 --- a/bitbake/doc/template/formal.object.heading.xsl +++ /dev/null | |||
@@ -1,21 +0,0 @@ | |||
1 | <xsl:stylesheet version="1.0" | ||
2 | xmlns:xsl="http://www.w3.org/1999/XSL/Transform" | ||
3 | xmlns:d="http://docbook.org/ns/docbook" | ||
4 | xmlns="http://www.w3.org/1999/xhtml" | ||
5 | exclude-result-prefixes="d"> | ||
6 | |||
7 | <xsl:template name="formal.object.heading"> | ||
8 | <xsl:param name="object" select="."/> | ||
9 | <xsl:param name="title"> | ||
10 | <xsl:apply-templates select="$object" mode="object.title.markup"> | ||
11 | <xsl:with-param name="allow-anchors" select="1"/> | ||
12 | </xsl:apply-templates> | ||
13 | </xsl:param> | ||
14 | <p class="title"> | ||
15 | <b><xsl:copy-of select="$title"/></b> | ||
16 | <xsl:call-template name="permalink"> | ||
17 | <xsl:with-param name="node" select="$object"/> | ||
18 | </xsl:call-template> | ||
19 | </p> | ||
20 | </xsl:template> | ||
21 | </xsl:stylesheet> \ No newline at end of file | ||
diff --git a/bitbake/doc/template/gloss-permalinks.xsl b/bitbake/doc/template/gloss-permalinks.xsl deleted file mode 100644 index 6bf58116f6..0000000000 --- a/bitbake/doc/template/gloss-permalinks.xsl +++ /dev/null | |||
@@ -1,14 +0,0 @@ | |||
1 | <xsl:stylesheet version="1.0" | ||
2 | xmlns:xsl="http://www.w3.org/1999/XSL/Transform" | ||
3 | xmlns:d="http://docbook.org/ns/docbook" | ||
4 | xmlns="http://www.w3.org/1999/xhtml"> | ||
5 | |||
6 | <xsl:template match="glossentry/glossterm"> | ||
7 | <xsl:apply-imports/> | ||
8 | <xsl:if test="$generate.permalink != 0"> | ||
9 | <xsl:call-template name="permalink"> | ||
10 | <xsl:with-param name="node" select=".."/> | ||
11 | </xsl:call-template> | ||
12 | </xsl:if> | ||
13 | </xsl:template> | ||
14 | </xsl:stylesheet> | ||
diff --git a/bitbake/doc/template/permalinks.xsl b/bitbake/doc/template/permalinks.xsl deleted file mode 100644 index d2a1c14524..0000000000 --- a/bitbake/doc/template/permalinks.xsl +++ /dev/null | |||
@@ -1,25 +0,0 @@ | |||
1 | <?xml version="1.0" encoding="UTF-8"?> | ||
2 | <xsl:stylesheet version="1.0" | ||
3 | xmlns="http://www.w3.org/1999/xhtml" | ||
4 | xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> | ||
5 | |||
6 | <xsl:param name="generate.permalink" select="1"/> | ||
7 | <xsl:param name="permalink.text">¶</xsl:param> | ||
8 | |||
9 | <xsl:template name="permalink"> | ||
10 | <xsl:param name="node"/> | ||
11 | |||
12 | <xsl:if test="$generate.permalink != '0'"> | ||
13 | <span class="permalink"> | ||
14 | <a alt="Permalink" title="Permalink"> | ||
15 | <xsl:attribute name="href"> | ||
16 | <xsl:call-template name="href.target"> | ||
17 | <xsl:with-param name="object" select="$node"/> | ||
18 | </xsl:call-template> | ||
19 | </xsl:attribute> | ||
20 | <xsl:copy-of select="$permalink.text"/> | ||
21 | </a> | ||
22 | </span> | ||
23 | </xsl:if> | ||
24 | </xsl:template> | ||
25 | </xsl:stylesheet> | ||
diff --git a/bitbake/doc/template/section.title.xsl b/bitbake/doc/template/section.title.xsl deleted file mode 100644 index 5c6ff9a96e..0000000000 --- a/bitbake/doc/template/section.title.xsl +++ /dev/null | |||
@@ -1,55 +0,0 @@ | |||
1 | <xsl:stylesheet version="1.0" | ||
2 | xmlns:xsl="http://www.w3.org/1999/XSL/Transform" | ||
3 | xmlns:d="http://docbook.org/ns/docbook" | ||
4 | xmlns="http://www.w3.org/1999/xhtml" exclude-result-prefixes="d"> | ||
5 | |||
6 | <xsl:template name="section.title"> | ||
7 | <xsl:variable name="section" | ||
8 | select="(ancestor::section | | ||
9 | ancestor::simplesect| | ||
10 | ancestor::sect1| | ||
11 | ancestor::sect2| | ||
12 | ancestor::sect3| | ||
13 | ancestor::sect4| | ||
14 | ancestor::sect5)[last()]"/> | ||
15 | |||
16 | <xsl:variable name="renderas"> | ||
17 | <xsl:choose> | ||
18 | <xsl:when test="$section/@renderas = 'sect1'">1</xsl:when> | ||
19 | <xsl:when test="$section/@renderas = 'sect2'">2</xsl:when> | ||
20 | <xsl:when test="$section/@renderas = 'sect3'">3</xsl:when> | ||
21 | <xsl:when test="$section/@renderas = 'sect4'">4</xsl:when> | ||
22 | <xsl:when test="$section/@renderas = 'sect5'">5</xsl:when> | ||
23 | <xsl:otherwise><xsl:value-of select="''"/></xsl:otherwise> | ||
24 | </xsl:choose> | ||
25 | </xsl:variable> | ||
26 | |||
27 | <xsl:variable name="level"> | ||
28 | <xsl:choose> | ||
29 | <xsl:when test="$renderas != ''"> | ||
30 | <xsl:value-of select="$renderas"/> | ||
31 | </xsl:when> | ||
32 | <xsl:otherwise> | ||
33 | <xsl:call-template name="section.level"> | ||
34 | <xsl:with-param name="node" select="$section"/> | ||
35 | </xsl:call-template> | ||
36 | </xsl:otherwise> | ||
37 | </xsl:choose> | ||
38 | </xsl:variable> | ||
39 | |||
40 | <xsl:call-template name="section.heading"> | ||
41 | <xsl:with-param name="section" select="$section"/> | ||
42 | <xsl:with-param name="level" select="$level"/> | ||
43 | <xsl:with-param name="title"> | ||
44 | <xsl:apply-templates select="$section" mode="object.title.markup"> | ||
45 | <xsl:with-param name="allow-anchors" select="1"/> | ||
46 | </xsl:apply-templates> | ||
47 | <xsl:if test="$level > 0"> | ||
48 | <xsl:call-template name="permalink"> | ||
49 | <xsl:with-param name="node" select="$section"/> | ||
50 | </xsl:call-template> | ||
51 | </xsl:if> | ||
52 | </xsl:with-param> | ||
53 | </xsl:call-template> | ||
54 | </xsl:template> | ||
55 | </xsl:stylesheet> | ||
diff --git a/bitbake/doc/template/titlepage.templates.xml b/bitbake/doc/template/titlepage.templates.xml deleted file mode 100644 index 38ec11a4c3..0000000000 --- a/bitbake/doc/template/titlepage.templates.xml +++ /dev/null | |||
@@ -1,1259 +0,0 @@ | |||
1 | <!DOCTYPE t:templates [ | ||
2 | <!ENTITY hsize0 "10pt"> | ||
3 | <!ENTITY hsize1 "12pt"> | ||
4 | <!ENTITY hsize2 "14.4pt"> | ||
5 | <!ENTITY hsize3 "17.28pt"> | ||
6 | <!ENTITY hsize4 "20.736pt"> | ||
7 | <!ENTITY hsize5 "24.8832pt"> | ||
8 | <!ENTITY hsize0space "7.5pt"> <!-- 0.75 * hsize0 --> | ||
9 | <!ENTITY hsize1space "9pt"> <!-- 0.75 * hsize1 --> | ||
10 | <!ENTITY hsize2space "10.8pt"> <!-- 0.75 * hsize2 --> | ||
11 | <!ENTITY hsize3space "12.96pt"> <!-- 0.75 * hsize3 --> | ||
12 | <!ENTITY hsize4space "15.552pt"> <!-- 0.75 * hsize4 --> | ||
13 | <!ENTITY hsize5space "18.6624pt"> <!-- 0.75 * hsize5 --> | ||
14 | ]> | ||
15 | <t:templates xmlns:t="http://nwalsh.com/docbook/xsl/template/1.0" | ||
16 | xmlns:param="http://nwalsh.com/docbook/xsl/template/1.0/param" | ||
17 | xmlns:fo="http://www.w3.org/1999/XSL/Format" | ||
18 | xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> | ||
19 | |||
20 | <!-- ******************************************************************** | ||
21 | $Id: titlepage.templates.xml,v 1.23 2003/12/16 00:30:49 bobstayton Exp $ | ||
22 | ******************************************************************** | ||
23 | |||
24 | This file is part of the DocBook XSL Stylesheet distribution. | ||
25 | See ../README or http://docbook.sf.net/ for copyright | ||
26 | and other information. | ||
27 | |||
28 | ******************************************************************** --> | ||
29 | |||
30 | <!-- ==================================================================== --> | ||
31 | |||
32 | <t:titlepage t:element="article" t:wrapper="fo:block" | ||
33 | font-family="{$title.fontset}"> | ||
34 | |||
35 | <t:titlepage-content t:side="recto" | ||
36 | text-align="center"> | ||
37 | |||
38 | <mediaobject/> | ||
39 | |||
40 | <title t:named-template="component.title" | ||
41 | param:node="ancestor-or-self::article[1]" | ||
42 | keep-with-next="always" | ||
43 | font-size="&hsize5;" | ||
44 | font-weight="bold"/> | ||
45 | |||
46 | <subtitle param:node="ancestor-or-self::article[1]" | ||
47 | keep-with-next="always" | ||
48 | font-size="&hsize3;" | ||
49 | font-weight="bold" | ||
50 | space-after="0.8em"/> | ||
51 | |||
52 | <corpauthor space-before="0.5em" | ||
53 | font-size="&hsize3;"/> | ||
54 | <authorgroup space-before="0.5em" | ||
55 | font-size="&hsize2;"/> | ||
56 | <author space-before="0.5em" | ||
57 | font-size="&hsize2;" | ||
58 | space-after="0.8em"/> | ||
59 | |||
60 | <email font-size="&hsize2;"/> | ||
61 | |||
62 | <othercredit space-before="0.5em"/> | ||
63 | <releaseinfo space-before="0.5em"/> | ||
64 | <copyright space-before="0.5em"/> | ||
65 | <legalnotice text-align="start" | ||
66 | margin-left="0.5in" | ||
67 | margin-right="0.5in" | ||
68 | font-family="{$body.fontset}"/> | ||
69 | <pubdate space-before="0.5em"/> | ||
70 | <para></para> | ||
71 | <revision space-before="0.5em"/> | ||
72 | <revhistory space-before="0.5em"/> | ||
73 | <abstract space-before="0.5em" | ||
74 | text-align="start" | ||
75 | margin-left="0.5in" | ||
76 | margin-right="0.5in" | ||
77 | font-family="{$body.fontset}"/> | ||
78 | |||
79 | <para></para> | ||
80 | </t:titlepage-content> | ||
81 | |||
82 | <t:titlepage-content t:side="verso"> | ||
83 | </t:titlepage-content> | ||
84 | |||
85 | <t:titlepage-separator> | ||
86 | </t:titlepage-separator> | ||
87 | |||
88 | <t:titlepage-before t:side="recto"> | ||
89 | </t:titlepage-before> | ||
90 | |||
91 | <t:titlepage-before t:side="verso"> | ||
92 | </t:titlepage-before> | ||
93 | </t:titlepage> | ||
94 | |||
95 | <!-- ==================================================================== --> | ||
96 | |||
97 | <t:titlepage t:element="set" t:wrapper="fo:block"> | ||
98 | <t:titlepage-content t:side="recto"> | ||
99 | <title | ||
100 | t:named-template="division.title" | ||
101 | param:node="ancestor-or-self::set[1]" | ||
102 | text-align="center" | ||
103 | font-size="&hsize5;" | ||
104 | space-before="&hsize5space;" | ||
105 | font-weight="bold" | ||
106 | font-family="{$title.fontset}"/> | ||
107 | <subtitle | ||
108 | font-family="{$title.fontset}" | ||
109 | text-align="center"/> | ||
110 | <corpauthor/> | ||
111 | <authorgroup/> | ||
112 | <author/> | ||
113 | <othercredit/> | ||
114 | <releaseinfo/> | ||
115 | <copyright/> | ||
116 | <legalnotice/> | ||
117 | <pubdate/> | ||
118 | <revision/> | ||
119 | <revhistory/> | ||
120 | <abstract/> | ||
121 | </t:titlepage-content> | ||
122 | |||
123 | <t:titlepage-content t:side="verso"> | ||
124 | </t:titlepage-content> | ||
125 | |||
126 | <t:titlepage-separator> | ||
127 | </t:titlepage-separator> | ||
128 | |||
129 | <t:titlepage-before t:side="recto"> | ||
130 | </t:titlepage-before> | ||
131 | |||
132 | <t:titlepage-before t:side="verso"> | ||
133 | </t:titlepage-before> | ||
134 | </t:titlepage> | ||
135 | |||
136 | <!-- ==================================================================== --> | ||
137 | |||
138 | <t:titlepage t:element="book" t:wrapper="fo:block"> | ||
139 | <t:titlepage-content t:side="recto"> | ||
140 | |||
141 | <mediaobject/> | ||
142 | |||
143 | <!-- | ||
144 | |||
145 | # If you leave this block of code in then the text title in the | ||
146 | # <title>BitBake User Manual</title> statement of the | ||
147 | # bitbake-user-manual.xml file is rendered on the title page below the | ||
148 | # image. Commenting it out gets it out of there yet allows it | ||
149 | # to be retained in the tab text for the HTML version of the | ||
150 | # manual. | ||
151 | |||
152 | <title | ||
153 | t:named-template="division.title" | ||
154 | param:node="ancestor-or-self::book[1]" | ||
155 | text-align="center" | ||
156 | font-size="&hsize5;" | ||
157 | space-before="&hsize5space;" | ||
158 | font-weight="bold" | ||
159 | font-family="{$title.fontset}"/> | ||
160 | --> | ||
161 | <subtitle | ||
162 | text-align="center" | ||
163 | font-size="&hsize4;" | ||
164 | space-before="&hsize4space;" | ||
165 | font-family="{$title.fontset}"/> | ||
166 | <corpauthor font-size="&hsize3;" | ||
167 | keep-with-next="always" | ||
168 | space-before="2in"/> | ||
169 | <authorgroup space-before="2in"/> | ||
170 | <author font-size="&hsize3;" | ||
171 | space-before="&hsize2space;" | ||
172 | keep-with-next="always"/> | ||
173 | </t:titlepage-content> | ||
174 | |||
175 | <t:titlepage-content t:side="verso"> | ||
176 | <!-- | ||
177 | # If you leave this block of code in then the text title in the | ||
178 | # <title>BitBake User Manual</title> statement of the | ||
179 | # bitbake-user-manual.xml file is rendered on the title page below the | ||
180 | # image. Commenting it out gets it out of there yet allows it | ||
181 | # to be retained in the tab text for the HTML version of the | ||
182 | # manual. | ||
183 | |||
184 | <title | ||
185 | t:named-template="book.verso.title" | ||
186 | font-size="&hsize2;" | ||
187 | font-weight="bold" | ||
188 | font-family="{$title.fontset}"/> | ||
189 | --> | ||
190 | <corpauthor/> | ||
191 | <authorgroup t:named-template="verso.authorgroup"/> | ||
192 | <author/> | ||
193 | <othercredit/> | ||
194 | <pubdate space-before="1em"/> | ||
195 | <copyright/> | ||
196 | <abstract/> | ||
197 | <legalnotice font-size="8pt"/> | ||
198 | </t:titlepage-content> | ||
199 | |||
200 | <t:titlepage-separator> | ||
201 | <fo:block break-after="page"/> | ||
202 | </t:titlepage-separator> | ||
203 | |||
204 | <t:titlepage-before t:side="recto"> | ||
205 | </t:titlepage-before> | ||
206 | |||
207 | <t:titlepage-before t:side="verso"> | ||
208 | <fo:block break-after="page"/> | ||
209 | </t:titlepage-before> | ||
210 | </t:titlepage> | ||
211 | |||
212 | <!-- ==================================================================== --> | ||
213 | |||
214 | <t:titlepage t:element="part" t:wrapper="fo:block"> | ||
215 | <t:titlepage-content t:side="recto"> | ||
216 | <title | ||
217 | t:named-template="division.title" | ||
218 | param:node="ancestor-or-self::part[1]" | ||
219 | text-align="center" | ||
220 | font-size="&hsize5;" | ||
221 | space-before="&hsize5space;" | ||
222 | font-weight="bold" | ||
223 | font-family="{$title.fontset}"/> | ||
224 | <subtitle | ||
225 | text-align="center" | ||
226 | font-size="&hsize4;" | ||
227 | space-before="&hsize4space;" | ||
228 | font-weight='bold' | ||
229 | font-style='italic' | ||
230 | font-family="{$title.fontset}"/> | ||
231 | </t:titlepage-content> | ||
232 | |||
233 | <t:titlepage-content t:side="verso"> | ||
234 | </t:titlepage-content> | ||
235 | |||
236 | <t:titlepage-separator> | ||
237 | </t:titlepage-separator> | ||
238 | |||
239 | <t:titlepage-before t:side="recto"> | ||
240 | </t:titlepage-before> | ||
241 | |||
242 | <t:titlepage-before t:side="verso"> | ||
243 | </t:titlepage-before> | ||
244 | </t:titlepage> | ||
245 | |||
246 | <t:titlepage t:element="partintro" t:wrapper="fo:block"> | ||
247 | <t:titlepage-content t:side="recto"> | ||
248 | <title | ||
249 | text-align="center" | ||
250 | font-size="&hsize5;" | ||
251 | font-weight="bold" | ||
252 | space-before="1em" | ||
253 | font-family="{$title.fontset}"/> | ||
254 | <subtitle | ||
255 | text-align="center" | ||
256 | font-size="&hsize2;" | ||
257 | font-weight="bold" | ||
258 | font-style="italic" | ||
259 | font-family="{$title.fontset}"/> | ||
260 | <corpauthor/> | ||
261 | <authorgroup/> | ||
262 | <author/> | ||
263 | <othercredit/> | ||
264 | <releaseinfo/> | ||
265 | <copyright/> | ||
266 | <legalnotice/> | ||
267 | <pubdate/> | ||
268 | <revision/> | ||
269 | <revhistory/> | ||
270 | <abstract/> | ||
271 | </t:titlepage-content> | ||
272 | |||
273 | <t:titlepage-content t:side="verso"> | ||
274 | </t:titlepage-content> | ||
275 | |||
276 | <t:titlepage-separator> | ||
277 | </t:titlepage-separator> | ||
278 | |||
279 | <t:titlepage-before t:side="recto"> | ||
280 | </t:titlepage-before> | ||
281 | |||
282 | <t:titlepage-before t:side="verso"> | ||
283 | </t:titlepage-before> | ||
284 | </t:titlepage> | ||
285 | |||
286 | <!-- ==================================================================== --> | ||
287 | |||
288 | <t:titlepage t:element="reference" t:wrapper="fo:block"> | ||
289 | <t:titlepage-content t:side="recto"> | ||
290 | <title | ||
291 | t:named-template="division.title" | ||
292 | param:node="ancestor-or-self::reference[1]" | ||
293 | text-align="center" | ||
294 | font-size="&hsize5;" | ||
295 | space-before="&hsize5space;" | ||
296 | font-weight="bold" | ||
297 | font-family="{$title.fontset}"/> | ||
298 | <subtitle | ||
299 | font-family="{$title.fontset}" | ||
300 | text-align="center"/> | ||
301 | <corpauthor/> | ||
302 | <authorgroup/> | ||
303 | <author/> | ||
304 | <othercredit/> | ||
305 | <releaseinfo/> | ||
306 | <copyright/> | ||
307 | <legalnotice/> | ||
308 | <pubdate/> | ||
309 | <revision/> | ||
310 | <revhistory/> | ||
311 | <abstract/> | ||
312 | </t:titlepage-content> | ||
313 | |||
314 | <t:titlepage-content t:side="verso"> | ||
315 | </t:titlepage-content> | ||
316 | |||
317 | <t:titlepage-separator> | ||
318 | </t:titlepage-separator> | ||
319 | |||
320 | <t:titlepage-before t:side="recto"> | ||
321 | </t:titlepage-before> | ||
322 | |||
323 | <t:titlepage-before t:side="verso"> | ||
324 | </t:titlepage-before> | ||
325 | </t:titlepage> | ||
326 | |||
327 | <!-- ==================================================================== --> | ||
328 | |||
329 | <t:titlepage t:element="refsynopsisdiv" t:wrapper="fo:block"> | ||
330 | <t:titlepage-content t:side="recto"> | ||
331 | <title | ||
332 | font-family="{$title.fontset}"/> | ||
333 | </t:titlepage-content> | ||
334 | |||
335 | <t:titlepage-content t:side="verso"> | ||
336 | </t:titlepage-content> | ||
337 | |||
338 | <t:titlepage-separator> | ||
339 | </t:titlepage-separator> | ||
340 | |||
341 | <t:titlepage-before t:side="recto"> | ||
342 | </t:titlepage-before> | ||
343 | |||
344 | <t:titlepage-before t:side="verso"> | ||
345 | </t:titlepage-before> | ||
346 | </t:titlepage> | ||
347 | |||
348 | <!-- ==================================================================== --> | ||
349 | |||
350 | <t:titlepage t:element="refsection" t:wrapper="fo:block"> | ||
351 | <t:titlepage-content t:side="recto"> | ||
352 | <title | ||
353 | font-family="{$title.fontset}"/> | ||
354 | </t:titlepage-content> | ||
355 | |||
356 | <t:titlepage-content t:side="verso"> | ||
357 | </t:titlepage-content> | ||
358 | |||
359 | <t:titlepage-separator> | ||
360 | </t:titlepage-separator> | ||
361 | |||
362 | <t:titlepage-before t:side="recto"> | ||
363 | </t:titlepage-before> | ||
364 | |||
365 | <t:titlepage-before t:side="verso"> | ||
366 | </t:titlepage-before> | ||
367 | </t:titlepage> | ||
368 | |||
369 | <!-- ==================================================================== --> | ||
370 | |||
371 | <t:titlepage t:element="refsect1" t:wrapper="fo:block"> | ||
372 | <t:titlepage-content t:side="recto"> | ||
373 | <title | ||
374 | font-family="{$title.fontset}"/> | ||
375 | </t:titlepage-content> | ||
376 | |||
377 | <t:titlepage-content t:side="verso"> | ||
378 | </t:titlepage-content> | ||
379 | |||
380 | <t:titlepage-separator> | ||
381 | </t:titlepage-separator> | ||
382 | |||
383 | <t:titlepage-before t:side="recto"> | ||
384 | </t:titlepage-before> | ||
385 | |||
386 | <t:titlepage-before t:side="verso"> | ||
387 | </t:titlepage-before> | ||
388 | </t:titlepage> | ||
389 | |||
390 | <!-- ==================================================================== --> | ||
391 | |||
392 | <t:titlepage t:element="refsect2" t:wrapper="fo:block"> | ||
393 | <t:titlepage-content t:side="recto"> | ||
394 | <title | ||
395 | font-family="{$title.fontset}"/> | ||
396 | </t:titlepage-content> | ||
397 | |||
398 | <t:titlepage-content t:side="verso"> | ||
399 | </t:titlepage-content> | ||
400 | |||
401 | <t:titlepage-separator> | ||
402 | </t:titlepage-separator> | ||
403 | |||
404 | <t:titlepage-before t:side="recto"> | ||
405 | </t:titlepage-before> | ||
406 | |||
407 | <t:titlepage-before t:side="verso"> | ||
408 | </t:titlepage-before> | ||
409 | </t:titlepage> | ||
410 | |||
411 | <!-- ==================================================================== --> | ||
412 | |||
413 | <t:titlepage t:element="refsect3" t:wrapper="fo:block"> | ||
414 | <t:titlepage-content t:side="recto"> | ||
415 | <title | ||
416 | font-family="{$title.fontset}"/> | ||
417 | </t:titlepage-content> | ||
418 | |||
419 | <t:titlepage-content t:side="verso"> | ||
420 | </t:titlepage-content> | ||
421 | |||
422 | <t:titlepage-separator> | ||
423 | </t:titlepage-separator> | ||
424 | |||
425 | <t:titlepage-before t:side="recto"> | ||
426 | </t:titlepage-before> | ||
427 | |||
428 | <t:titlepage-before t:side="verso"> | ||
429 | </t:titlepage-before> | ||
430 | </t:titlepage> | ||
431 | |||
432 | <!-- ==================================================================== --> | ||
433 | |||
434 | <t:titlepage t:element="dedication" t:wrapper="fo:block"> | ||
435 | <t:titlepage-content t:side="recto"> | ||
436 | <title | ||
437 | t:force="1" | ||
438 | t:named-template="component.title" | ||
439 | param:node="ancestor-or-self::dedication[1]" | ||
440 | margin-left="{$title.margin.left}" | ||
441 | font-size="&hsize5;" | ||
442 | font-family="{$title.fontset}" | ||
443 | font-weight="bold"/> | ||
444 | <subtitle | ||
445 | font-family="{$title.fontset}"/> | ||
446 | </t:titlepage-content> | ||
447 | |||
448 | <t:titlepage-content t:side="verso"> | ||
449 | </t:titlepage-content> | ||
450 | |||
451 | <t:titlepage-separator> | ||
452 | </t:titlepage-separator> | ||
453 | |||
454 | <t:titlepage-before t:side="recto"> | ||
455 | </t:titlepage-before> | ||
456 | |||
457 | <t:titlepage-before t:side="verso"> | ||
458 | </t:titlepage-before> | ||
459 | </t:titlepage> | ||
460 | |||
461 | <!-- ==================================================================== --> | ||
462 | |||
463 | <t:titlepage t:element="preface" t:wrapper="fo:block"> | ||
464 | <t:titlepage-content t:side="recto"> | ||
465 | <title | ||
466 | t:force="1" | ||
467 | t:named-template="component.title" | ||
468 | param:node="ancestor-or-self::preface[1]" | ||
469 | margin-left="{$title.margin.left}" | ||
470 | font-size="&hsize5;" | ||
471 | font-family="{$title.fontset}" | ||
472 | font-weight="bold"/> | ||
473 | <subtitle | ||
474 | font-family="{$title.fontset}"/> | ||
475 | <corpauthor/> | ||
476 | <authorgroup/> | ||
477 | <author/> | ||
478 | <othercredit/> | ||
479 | <releaseinfo/> | ||
480 | <copyright/> | ||
481 | <legalnotice/> | ||
482 | <pubdate/> | ||
483 | <revision/> | ||
484 | <revhistory/> | ||
485 | <abstract/> | ||
486 | </t:titlepage-content> | ||
487 | |||
488 | <t:titlepage-content t:side="verso"> | ||
489 | </t:titlepage-content> | ||
490 | |||
491 | <t:titlepage-separator> | ||
492 | </t:titlepage-separator> | ||
493 | |||
494 | <t:titlepage-before t:side="recto"> | ||
495 | </t:titlepage-before> | ||
496 | |||
497 | <t:titlepage-before t:side="verso"> | ||
498 | </t:titlepage-before> | ||
499 | </t:titlepage> | ||
500 | |||
501 | <!-- ==================================================================== --> | ||
502 | |||
503 | <t:titlepage t:element="chapter" t:wrapper="fo:block" | ||
504 | font-family="{$title.fontset}"> | ||
505 | <t:titlepage-content t:side="recto" margin-left="{$title.margin.left}"> | ||
506 | <title t:named-template="component.title" | ||
507 | param:node="ancestor-or-self::chapter[1]" | ||
508 | font-size="&hsize5;" | ||
509 | font-weight="bold"/> | ||
510 | |||
511 | <subtitle space-before="0.5em" | ||
512 | font-style="italic" | ||
513 | font-size="&hsize2;" | ||
514 | font-weight="bold"/> | ||
515 | |||
516 | <corpauthor space-before="0.5em" | ||
517 | space-after="0.5em" | ||
518 | font-size="&hsize2;"/> | ||
519 | |||
520 | <authorgroup space-before="0.5em" | ||
521 | space-after="0.5em" | ||
522 | font-size="&hsize2;"/> | ||
523 | |||
524 | <author space-before="0.5em" | ||
525 | space-after="0.5em" | ||
526 | font-size="&hsize2;"/> | ||
527 | |||
528 | <othercredit/> | ||
529 | <releaseinfo/> | ||
530 | <copyright/> | ||
531 | <legalnotice/> | ||
532 | <pubdate/> | ||
533 | <revision/> | ||
534 | <revhistory/> | ||
535 | <abstract/> | ||
536 | </t:titlepage-content> | ||
537 | |||
538 | <t:titlepage-content t:side="verso"> | ||
539 | </t:titlepage-content> | ||
540 | |||
541 | <t:titlepage-separator> | ||
542 | </t:titlepage-separator> | ||
543 | |||
544 | <t:titlepage-before t:side="recto"> | ||
545 | </t:titlepage-before> | ||
546 | |||
547 | <t:titlepage-before t:side="verso"> | ||
548 | </t:titlepage-before> | ||
549 | </t:titlepage> | ||
550 | |||
551 | <!-- ==================================================================== --> | ||
552 | |||
553 | <t:titlepage t:element="appendix" t:wrapper="fo:block"> | ||
554 | <t:titlepage-content t:side="recto"> | ||
555 | <title | ||
556 | t:named-template="component.title" | ||
557 | param:node="ancestor-or-self::appendix[1]" | ||
558 | margin-left="{$title.margin.left}" | ||
559 | font-size="&hsize5;" | ||
560 | font-weight="bold" | ||
561 | font-family="{$title.fontset}"/> | ||
562 | <subtitle | ||
563 | font-family="{$title.fontset}"/> | ||
564 | <corpauthor/> | ||
565 | <authorgroup/> | ||
566 | <author/> | ||
567 | <othercredit/> | ||
568 | <releaseinfo/> | ||
569 | <copyright/> | ||
570 | <legalnotice/> | ||
571 | <pubdate/> | ||
572 | <revision/> | ||
573 | <revhistory/> | ||
574 | <abstract/> | ||
575 | </t:titlepage-content> | ||
576 | |||
577 | <t:titlepage-content t:side="verso"> | ||
578 | </t:titlepage-content> | ||
579 | |||
580 | <t:titlepage-separator> | ||
581 | </t:titlepage-separator> | ||
582 | |||
583 | <t:titlepage-before t:side="recto"> | ||
584 | </t:titlepage-before> | ||
585 | |||
586 | <t:titlepage-before t:side="verso"> | ||
587 | </t:titlepage-before> | ||
588 | </t:titlepage> | ||
589 | |||
590 | <!-- ==================================================================== --> | ||
591 | |||
592 | <t:titlepage t:element="section" t:wrapper="fo:block"> | ||
593 | <t:titlepage-content t:side="recto"> | ||
594 | <title | ||
595 | margin-left="{$title.margin.left}" | ||
596 | font-family="{$title.fontset}"/> | ||
597 | <subtitle | ||
598 | font-family="{$title.fontset}"/> | ||
599 | <corpauthor/> | ||
600 | <authorgroup/> | ||
601 | <author/> | ||
602 | <othercredit/> | ||
603 | <releaseinfo/> | ||
604 | <copyright/> | ||
605 | <legalnotice/> | ||
606 | <pubdate/> | ||
607 | <revision/> | ||
608 | <revhistory/> | ||
609 | <abstract/> | ||
610 | </t:titlepage-content> | ||
611 | |||
612 | <t:titlepage-content t:side="verso"> | ||
613 | </t:titlepage-content> | ||
614 | |||
615 | <t:titlepage-separator> | ||
616 | </t:titlepage-separator> | ||
617 | |||
618 | <t:titlepage-before t:side="recto"> | ||
619 | </t:titlepage-before> | ||
620 | |||
621 | <t:titlepage-before t:side="verso"> | ||
622 | </t:titlepage-before> | ||
623 | </t:titlepage> | ||
624 | |||
625 | <t:titlepage t:element="sect1" t:wrapper="fo:block"> | ||
626 | <t:titlepage-content t:side="recto"> | ||
627 | <title | ||
628 | margin-left="{$title.margin.left}" | ||
629 | font-family="{$title.fontset}"/> | ||
630 | <subtitle | ||
631 | font-family="{$title.fontset}"/> | ||
632 | <corpauthor/> | ||
633 | <authorgroup/> | ||
634 | <author/> | ||
635 | <othercredit/> | ||
636 | <releaseinfo/> | ||
637 | <copyright/> | ||
638 | <legalnotice/> | ||
639 | <pubdate/> | ||
640 | <revision/> | ||
641 | <revhistory/> | ||
642 | <abstract/> | ||
643 | </t:titlepage-content> | ||
644 | |||
645 | <t:titlepage-content t:side="verso"> | ||
646 | </t:titlepage-content> | ||
647 | |||
648 | <t:titlepage-separator> | ||
649 | </t:titlepage-separator> | ||
650 | |||
651 | <t:titlepage-before t:side="recto"> | ||
652 | </t:titlepage-before> | ||
653 | |||
654 | <t:titlepage-before t:side="verso"> | ||
655 | </t:titlepage-before> | ||
656 | </t:titlepage> | ||
657 | |||
658 | <t:titlepage t:element="sect2" t:wrapper="fo:block"> | ||
659 | <t:titlepage-content t:side="recto"> | ||
660 | <title | ||
661 | margin-left="{$title.margin.left}" | ||
662 | font-family="{$title.fontset}"/> | ||
663 | <subtitle | ||
664 | font-family="{$title.fontset}"/> | ||
665 | <corpauthor/> | ||
666 | <authorgroup/> | ||
667 | <author/> | ||
668 | <othercredit/> | ||
669 | <releaseinfo/> | ||
670 | <copyright/> | ||
671 | <legalnotice/> | ||
672 | <pubdate/> | ||
673 | <revision/> | ||
674 | <revhistory/> | ||
675 | <abstract/> | ||
676 | </t:titlepage-content> | ||
677 | |||
678 | <t:titlepage-content t:side="verso"> | ||
679 | </t:titlepage-content> | ||
680 | |||
681 | <t:titlepage-separator> | ||
682 | </t:titlepage-separator> | ||
683 | |||
684 | <t:titlepage-before t:side="recto"> | ||
685 | </t:titlepage-before> | ||
686 | |||
687 | <t:titlepage-before t:side="verso"> | ||
688 | </t:titlepage-before> | ||
689 | </t:titlepage> | ||
690 | |||
691 | <t:titlepage t:element="sect3" t:wrapper="fo:block"> | ||
692 | <t:titlepage-content t:side="recto"> | ||
693 | <title | ||
694 | margin-left="{$title.margin.left}" | ||
695 | font-family="{$title.fontset}"/> | ||
696 | <subtitle | ||
697 | font-family="{$title.fontset}"/> | ||
698 | <corpauthor/> | ||
699 | <authorgroup/> | ||
700 | <author/> | ||
701 | <othercredit/> | ||
702 | <releaseinfo/> | ||
703 | <copyright/> | ||
704 | <legalnotice/> | ||
705 | <pubdate/> | ||
706 | <revision/> | ||
707 | <revhistory/> | ||
708 | <abstract/> | ||
709 | </t:titlepage-content> | ||
710 | |||
711 | <t:titlepage-content t:side="verso"> | ||
712 | </t:titlepage-content> | ||
713 | |||
714 | <t:titlepage-separator> | ||
715 | </t:titlepage-separator> | ||
716 | |||
717 | <t:titlepage-before t:side="recto"> | ||
718 | </t:titlepage-before> | ||
719 | |||
720 | <t:titlepage-before t:side="verso"> | ||
721 | </t:titlepage-before> | ||
722 | </t:titlepage> | ||
723 | |||
724 | <t:titlepage t:element="sect4" t:wrapper="fo:block"> | ||
725 | <t:titlepage-content t:side="recto"> | ||
726 | <title | ||
727 | margin-left="{$title.margin.left}" | ||
728 | font-family="{$title.fontset}"/> | ||
729 | <subtitle | ||
730 | font-family="{$title.fontset}"/> | ||
731 | <corpauthor/> | ||
732 | <authorgroup/> | ||
733 | <author/> | ||
734 | <othercredit/> | ||
735 | <releaseinfo/> | ||
736 | <copyright/> | ||
737 | <legalnotice/> | ||
738 | <pubdate/> | ||
739 | <revision/> | ||
740 | <revhistory/> | ||
741 | <abstract/> | ||
742 | </t:titlepage-content> | ||
743 | |||
744 | <t:titlepage-content t:side="verso"> | ||
745 | </t:titlepage-content> | ||
746 | |||
747 | <t:titlepage-separator> | ||
748 | </t:titlepage-separator> | ||
749 | |||
750 | <t:titlepage-before t:side="recto"> | ||
751 | </t:titlepage-before> | ||
752 | |||
753 | <t:titlepage-before t:side="verso"> | ||
754 | </t:titlepage-before> | ||
755 | </t:titlepage> | ||
756 | |||
757 | <t:titlepage t:element="sect5" t:wrapper="fo:block"> | ||
758 | <t:titlepage-content t:side="recto"> | ||
759 | <title | ||
760 | margin-left="{$title.margin.left}" | ||
761 | font-family="{$title.fontset}"/> | ||
762 | <subtitle | ||
763 | font-family="{$title.fontset}"/> | ||
764 | <corpauthor/> | ||
765 | <authorgroup/> | ||
766 | <author/> | ||
767 | <othercredit/> | ||
768 | <releaseinfo/> | ||
769 | <copyright/> | ||
770 | <legalnotice/> | ||
771 | <pubdate/> | ||
772 | <revision/> | ||
773 | <revhistory/> | ||
774 | <abstract/> | ||
775 | </t:titlepage-content> | ||
776 | |||
777 | <t:titlepage-content t:side="verso"> | ||
778 | </t:titlepage-content> | ||
779 | |||
780 | <t:titlepage-separator> | ||
781 | </t:titlepage-separator> | ||
782 | |||
783 | <t:titlepage-before t:side="recto"> | ||
784 | </t:titlepage-before> | ||
785 | |||
786 | <t:titlepage-before t:side="verso"> | ||
787 | </t:titlepage-before> | ||
788 | </t:titlepage> | ||
789 | |||
790 | <t:titlepage t:element="simplesect" t:wrapper="fo:block"> | ||
791 | <t:titlepage-content t:side="recto"> | ||
792 | <title | ||
793 | margin-left="{$title.margin.left}" | ||
794 | font-family="{$title.fontset}"/> | ||
795 | <subtitle | ||
796 | font-family="{$title.fontset}"/> | ||
797 | <corpauthor/> | ||
798 | <authorgroup/> | ||
799 | <author/> | ||
800 | <othercredit/> | ||
801 | <releaseinfo/> | ||
802 | <copyright/> | ||
803 | <legalnotice/> | ||
804 | <pubdate/> | ||
805 | <revision/> | ||
806 | <revhistory/> | ||
807 | <abstract/> | ||
808 | </t:titlepage-content> | ||
809 | |||
810 | <t:titlepage-content t:side="verso"> | ||
811 | </t:titlepage-content> | ||
812 | |||
813 | <t:titlepage-separator> | ||
814 | </t:titlepage-separator> | ||
815 | |||
816 | <t:titlepage-before t:side="recto"> | ||
817 | </t:titlepage-before> | ||
818 | |||
819 | <t:titlepage-before t:side="verso"> | ||
820 | </t:titlepage-before> | ||
821 | </t:titlepage> | ||
822 | |||
823 | <!-- ==================================================================== --> | ||
824 | |||
825 | <t:titlepage t:element="bibliography" t:wrapper="fo:block"> | ||
826 | <t:titlepage-content t:side="recto"> | ||
827 | <title | ||
828 | t:force="1" | ||
829 | t:named-template="component.title" | ||
830 | param:node="ancestor-or-self::bibliography[1]" | ||
831 | margin-left="{$title.margin.left}" | ||
832 | font-size="&hsize5;" | ||
833 | font-family="{$title.fontset}" | ||
834 | font-weight="bold"/> | ||
835 | <subtitle | ||
836 | font-family="{$title.fontset}"/> | ||
837 | </t:titlepage-content> | ||
838 | |||
839 | <t:titlepage-content t:side="verso"> | ||
840 | </t:titlepage-content> | ||
841 | |||
842 | <t:titlepage-separator> | ||
843 | </t:titlepage-separator> | ||
844 | |||
845 | <t:titlepage-before t:side="recto"> | ||
846 | </t:titlepage-before> | ||
847 | |||
848 | <t:titlepage-before t:side="verso"> | ||
849 | </t:titlepage-before> | ||
850 | </t:titlepage> | ||
851 | |||
852 | <!-- ==================================================================== --> | ||
853 | |||
854 | <t:titlepage t:element="bibliodiv" t:wrapper="fo:block"> | ||
855 | <t:titlepage-content t:side="recto"> | ||
856 | <title t:named-template="component.title" | ||
857 | param:node="ancestor-or-self::bibliodiv[1]" | ||
858 | margin-left="{$title.margin.left}" | ||
859 | font-size="&hsize4;" | ||
860 | font-family="{$title.fontset}" | ||
861 | font-weight="bold"/> | ||
862 | <subtitle | ||
863 | font-family="{$title.fontset}"/> | ||
864 | </t:titlepage-content> | ||
865 | |||
866 | <t:titlepage-content t:side="verso"> | ||
867 | </t:titlepage-content> | ||
868 | |||
869 | <t:titlepage-separator> | ||
870 | </t:titlepage-separator> | ||
871 | |||
872 | <t:titlepage-before t:side="recto"> | ||
873 | </t:titlepage-before> | ||
874 | |||
875 | <t:titlepage-before t:side="verso"> | ||
876 | </t:titlepage-before> | ||
877 | </t:titlepage> | ||
878 | |||
879 | <!-- ==================================================================== --> | ||
880 | |||
881 | <t:titlepage t:element="glossary" t:wrapper="fo:block"> | ||
882 | <t:titlepage-content t:side="recto"> | ||
883 | <title | ||
884 | t:force="1" | ||
885 | t:named-template="component.title" | ||
886 | param:node="ancestor-or-self::glossary[1]" | ||
887 | margin-left="{$title.margin.left}" | ||
888 | font-size="&hsize5;" | ||
889 | font-family="{$title.fontset}" | ||
890 | font-weight="bold"/> | ||
891 | <subtitle | ||
892 | font-family="{$title.fontset}"/> | ||
893 | </t:titlepage-content> | ||
894 | |||
895 | <t:titlepage-content t:side="verso"> | ||
896 | </t:titlepage-content> | ||
897 | |||
898 | <t:titlepage-separator> | ||
899 | </t:titlepage-separator> | ||
900 | |||
901 | <t:titlepage-before t:side="recto"> | ||
902 | </t:titlepage-before> | ||
903 | |||
904 | <t:titlepage-before t:side="verso"> | ||
905 | </t:titlepage-before> | ||
906 | </t:titlepage> | ||
907 | |||
908 | <!-- ==================================================================== --> | ||
909 | |||
910 | <t:titlepage t:element="glossdiv" t:wrapper="fo:block"> | ||
911 | <t:titlepage-content t:side="recto"> | ||
912 | <title t:named-template="component.title" | ||
913 | param:node="ancestor-or-self::glossdiv[1]" | ||
914 | margin-left="{$title.margin.left}" | ||
915 | font-size="&hsize4;" | ||
916 | font-family="{$title.fontset}" | ||
917 | font-weight="bold"/> | ||
918 | <subtitle | ||
919 | font-family="{$title.fontset}"/> | ||
920 | </t:titlepage-content> | ||
921 | |||
922 | <t:titlepage-content t:side="verso"> | ||
923 | </t:titlepage-content> | ||
924 | |||
925 | <t:titlepage-separator> | ||
926 | </t:titlepage-separator> | ||
927 | |||
928 | <t:titlepage-before t:side="recto"> | ||
929 | </t:titlepage-before> | ||
930 | |||
931 | <t:titlepage-before t:side="verso"> | ||
932 | </t:titlepage-before> | ||
933 | </t:titlepage> | ||
934 | |||
935 | <!-- ==================================================================== --> | ||
936 | |||
937 | <t:titlepage t:element="index" t:wrapper="fo:block"> | ||
938 | <t:titlepage-content t:side="recto"> | ||
939 | <title | ||
940 | t:force="1" | ||
941 | t:named-template="component.title" | ||
942 | param:node="ancestor-or-self::index[1]" | ||
943 | param:pagewide="1" | ||
944 | margin-left="0pt" | ||
945 | font-size="&hsize5;" | ||
946 | font-family="{$title.fontset}" | ||
947 | font-weight="bold"/> | ||
948 | <subtitle | ||
949 | font-family="{$title.fontset}"/> | ||
950 | </t:titlepage-content> | ||
951 | |||
952 | <t:titlepage-content t:side="verso"> | ||
953 | </t:titlepage-content> | ||
954 | |||
955 | <t:titlepage-separator> | ||
956 | </t:titlepage-separator> | ||
957 | |||
958 | <t:titlepage-before t:side="recto"> | ||
959 | </t:titlepage-before> | ||
960 | |||
961 | <t:titlepage-before t:side="verso"> | ||
962 | </t:titlepage-before> | ||
963 | </t:titlepage> | ||
964 | |||
965 | <!-- ==================================================================== --> | ||
966 | |||
967 | <!-- The indexdiv.title template is used so that manual and --> | ||
968 | <!-- automatically generated indexdiv titles get the same --> | ||
969 | <!-- formatting. --> | ||
970 | |||
971 | <t:titlepage t:element="indexdiv" t:wrapper="fo:block"> | ||
972 | <t:titlepage-content t:side="recto"> | ||
973 | <title t:force="1" | ||
974 | t:named-template="indexdiv.title" | ||
975 | param:title="title"/> | ||
976 | <subtitle | ||
977 | font-family="{$title.fontset}"/> | ||
978 | </t:titlepage-content> | ||
979 | |||
980 | <t:titlepage-content t:side="verso"> | ||
981 | </t:titlepage-content> | ||
982 | |||
983 | <t:titlepage-separator> | ||
984 | </t:titlepage-separator> | ||
985 | |||
986 | <t:titlepage-before t:side="recto"> | ||
987 | </t:titlepage-before> | ||
988 | |||
989 | <t:titlepage-before t:side="verso"> | ||
990 | </t:titlepage-before> | ||
991 | </t:titlepage> | ||
992 | |||
993 | <!-- ==================================================================== --> | ||
994 | |||
995 | <t:titlepage t:element="setindex" t:wrapper="fo:block"> | ||
996 | <t:titlepage-content t:side="recto"> | ||
997 | <title | ||
998 | t:force="1" | ||
999 | t:named-template="component.title" | ||
1000 | param:node="ancestor-or-self::setindex[1]" | ||
1001 | param:pagewide="1" | ||
1002 | margin-left="0pt" | ||
1003 | font-size="&hsize5;" | ||
1004 | font-family="{$title.fontset}" | ||
1005 | font-weight="bold"/> | ||
1006 | <subtitle | ||
1007 | font-family="{$title.fontset}"/> | ||
1008 | </t:titlepage-content> | ||
1009 | |||
1010 | <t:titlepage-content t:side="verso"> | ||
1011 | </t:titlepage-content> | ||
1012 | |||
1013 | <t:titlepage-separator> | ||
1014 | </t:titlepage-separator> | ||
1015 | |||
1016 | <t:titlepage-before t:side="recto"> | ||
1017 | </t:titlepage-before> | ||
1018 | |||
1019 | <t:titlepage-before t:side="verso"> | ||
1020 | </t:titlepage-before> | ||
1021 | </t:titlepage> | ||
1022 | |||
1023 | <!-- ==================================================================== --> | ||
1024 | |||
1025 | <t:titlepage t:element="colophon" t:wrapper="fo:block"> | ||
1026 | <t:titlepage-content t:side="recto"> | ||
1027 | <title | ||
1028 | t:force="1" | ||
1029 | t:named-template="component.title" | ||
1030 | param:node="ancestor-or-self::colophon[1]" | ||
1031 | margin-left="{$title.margin.left}" | ||
1032 | font-size="&hsize5;" | ||
1033 | font-family="{$title.fontset}" | ||
1034 | font-weight="bold"/> | ||
1035 | <subtitle | ||
1036 | font-family="{$title.fontset}"/> | ||
1037 | </t:titlepage-content> | ||
1038 | |||
1039 | <t:titlepage-content t:side="verso"> | ||
1040 | </t:titlepage-content> | ||
1041 | |||
1042 | <t:titlepage-separator> | ||
1043 | </t:titlepage-separator> | ||
1044 | |||
1045 | <t:titlepage-before t:side="recto"> | ||
1046 | </t:titlepage-before> | ||
1047 | |||
1048 | <t:titlepage-before t:side="verso"> | ||
1049 | </t:titlepage-before> | ||
1050 | </t:titlepage> | ||
1051 | |||
1052 | <!-- ==================================================================== --> | ||
1053 | |||
1054 | <t:titlepage t:element="table.of.contents" t:wrapper="fo:block"> | ||
1055 | <t:titlepage-content t:side="recto"> | ||
1056 | <title | ||
1057 | t:force="1" | ||
1058 | t:named-template="gentext" | ||
1059 | param:key="'TableofContents'" | ||
1060 | space-before.minimum="1em" | ||
1061 | space-before.optimum="1.5em" | ||
1062 | space-before.maximum="2em" | ||
1063 | space-after="0.5em" | ||
1064 | margin-left="{$title.margin.left}" | ||
1065 | font-size="&hsize3;" | ||
1066 | font-weight="bold" | ||
1067 | font-family="{$title.fontset}"/> | ||
1068 | </t:titlepage-content> | ||
1069 | |||
1070 | <t:titlepage-content t:side="verso"> | ||
1071 | </t:titlepage-content> | ||
1072 | |||
1073 | <t:titlepage-separator> | ||
1074 | </t:titlepage-separator> | ||
1075 | |||
1076 | <t:titlepage-before t:side="recto"> | ||
1077 | </t:titlepage-before> | ||
1078 | |||
1079 | <t:titlepage-before t:side="verso"> | ||
1080 | </t:titlepage-before> | ||
1081 | </t:titlepage> | ||
1082 | |||
1083 | <t:titlepage t:element="list.of.tables" t:wrapper="fo:block"> | ||
1084 | <t:titlepage-content t:side="recto"> | ||
1085 | <title | ||
1086 | t:force="1" | ||
1087 | t:named-template="gentext" | ||
1088 | param:key="'ListofTables'" | ||
1089 | space-before.minimum="1em" | ||
1090 | space-before.optimum="1.5em" | ||
1091 | space-before.maximum="2em" | ||
1092 | space-after="0.5em" | ||
1093 | margin-left="{$title.margin.left}" | ||
1094 | font-size="&hsize3;" | ||
1095 | font-weight="bold" | ||
1096 | font-family="{$title.fontset}"/> | ||
1097 | </t:titlepage-content> | ||
1098 | |||
1099 | <t:titlepage-content t:side="verso"> | ||
1100 | </t:titlepage-content> | ||
1101 | |||
1102 | <t:titlepage-separator> | ||
1103 | </t:titlepage-separator> | ||
1104 | |||
1105 | <t:titlepage-before t:side="recto"> | ||
1106 | </t:titlepage-before> | ||
1107 | |||
1108 | <t:titlepage-before t:side="verso"> | ||
1109 | </t:titlepage-before> | ||
1110 | </t:titlepage> | ||
1111 | |||
1112 | <t:titlepage t:element="list.of.figures" t:wrapper="fo:block"> | ||
1113 | <t:titlepage-content t:side="recto"> | ||
1114 | <title | ||
1115 | t:force="1" | ||
1116 | t:named-template="gentext" | ||
1117 | param:key="'ListofFigures'" | ||
1118 | space-before.minimum="1em" | ||
1119 | space-before.optimum="1.5em" | ||
1120 | space-before.maximum="2em" | ||
1121 | space-after="0.5em" | ||
1122 | margin-left="{$title.margin.left}" | ||
1123 | font-size="&hsize3;" | ||
1124 | font-weight="bold" | ||
1125 | font-family="{$title.fontset}"/> | ||
1126 | </t:titlepage-content> | ||
1127 | |||
1128 | <t:titlepage-content t:side="verso"> | ||
1129 | </t:titlepage-content> | ||
1130 | |||
1131 | <t:titlepage-separator> | ||
1132 | </t:titlepage-separator> | ||
1133 | |||
1134 | <t:titlepage-before t:side="recto"> | ||
1135 | </t:titlepage-before> | ||
1136 | |||
1137 | <t:titlepage-before t:side="verso"> | ||
1138 | </t:titlepage-before> | ||
1139 | </t:titlepage> | ||
1140 | |||
1141 | <t:titlepage t:element="list.of.examples" t:wrapper="fo:block"> | ||
1142 | <t:titlepage-content t:side="recto"> | ||
1143 | <title | ||
1144 | t:force="1" | ||
1145 | t:named-template="gentext" | ||
1146 | param:key="'ListofExamples'" | ||
1147 | space-before.minimum="1em" | ||
1148 | space-before.optimum="1.5em" | ||
1149 | space-before.maximum="2em" | ||
1150 | space-after="0.5em" | ||
1151 | margin-left="{$title.margin.left}" | ||
1152 | font-size="&hsize3;" | ||
1153 | font-weight="bold" | ||
1154 | font-family="{$title.fontset}"/> | ||
1155 | </t:titlepage-content> | ||
1156 | |||
1157 | <t:titlepage-content t:side="verso"> | ||
1158 | </t:titlepage-content> | ||
1159 | |||
1160 | <t:titlepage-separator> | ||
1161 | </t:titlepage-separator> | ||
1162 | |||
1163 | <t:titlepage-before t:side="recto"> | ||
1164 | </t:titlepage-before> | ||
1165 | |||
1166 | <t:titlepage-before t:side="verso"> | ||
1167 | </t:titlepage-before> | ||
1168 | </t:titlepage> | ||
1169 | |||
1170 | <t:titlepage t:element="list.of.equations" t:wrapper="fo:block"> | ||
1171 | <t:titlepage-content t:side="recto"> | ||
1172 | <title | ||
1173 | t:force="1" | ||
1174 | t:named-template="gentext" | ||
1175 | param:key="'ListofEquations'" | ||
1176 | space-before.minimum="1em" | ||
1177 | space-before.optimum="1.5em" | ||
1178 | space-before.maximum="2em" | ||
1179 | space-after="0.5em" | ||
1180 | margin-left="{$title.margin.left}" | ||
1181 | font-size="&hsize3;" | ||
1182 | font-weight="bold" | ||
1183 | font-family="{$title.fontset}"/> | ||
1184 | </t:titlepage-content> | ||
1185 | |||
1186 | <t:titlepage-content t:side="verso"> | ||
1187 | </t:titlepage-content> | ||
1188 | |||
1189 | <t:titlepage-separator> | ||
1190 | </t:titlepage-separator> | ||
1191 | |||
1192 | <t:titlepage-before t:side="recto"> | ||
1193 | </t:titlepage-before> | ||
1194 | |||
1195 | <t:titlepage-before t:side="verso"> | ||
1196 | </t:titlepage-before> | ||
1197 | </t:titlepage> | ||
1198 | |||
1199 | <t:titlepage t:element="list.of.procedures" t:wrapper="fo:block"> | ||
1200 | <t:titlepage-content t:side="recto"> | ||
1201 | <title | ||
1202 | t:force="1" | ||
1203 | t:named-template="gentext" | ||
1204 | param:key="'ListofProcedures'" | ||
1205 | space-before.minimum="1em" | ||
1206 | space-before.optimum="1.5em" | ||
1207 | space-before.maximum="2em" | ||
1208 | space-after="0.5em" | ||
1209 | margin-left="{$title.margin.left}" | ||
1210 | font-size="&hsize3;" | ||
1211 | font-weight="bold" | ||
1212 | font-family="{$title.fontset}"/> | ||
1213 | </t:titlepage-content> | ||
1214 | |||
1215 | <t:titlepage-content t:side="verso"> | ||
1216 | </t:titlepage-content> | ||
1217 | |||
1218 | <t:titlepage-separator> | ||
1219 | </t:titlepage-separator> | ||
1220 | |||
1221 | <t:titlepage-before t:side="recto"> | ||
1222 | </t:titlepage-before> | ||
1223 | |||
1224 | <t:titlepage-before t:side="verso"> | ||
1225 | </t:titlepage-before> | ||
1226 | </t:titlepage> | ||
1227 | |||
1228 | <t:titlepage t:element="list.of.unknowns" t:wrapper="fo:block"> | ||
1229 | <t:titlepage-content t:side="recto"> | ||
1230 | <title | ||
1231 | t:force="1" | ||
1232 | t:named-template="gentext" | ||
1233 | param:key="'ListofUnknown'" | ||
1234 | space-before.minimum="1em" | ||
1235 | space-before.optimum="1.5em" | ||
1236 | space-before.maximum="2em" | ||
1237 | space-after="0.5em" | ||
1238 | margin-left="{$title.margin.left}" | ||
1239 | font-size="&hsize3;" | ||
1240 | font-weight="bold" | ||
1241 | font-family="{$title.fontset}"/> | ||
1242 | </t:titlepage-content> | ||
1243 | |||
1244 | <t:titlepage-content t:side="verso"> | ||
1245 | </t:titlepage-content> | ||
1246 | |||
1247 | <t:titlepage-separator> | ||
1248 | </t:titlepage-separator> | ||
1249 | |||
1250 | <t:titlepage-before t:side="recto"> | ||
1251 | </t:titlepage-before> | ||
1252 | |||
1253 | <t:titlepage-before t:side="verso"> | ||
1254 | </t:titlepage-before> | ||
1255 | </t:titlepage> | ||
1256 | |||
1257 | <!-- ==================================================================== --> | ||
1258 | |||
1259 | </t:templates> | ||
diff --git a/bitbake/doc/tools/docbook-to-pdf b/bitbake/doc/tools/docbook-to-pdf deleted file mode 100755 index 558ded9e0b..0000000000 --- a/bitbake/doc/tools/docbook-to-pdf +++ /dev/null | |||
@@ -1,51 +0,0 @@ | |||
1 | #!/bin/sh | ||
2 | |||
3 | if [ -z "$1" -o -z "$2" ]; then | ||
4 | echo "usage: [-v] $0 <docbook file> <templatedir>" | ||
5 | echo | ||
6 | echo "*NOTE* you need xsltproc, fop and nwalsh docbook stylesheets" | ||
7 | echo " installed for this to work!" | ||
8 | echo | ||
9 | exit 0 | ||
10 | fi | ||
11 | |||
12 | FO=`echo $1 | sed s/.xml/.fo/` || exit 1 | ||
13 | PDF=`echo $1 | sed s/.xml/.pdf/` || exit 1 | ||
14 | TEMPLATEDIR=$2 | ||
15 | |||
16 | ## | ||
17 | # These URI should be rewritten by your distribution's xml catalog to | ||
18 | # match your localy installed XSL stylesheets. | ||
19 | XSL_BASE_URI="http://docbook.sourceforge.net/release/xsl/current" | ||
20 | |||
21 | # Creates a temporary XSL stylesheet based on titlepage.xsl | ||
22 | xsltproc -o /tmp/titlepage.xsl \ | ||
23 | --xinclude \ | ||
24 | $XSL_BASE_URI/template/titlepage.xsl \ | ||
25 | $TEMPLATEDIR/titlepage.templates.xml || exit 1 | ||
26 | |||
27 | # Creates the file needed for FOP | ||
28 | xsltproc --xinclude \ | ||
29 | --stringparam hyphenate false \ | ||
30 | --stringparam formal.title.placement "figure after" \ | ||
31 | --stringparam ulink.show 1 \ | ||
32 | --stringparam body.font.master 9 \ | ||
33 | --stringparam title.font.master 11 \ | ||
34 | --stringparam draft.watermark.image "$TEMPLATEDIR/draft.png" \ | ||
35 | --stringparam chapter.autolabel 1 \ | ||
36 | --stringparam appendix.autolabel A \ | ||
37 | --stringparam section.autolabel 1 \ | ||
38 | --stringparam section.label.includes.component.label 1 \ | ||
39 | --output $FO \ | ||
40 | $TEMPLATEDIR/db-pdf.xsl \ | ||
41 | $1 || exit 1 | ||
42 | |||
43 | # Invokes the Java version of FOP. Uses the additional configuration file common/fop-config.xml | ||
44 | fop -c $TEMPLATEDIR/fop-config.xml -fo $FO -pdf $PDF || exit 1 | ||
45 | |||
46 | rm -f $FO | ||
47 | rm -f /tmp/titlepage.xsl | ||
48 | |||
49 | echo | ||
50 | echo " #### Success! $PDF ready. ####" | ||
51 | echo | ||