summaryrefslogtreecommitdiffstats
path: root/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
diff options
context:
space:
mode:
Diffstat (limited to 'bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml')
-rw-r--r--bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml2132
1 files changed, 2132 insertions, 0 deletions
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
new file mode 100644
index 0000000..b33a457
--- /dev/null
+++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
@@ -0,0 +1,2132 @@
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-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-variables-glossary'>
38
39 <para>
40 <link linkend='var-ASSUME_PROVIDED'>A</link>
41 <link linkend='var-B'>B</link>
42 <link linkend='var-CACHE'>C</link>
43 <link linkend='var-DEFAULT_PREFERENCE'>D</link>
44 <link linkend='var-EXCLUDE_FROM_WORLD'>E</link>
45 <link linkend='var-FAKEROOT'>F</link>
46<!-- <link linkend='var-GROUPADD_PARAM'>G</link> -->
47 <link linkend='var-HOMEPAGE'>H</link>
48<!-- <link linkend='var-ICECC_DISABLED'>I</link> -->
49<!-- <link linkend='var-glossary-j'>J</link> -->
50<!-- <link linkend='var-KARCH'>K</link> -->
51 <link linkend='var-LAYERDEPENDS'>L</link>
52 <link linkend='var-MIRRORS'>M</link>
53<!-- <link linkend='var-glossary-n'>N</link> -->
54 <link linkend='var-OVERRIDES'>O</link>
55 <link linkend='var-PACKAGES'>P</link>
56<!-- <link linkend='var-QMAKE_PROFILES'>Q</link> -->
57 <link linkend='var-RDEPENDS'>R</link>
58 <link linkend='var-SECTION'>S</link>
59 <link linkend='var-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-glossary-a'><title>A</title>
69
70 <glossentry id='var-ASSUME_PROVIDED'><glossterm>ASSUME_PROVIDED</glossterm>
71 <glossdef>
72 <para>
73 Lists recipe names
74 (<link linkend='var-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-glossary-b'><title>B</title>
95
96 <glossentry id='var-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_CONSOLELOG'><glossterm>BB_CONSOLELOG</glossterm>
106 <glossdef>
107 <para>
108 Specifies the path to a log file into which BitBake's user
109 interface writes output during the build.
110 </para>
111 </glossdef>
112 </glossentry>
113
114 <glossentry id='var-BB_CURRENTTASK'><glossterm>BB_CURRENTTASK</glossterm>
115 <glossdef>
116 <para>
117 Contains the name of the currently running task.
118 The name does not include the
119 <filename>do_</filename> prefix.
120 </para>
121 </glossdef>
122 </glossentry>
123
124 <glossentry id='var-BB_DANGLINGAPPENDS_WARNONLY'><glossterm>BB_DANGLINGAPPENDS_WARNONLY</glossterm>
125 <glossdef>
126 <para>
127 Defines how BitBake handles situations where an append
128 file (<filename>.bbappend</filename>) has no
129 corresponding recipe file (<filename>.bb</filename>).
130 This condition often occurs when layers get out of sync
131 (e.g. <filename>oe-core</filename> bumps a
132 recipe version and the old recipe no longer exists and the
133 other layer has not been updated to the new version
134 of the recipe yet).
135 </para>
136
137 <para>
138 The default fatal behavior is safest because it is
139 the sane reaction given something is out of sync.
140 It is important to realize when your changes are no longer
141 being applied.
142 </para>
143 </glossdef>
144 </glossentry>
145
146 <glossentry id='var-BB_DEFAULT_TASK'><glossterm>BB_DEFAULT_TASK</glossterm>
147 <glossdef>
148 <para>
149 The default task to use when none is specified (e.g.
150 with the <filename>-c</filename> command line option).
151 The task name specified should not include the
152 <filename>do_</filename> prefix.
153 </para>
154 </glossdef>
155 </glossentry>
156
157 <glossentry id='var-BB_DISKMON_DIRS'><glossterm>BB_DISKMON_DIRS</glossterm>
158 <glossdef>
159 <para>
160 Monitors disk space and available inodes during the build
161 and allows you to control the build based on these
162 parameters.
163 </para>
164
165 <para>
166 Disk space monitoring is disabled by default.
167 When setting this variable, use the following form:
168 <literallayout class='monospaced'>
169 BB_DISKMON_DIRS = "&lt;action&gt;,&lt;dir&gt;,&lt;threshold&gt; [...]"
170
171 where:
172
173 &lt;action&gt; is:
174 ABORT: Immediately abort the build when
175 a threshold is broken.
176 STOPTASKS: Stop the build after the currently
177 executing tasks have finished when
178 a threshold is broken.
179 WARN: Issue a warning but continue the
180 build when a threshold is broken.
181 Subsequent warnings are issued as
182 defined by the
183 <link linkend='var-BB_DISKMON_WARNINTERVAL'>BB_DISKMON_WARNINTERVAL</link> variable,
184 which must be defined.
185
186 &lt;dir&gt; is:
187 Any directory you choose. You can specify one or
188 more directories to monitor by separating the
189 groupings with a space. If two directories are
190 on the same device, only the first directory
191 is monitored.
192
193 &lt;threshold&gt; is:
194 Either the minimum available disk space,
195 the minimum number of free inodes, or
196 both. You must specify at least one. To
197 omit one or the other, simply omit the value.
198 Specify the threshold using G, M, K for Gbytes,
199 Mbytes, and Kbytes, respectively. If you do
200 not specify G, M, or K, Kbytes is assumed by
201 default. Do not use GB, MB, or KB.
202 </literallayout>
203 </para>
204
205 <para>
206 Here are some examples:
207 <literallayout class='monospaced'>
208 BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
209 BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
210 BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
211 </literallayout>
212 The first example works only if you also set
213 the <link linkend='var-BB_DISKMON_WARNINTERVAL'><filename>BB_DISKMON_WARNINTERVAL</filename></link> variable.
214 This example causes the build system to immediately
215 abort when either the disk space in <filename>${TMPDIR}</filename> drops
216 below 1 Gbyte or the available free inodes drops below
217 100 Kbytes.
218 Because two directories are provided with the variable, the
219 build system also issues a
220 warning when the disk space in the
221 <filename>${SSTATE_DIR}</filename> directory drops
222 below 1 Gbyte or the number of free inodes drops
223 below 100 Kbytes.
224 Subsequent warnings are issued during intervals as
225 defined by the <filename>BB_DISKMON_WARNINTERVAL</filename>
226 variable.
227 </para>
228
229 <para>
230 The second example stops the build after all currently
231 executing tasks complete when the minimum disk space
232 in the <filename>${TMPDIR}</filename>
233 directory drops below 1 Gbyte.
234 No disk monitoring occurs for the free inodes in this case.
235 </para>
236
237 <para>
238 The final example immediately aborts the build when the
239 number of free inodes in the <filename>${TMPDIR}</filename> directory
240 drops below 100 Kbytes.
241 No disk space monitoring for the directory itself occurs
242 in this case.
243 </para>
244 </glossdef>
245 </glossentry>
246
247 <glossentry id='var-BB_DISKMON_WARNINTERVAL'><glossterm>BB_DISKMON_WARNINTERVAL</glossterm>
248 <glossdef>
249 <para>
250 Defines the disk space and free inode warning intervals.
251 </para>
252
253 <para>
254 If you are going to use the
255 <filename>BB_DISKMON_WARNINTERVAL</filename> variable, you must
256 also use the
257 <link linkend='var-BB_DISKMON_DIRS'><filename>BB_DISKMON_DIRS</filename></link> variable
258 and define its action as "WARN".
259 During the build, subsequent warnings are issued each time
260 disk space or number of free inodes further reduces by
261 the respective interval.
262 </para>
263
264 <para>
265 If you do not provide a <filename>BB_DISKMON_WARNINTERVAL</filename>
266 variable and you do use <filename>BB_DISKMON_DIRS</filename> with
267 the "WARN" action, the disk monitoring interval defaults to
268 the following:
269 <literallayout class='monospaced'>
270 BB_DISKMON_WARNINTERVAL = "50M,5K"
271 </literallayout>
272 </para>
273
274 <para>
275 When specifying the variable in your configuration file,
276 use the following form:
277 <literallayout class='monospaced'>
278 BB_DISKMON_WARNINTERVAL = "&lt;disk_space_interval&gt;,&lt;disk_inode_interval&gt;"
279
280 where:
281
282 &lt;disk_space_interval&gt; is:
283 An interval of memory expressed in either
284 G, M, or K for Gbytes, Mbytes, or Kbytes,
285 respectively. You cannot use GB, MB, or KB.
286
287 &lt;disk_inode_interval&gt; is:
288 An interval of free inodes expressed in either
289 G, M, or K for Gbytes, Mbytes, or Kbytes,
290 respectively. You cannot use GB, MB, or KB.
291 </literallayout>
292 </para>
293
294 <para>
295 Here is an example:
296 <literallayout class='monospaced'>
297 BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
298 BB_DISKMON_WARNINTERVAL = "50M,5K"
299 </literallayout>
300 These variables cause BitBake to
301 issue subsequent warnings each time the available
302 disk space further reduces by 50 Mbytes or the number
303 of free inodes further reduces by 5 Kbytes in the
304 <filename>${SSTATE_DIR}</filename> directory.
305 Subsequent warnings based on the interval occur each time
306 a respective interval is reached beyond the initial warning
307 (i.e. 1 Gbytes and 100 Kbytes).
308 </para>
309 </glossdef>
310 </glossentry>
311
312 <glossentry id='var-BB_ENV_WHITELIST'><glossterm>BB_ENV_WHITELIST</glossterm>
313 <glossdef>
314 <para>
315 Specifies the internal whitelist of variables to allow
316 through from the external environment into BitBake's
317 datastore.
318 If the value of this variable is not specified
319 (which is the default), the following list is used:
320 <link linkend='var-BBPATH'><filename>BBPATH</filename></link>,
321 <link linkend='var-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link>,
322 <link linkend='var-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link>,
323 and
324 <link linkend='var-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link>.
325 <note>
326 You must set this variable in the external environment
327 in order for it to work.
328 </note>
329 </para>
330 </glossdef>
331 </glossentry>
332
333 <glossentry id='var-BB_ENV_EXTRAWHITE'><glossterm>BB_ENV_EXTRAWHITE</glossterm>
334 <glossdef>
335 <para>
336 Specifies an additional set of variables to allow through
337 (whitelist) from the external environment into BitBake's
338 datastore.
339 This list of variables are on top of the internal list
340 set in
341 <link linkend='var-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link>.
342 <note>
343 You must set this variable in the external
344 environment in order for it to work.
345 </note>
346 </para>
347 </glossdef>
348 </glossentry>
349
350 <glossentry id='var-BB_FETCH_PREMIRRORONLY'><glossterm>BB_FETCH_PREMIRRORONLY</glossterm>
351 <glossdef>
352 <para>
353 When set to "1", causes BitBake's fetcher module to only
354 search
355 <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
356 for files.
357 BitBake will not search the main
358 <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
359 or
360 <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>.
361 </para>
362 </glossdef>
363 </glossentry>
364
365 <glossentry id='var-BB_FILENAME'><glossterm>BB_FILENAME</glossterm>
366 <glossdef>
367 <para>
368 Contains the filename of the recipe that owns the currently
369 running task.
370 For example, if the <filename>do_fetch</filename> task that
371 resides in the <filename>my-recipe.bb</filename> is
372 executing, the <filename>BB_FILENAME</filename> variable
373 contains "/foo/path/my-recipe.bb".
374 </para>
375 </glossdef>
376 </glossentry>
377
378 <glossentry id='var-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm>
379 <glossdef>
380 <para>
381 Causes tarballs of the Git repositories, including the
382 Git metadata, to be placed in the
383 <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
384 directory.
385 Anyone wishing to create a source mirror would want to
386 enable this variable.
387 </para>
388
389 <para>
390 For performance reasons, creating and placing tarballs of
391 the Git repositories is not the default action by BitBake.
392 <literallayout class='monospaced'>
393 BB_GENERATE_MIRROR_TARBALLS = "1"
394 </literallayout>
395 </para>
396 </glossdef>
397 </glossentry>
398
399 <glossentry id='var-BB_HASHCONFIG_WHITELIST'><glossterm>BB_HASHCONFIG_WHITELIST</glossterm>
400 <glossdef>
401 <para>
402 Lists variables that are excluded from base configuration
403 checksum, which is used to determine if the cache can
404 be reused.
405 </para>
406
407 <para>
408 One of the ways BitBake determines whether to re-parse the
409 main metadata is through checksums of the variables in the
410 datastore of the base configuration data.
411 There are variables that you typically want to exclude when
412 checking whether or not to re-parse and thus rebuild the
413 cache.
414 As an example, you would usually exclude
415 <filename>TIME</filename> and <filename>DATE</filename>
416 because these variables are always changing.
417 If you did not exclude them, BitBake would never reuse the
418 cache.
419 </para>
420 </glossdef>
421 </glossentry>
422
423 <glossentry id='var-BB_HASHBASE_WHITELIST'><glossterm>BB_HASHBASE_WHITELIST</glossterm>
424 <glossdef>
425 <para>
426 Lists variables that are excluded from checksum and
427 dependency data.
428 Variables that are excluded can therefore change without
429 affecting the checksum mechanism.
430 A common example would be the variable for the path of
431 the build.
432 BitBake's output should not (and usually does not) depend
433 on the directory in which it was built.
434 </para>
435 </glossdef>
436 </glossentry>
437
438 <glossentry id='var-BB_HASHCHECK_FUNCTION'><glossterm>BB_HASHCHECK_FUNCTION</glossterm>
439 <glossdef>
440 <para>
441 Specifies the name of the function to call during the
442 "setscene" part of the task's execution in order to
443 validate the list of task hashes.
444 The function returns the list of setscene tasks that should
445 be executed.
446 </para>
447
448 <para>
449 At this point in the execution of the code, the objective
450 is to quickly verify if a given setscene function is likely
451 to work or not.
452 It's easier to check the list of setscene functions in
453 one pass than to call many individual tasks.
454 The returned list need not be completely accurate.
455 A given setscene task can still later fail.
456 However, the more accurate the data returned, the more
457 efficient the build will be.
458 </para>
459 </glossdef>
460 </glossentry>
461
462 <glossentry id='var-BB_INVALIDCONF'><glossterm>BB_INVALIDCONF</glossterm>
463 <glossdef>
464 <para>
465 Used in combination with the
466 <filename>ConfigParsed</filename> event to trigger
467 re-parsing the base metadata (i.e. all the
468 recipes).
469 The <filename>ConfigParsed</filename> event can set the
470 variable to trigger the re-parse.
471 You must be careful to avoid recursive loops with this
472 functionality.
473 </para>
474 </glossdef>
475 </glossentry>
476
477 <glossentry id='var-BB_LOGFMT'><glossterm>BB_LOGFMT</glossterm>
478 <glossdef>
479 <para>
480 Specifies the name of the log files saved into
481 <filename>${</filename><link linkend='var-T'><filename>T</filename></link><filename>}</filename>.
482 By default, the <filename>BB_LOGFMT</filename> variable
483 is undefined and the log file names get created using the
484 following form:
485 <literallayout class='monospaced'>
486 log.{task}.{pid}
487 </literallayout>
488 If you want to force log files to take a specific name,
489 you can set this variable in a configuration file.
490 </para>
491 </glossdef>
492 </glossentry>
493
494 <glossentry id='var-BB_NICE_LEVEL'><glossterm>BB_NICE_LEVEL</glossterm>
495 <glossdef>
496 <para>
497 Allows BitBake to run at a specific priority
498 (i.e. nice level).
499 System permissions usually mean that BitBake can reduce its
500 priority but not raise it again.
501 See
502 <link linkend='var-BB_TASK_NICE_LEVEL'><filename>BB_TASK_NICE_LEVEL</filename></link>
503 for additional information.
504 </para>
505 </glossdef>
506 </glossentry>
507
508 <glossentry id='var-BB_NO_NETWORK'><glossterm>BB_NO_NETWORK</glossterm>
509 <glossdef>
510 <para>
511 Disables network access in the BitBake fetcher modules.
512 With this access disabled, any command that attempts to
513 access the network becomes an error.
514 </para>
515
516 <para>
517 Disabling network access is useful for testing source
518 mirrors, running builds when not connected to the Internet,
519 and when operating in certain kinds of firewall
520 environments.
521 </para>
522 </glossdef>
523 </glossentry>
524
525 <glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
526 <glossdef>
527 <para>
528 The maximum number of tasks BitBake should run in parallel
529 at any one time.
530 If your host development system supports multiple cores,
531 a good rule of thumb is to set this variable to twice the
532 number of cores.
533 </para>
534 </glossdef>
535 </glossentry>
536
537 <glossentry id='var-BB_NUMBER_PARSE_THREADS'><glossterm>BB_NUMBER_PARSE_THREADS</glossterm>
538 <glossdef>
539 <para>
540 Sets the number of threads BitBake uses when parsing.
541 By default, the number of threads is equal to the number
542 of cores on the system.
543 </para>
544 </glossdef>
545 </glossentry>
546
547 <glossentry id='var-BB_ORIGENV'><glossterm>BB_ORIGENV</glossterm>
548 <glossdef>
549 <para>
550 Contains a copy of the original external environment in
551 which BitBake was run.
552 The copy is taken before any whitelisted variable values
553 are filtered into BitBake's datastore.
554 <note>
555 The contents of this variable is a datastore object
556 that can be queried using the normal datastore
557 operations.
558 </note>
559 </para>
560 </glossdef>
561 </glossentry>
562
563 <glossentry id='var-BB_PRESERVE_ENV'><glossterm>BB_PRESERVE_ENV</glossterm>
564 <glossdef>
565 <para>
566 Disables whitelisting and instead allows all variables
567 through from the external environment into BitBake's
568 datastore.
569 <note>
570 You must set this variable in the external
571 environment in order for it to work.
572 </note>
573 </para>
574 </glossdef>
575 </glossentry>
576
577 <glossentry id='var-BB_RUNFMT'><glossterm>BB_RUNFMT</glossterm>
578 <glossdef>
579 <para>
580 Specifies the name of the executable script files
581 (i.e. run files) saved into
582 <filename>${</filename><link linkend='var-T'><filename>T</filename></link><filename>}</filename>.
583 By default, the <filename>BB_RUNFMT</filename> variable
584 is undefined and the run file names get created using the
585 following form:
586 <literallayout class='monospaced'>
587 run.{task}.{pid}
588 </literallayout>
589 If you want to force run files to take a specific name,
590 you can set this variable in a configuration file.
591 </para>
592 </glossdef>
593 </glossentry>
594
595 <glossentry id='var-BB_RUNTASK'><glossterm>BB_RUNTASK</glossterm>
596 <glossdef>
597 <para>
598 Contains the name of the currently executing task.
599 The value does not include the "do_" prefix.
600 For example, if the currently executing task is
601 <filename>do_config</filename>, the value is
602 "config".
603 </para>
604 </glossdef>
605 </glossentry>
606
607 <glossentry id='var-BB_SCHEDULER'><glossterm>BB_SCHEDULER</glossterm>
608 <glossdef>
609 <para>
610 Selects the name of the scheduler to use for the
611 scheduling of BitBake tasks.
612 Three options exist:
613 <itemizedlist>
614 <listitem><para><emphasis>basic</emphasis> -
615 The basic framework from which everything derives.
616 Using this option causes tasks to be ordered
617 numerically as they are parsed.
618 </para></listitem>
619 <listitem><para><emphasis>speed</emphasis> -
620 Executes tasks first that have more tasks
621 depending on them.
622 The "speed" option is the default.
623 </para></listitem>
624 <listitem><para><emphasis>completion</emphasis> -
625 Causes the scheduler to try to complete a given
626 recipe once its build has started.
627 </para></listitem>
628 </itemizedlist>
629 </para>
630 </glossdef>
631 </glossentry>
632
633 <glossentry id='var-BB_SCHEDULERS'><glossterm>BB_SCHEDULERS</glossterm>
634 <glossdef>
635 <para>
636 Defines custom schedulers to import.
637 Custom schedulers need to be derived from the
638 <filename>RunQueueScheduler</filename> class.
639 </para>
640
641 <para>
642 For information how to select a scheduler, see the
643 <link linkend='var-BB_SCHEDULER'><filename>BB_SCHEDULER</filename></link>
644 variable.
645 </para>
646 </glossdef>
647 </glossentry>
648
649 <glossentry id='var-BB_SETSCENE_DEPVALID'><glossterm>BB_SETSCENE_DEPVALID</glossterm>
650 <glossdef>
651 <para>
652 Specifies a function BitBake calls that determines
653 whether BitBake requires a setscene dependency to be met.
654 </para>
655
656 <para>
657 When running a setscene task, BitBake needs to
658 know which dependencies of that setscene task also need
659 to be run.
660 Whether dependencies also need to be run is highly
661 dependent on the metadata.
662 The function specified by this variable returns a
663 "True" or "False" depending on whether the dependency needs
664 to be met.
665 </para>
666 </glossdef>
667 </glossentry>
668
669 <glossentry id='var-BB_SETSCENE_VERIFY_FUNCTION'><glossterm>BB_SETSCENE_VERIFY_FUNCTION</glossterm>
670 <glossdef>
671 <para>
672 Specifies a function to call that verifies the list of
673 planned task execution before the main task execution
674 happens.
675 The function is called once BitBake has a list of setscene
676 tasks that have run and either succeeded or failed.
677 </para>
678
679 <para>
680 The function allows for a task list check to see if they
681 make sense.
682 Even if BitBake was planning to skip a task, the
683 returned value of the function can force BitBake to run
684 the task, which is necessary under certain metadata
685 defined circumstances.
686 </para>
687 </glossdef>
688 </glossentry>
689
690 <glossentry id='var-BB_SIGNATURE_EXCLUDE_FLAGS'><glossterm>BB_SIGNATURE_EXCLUDE_FLAGS</glossterm>
691 <glossdef>
692 <para>
693 Lists variable flags (varflags)
694 that can be safely excluded from checksum
695 and dependency data for keys in the datastore.
696 When generating checksum or dependency data for keys in the
697 datastore, the flags set against that key are normally
698 included in the checksum.
699 </para>
700
701 <para>
702 For more information on varflags, see the
703 "<link linkend='variable-flags'>Variable Flags</link>"
704 section.
705 </para>
706 </glossdef>
707 </glossentry>
708
709 <glossentry id='var-BB_SIGNATURE_HANDLER'><glossterm>BB_SIGNATURE_HANDLER</glossterm>
710 <glossdef>
711 <para>
712 Defines the name of the signature handler BitBake uses.
713 The signature handler defines the way stamp files are
714 created and handled, if and how the signature is
715 incorporated into the stamps, and how the signature
716 itself is generated.
717 </para>
718
719 <para>
720 A new signature handler can be added by injecting a class
721 derived from the
722 <filename>SignatureGenerator</filename> class into the
723 global namespace.
724 </para>
725 </glossdef>
726 </glossentry>
727
728 <glossentry id='var-BB_SRCREV_POLICY'><glossterm>BB_SRCREV_POLICY</glossterm>
729 <glossdef>
730 <para>
731 Defines the behavior of the fetcher when it interacts with
732 source control systems and dynamic source revisions.
733 The <filename>BB_SRCREV_POLICY</filename> variable is
734 useful when working without a network.
735 </para>
736
737 <para>
738 The variable can be set using one of two policies:
739 <itemizedlist>
740 <listitem><para><emphasis>cache</emphasis> -
741 Retains the value the system obtained previously
742 rather than querying the source control system
743 each time.
744 </para></listitem>
745 <listitem><para><emphasis>clear</emphasis> -
746 Queries the source controls system every time.
747 With this policy, there is no cache.
748 The "clear" policy is the default.
749 </para></listitem>
750 </itemizedlist>
751 </para>
752 </glossdef>
753 </glossentry>
754
755 <glossentry id='var-BB_STAMP_POLICY'><glossterm>BB_STAMP_POLICY</glossterm>
756 <glossdef>
757 <para>
758 Defines the mode used for how timestamps of stamp files
759 are compared.
760 You can set the variable to one of the following modes:
761 <itemizedlist>
762 <listitem><para><emphasis>perfile</emphasis> -
763 Timestamp comparisons are only made
764 between timestamps of a specific recipe.
765 This is the default mode.
766 </para></listitem>
767 <listitem><para><emphasis>full</emphasis> -
768 Timestamp comparisons are made for all
769 dependencies.
770 </para></listitem>
771 <listitem><para><emphasis>whitelist</emphasis> -
772 Identical to "full" mode except timestamp
773 comparisons are made for recipes listed in the
774 <link linkend='var-BB_STAMP_WHITELIST'><filename>BB_STAMP_WHITELIST</filename></link>
775 variable.
776 </para></listitem>
777 </itemizedlist>
778 <note>
779 Stamp policies are largely obsolete with the
780 introduction of setscene tasks.
781 </note>
782 </para>
783 </glossdef>
784 </glossentry>
785
786 <glossentry id='var-BB_STAMP_WHITELIST'><glossterm>BB_STAMP_WHITELIST</glossterm>
787 <glossdef>
788 <para>
789 Lists files whose stamp file timestamps are compared when
790 the stamp policy mode is set to "whitelist".
791 For information on stamp policies, see the
792 <link linkend='var-BB_STAMP_POLICY'><filename>BB_STAMP_POLICY</filename></link>
793 variable.
794 </para>
795 </glossdef>
796 </glossentry>
797
798 <glossentry id='var-BB_STRICT_CHECKSUM'><glossterm>BB_STRICT_CHECKSUM</glossterm>
799 <glossdef>
800 <para>
801 Sets a more strict checksum mechanism for non-local URLs.
802 Setting this variable to a value causes BitBake
803 to report an error if it encounters a non-local URL
804 that does not have at least one checksum specified.
805 </para>
806 </glossdef>
807 </glossentry>
808
809 <glossentry id='var-BB_TASK_NICE_LEVEL'><glossterm>BB_TASK_NICE_LEVEL</glossterm>
810 <glossdef>
811 <para>
812 Allows specific tasks to change their priority
813 (i.e. nice level).
814 </para>
815
816 <para>
817 You can use this variable in combination with task
818 overrides to raise or lower priorities of specific tasks.
819 For example, on the
820 <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink>
821 autobuilder, QEMU emulation in images is given a higher
822 priority as compared to build tasks to ensure that images
823 do not suffer timeouts on loaded systems.
824 </para>
825 </glossdef>
826 </glossentry>
827
828 <glossentry id='var-BB_TASKHASH'><glossterm>BB_TASKHASH</glossterm>
829 <glossdef>
830 <para>
831 Within an executing task, this variable holds the hash
832 of the task as returned by the currently enabled
833 signature generator.
834 </para>
835 </glossdef>
836 </glossentry>
837
838 <glossentry id='var-BB_VERBOSE_LOGS'><glossterm>BB_VERBOSE_LOGS</glossterm>
839 <glossdef>
840 <para>
841 Controls how verbose BitBake is during builds.
842 If set, shell scripts echo commands and shell script output
843 appears on standard out (stdout).
844 </para>
845 </glossdef>
846 </glossentry>
847
848 <glossentry id='var-BB_WORKERCONTEXT'><glossterm>BB_WORKERCONTEXT</glossterm>
849 <glossdef>
850 <para>
851 Specifies if the current context is executing a task.
852 BitBake sets this variable to "1" when a task is
853 being executed.
854 The value is not set when the task is in server context
855 during parsing or event handling.
856 </para>
857 </glossdef>
858 </glossentry>
859
860
861 <glossentry id='var-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm>
862 <glossdef>
863 <para>
864 Allows you to extend a recipe so that it builds variants
865 of the software.
866 Some examples of these variants for recipes from the
867 OpenEmbedded Core metadata are "natives" such as
868 <filename>quilt-native</filename>, which is a copy of
869 Quilt built to run on the build system; "crosses" such
870 as <filename>gcc-cross</filename>, which is a compiler
871 built to run on the build machine but produces binaries
872 that run on the target <filename>MACHINE</filename>;
873 "nativesdk", which targets the SDK machine instead of
874 <filename>MACHINE</filename>; and "mulitlibs" in the form
875 "<filename>multilib:&lt;multilib_name&gt;</filename>".
876 </para>
877
878 <para>
879 To build a different variant of the recipe with a minimal
880 amount of code, it usually is as simple as adding the
881 variable to your recipe.
882 Here are two examples.
883 The "native" variants are from the OpenEmbedded Core
884 metadata:
885 <literallayout class='monospaced'>
886 BBCLASSEXTEND =+ "native nativesdk"
887 BBCLASSEXTEND =+ "multilib:&lt;multilib_name&gt;"
888 </literallayout>
889 </para>
890 </glossdef>
891 </glossentry>
892
893 <glossentry id='var-BBDEBUG'><glossterm>BBDEBUG</glossterm>
894 <glossdef>
895 <para>
896 Sets the BitBake debug output level to a specific value
897 as incremented by the <filename>-d</filename> command line
898 option.
899 <note>
900 You must set this variable in the external environment
901 in order for it to work.
902 </note>
903 </para>
904 </glossdef>
905 </glossentry>
906
907 <glossentry id='var-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm>
908 <glossdef>
909 <para>Lists the names of configured layers.
910 These names are used to find the other <filename>BBFILE_*</filename>
911 variables.
912 Typically, each layer appends its name to this variable in its
913 <filename>conf/layer.conf</filename> file.
914 </para>
915 </glossdef>
916 </glossentry>
917
918 <glossentry id='var-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm>
919 <glossdef>
920 <para>Variable that expands to match files from
921 <link linkend='var-BBFILES'><filename>BBFILES</filename></link>
922 in a particular layer.
923 This variable is used in the <filename>conf/layer.conf</filename> file and must
924 be suffixed with the name of the specific layer (e.g.
925 <filename>BBFILE_PATTERN_emenlow</filename>).</para>
926 </glossdef>
927 </glossentry>
928
929 <glossentry id='var-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm>
930 <glossdef>
931 <para>Assigns the priority for recipe files in each layer.</para>
932 <para>This variable is useful in situations where the same recipe appears in
933 more than one layer.
934 Setting this variable allows you to prioritize a
935 layer against other layers that contain the same recipe - effectively
936 letting you control the precedence for the multiple layers.
937 The precedence established through this variable stands regardless of a
938 recipe's version
939 (<link linkend='var-PV'><filename>PV</filename></link> variable).
940 For example, a layer that has a recipe with a higher <filename>PV</filename> value but for
941 which the <filename>BBFILE_PRIORITY</filename> is set to have a lower precedence still has a
942 lower precedence.</para>
943 <para>A larger value for the <filename>BBFILE_PRIORITY</filename> variable results in a higher
944 precedence.
945 For example, the value 6 has a higher precedence than the value 5.
946 If not specified, the <filename>BBFILE_PRIORITY</filename> variable is set based on layer
947 dependencies (see the
948 <filename><link linkend='var-LAYERDEPENDS'>LAYERDEPENDS</link></filename> variable for
949 more information.
950 The default priority, if unspecified
951 for a layer with no dependencies, is the lowest defined priority + 1
952 (or 1 if no priorities are defined).</para>
953 <tip>
954 You can use the command <filename>bitbake-layers show-layers</filename> to list
955 all configured layers along with their priorities.
956 </tip>
957 </glossdef>
958 </glossentry>
959
960 <glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm>
961 <glossdef>
962 <para>List of recipe files BitBake uses to build software.</para>
963 </glossdef>
964 </glossentry>
965
966 <glossentry id='var-BBINCLUDED'><glossterm>BBINCLUDED</glossterm>
967 <glossdef>
968 <para>
969 Contains a space-separated list of all of all files that
970 BitBake's parser included during parsing of the current
971 file.
972 </para>
973 </glossdef>
974 </glossentry>
975
976 <glossentry id='var-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm>
977 <glossdef>
978 <para>
979 If set to a value, enables printing the task log when
980 reporting a failed task.
981 </para>
982 </glossdef>
983 </glossentry>
984
985 <glossentry id='var-BBINCLUDELOGS_LINES'><glossterm>BBINCLUDELOGS_LINES</glossterm>
986 <glossdef>
987 <para>
988 If
989 <link linkend='var-BBINCLUDELOGS'><filename>BBINCLUDELOGS</filename></link>
990 is set, specifies the maximum number of lines from the
991 task log file to print when reporting a failed task.
992 If you do not set <filename>BBINCLUDELOGS_LINES</filename>,
993 the entire log is printed.
994 </para>
995 </glossdef>
996 </glossentry>
997
998 <glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm>
999 <glossdef>
1000 <para>Lists the layers to enable during the build.
1001 This variable is defined in the <filename>bblayers.conf</filename> configuration
1002 file in the build directory.
1003 Here is an example:
1004 <literallayout class='monospaced'>
1005 BBLAYERS = " \
1006 /home/scottrif/poky/meta \
1007 /home/scottrif/poky/meta-yocto \
1008 /home/scottrif/poky/meta-yocto-bsp \
1009 /home/scottrif/poky/meta-mykernel \
1010 "
1011
1012 </literallayout>
1013 This example enables four layers, one of which is a custom, user-defined layer
1014 named <filename>meta-mykernel</filename>.
1015 </para>
1016 </glossdef>
1017 </glossentry>
1018
1019 <glossentry id='var-BBMASK'><glossterm>BBMASK</glossterm>
1020 <glossdef>
1021 <para>
1022 Prevents BitBake from processing recipes and recipe
1023 append files.
1024 </para>
1025
1026 <para>
1027 You can use the <filename>BBMASK</filename> variable
1028 to "hide" these <filename>.bb</filename> and
1029 <filename>.bbappend</filename> files.
1030 BitBake ignores any recipe or recipe append files that
1031 match the expression.
1032 It is as if BitBake does not see them at all.
1033 Consequently, matching files are not parsed or otherwise
1034 used by BitBake.</para>
1035 <para>
1036 The value you provide is passed to Python's regular
1037 expression compiler.
1038 The expression is compared against the full paths to
1039 the files.
1040 For complete syntax information, see Python's
1041 documentation at
1042 <ulink url='http://docs.python.org/release/2.3/lib/re-syntax.html'></ulink>.
1043 </para>
1044
1045 <para>
1046 The following example uses a complete regular expression
1047 to tell BitBake to ignore all recipe and recipe append
1048 files in the <filename>meta-ti/recipes-misc/</filename>
1049 directory:
1050 <literallayout class='monospaced'>
1051 BBMASK = "meta-ti/recipes-misc/"
1052 </literallayout>
1053 If you want to mask out multiple directories or recipes,
1054 use the vertical bar to separate the regular expression
1055 fragments.
1056 This next example masks out multiple directories and
1057 individual recipes:
1058 <literallayout class='monospaced'>
1059 BBMASK = "meta-ti/recipes-misc/|meta-ti/recipes-ti/packagegroup/"
1060 BBMASK .= "|.*meta-oe/recipes-support/"
1061 BBMASK .= "|.*openldap"
1062 BBMASK .= "|.*opencv"
1063 BBMASK .= "|.*lzma"
1064 </literallayout>
1065 Notice how the vertical bar is used to append the fragments.
1066 <note>
1067 When specifying a directory name, use the trailing
1068 slash character to ensure you match just that directory
1069 name.
1070 </note>
1071 </para>
1072 </glossdef>
1073 </glossentry>
1074
1075 <glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm>
1076 <glossdef>
1077 <para>
1078 Used by BitBake to locate class
1079 (<filename>.bbclass</filename>) and configuration
1080 (<filename>.conf</filename>) files.
1081 This variable is analogous to the
1082 <filename>PATH</filename> variable.
1083 </para>
1084
1085 <para>
1086 If you run BitBake from a directory outside of the
1087 build directory,
1088 you must be sure to set
1089 <filename>BBPATH</filename> to point to the
1090 build directory.
1091 Set the variable as you would any environment variable
1092 and then run BitBake:
1093 <literallayout class='monospaced'>
1094 $ BBPATH="&lt;build_directory&gt;"
1095 $ export BBPATH
1096 $ bitbake &lt;target&gt;
1097 </literallayout>
1098 </para>
1099 </glossdef>
1100 </glossentry>
1101
1102 <glossentry id='var-BBSERVER'><glossterm>BBSERVER</glossterm>
1103 <glossdef>
1104 <para>
1105 Points to the server that runs memory-resident BitBake.
1106 The variable is only used when you employ memory-resident
1107 BitBake.
1108 </para>
1109 </glossdef>
1110 </glossentry>
1111
1112 <glossentry id='var-BBVERSIONS'><glossterm>BBVERSIONS</glossterm>
1113 <glossdef>
1114 <para>
1115 Allows a single recipe to build multiple versions of a
1116 project from a single recipe file.
1117 You also able to specify conditional metadata
1118 using the
1119 <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
1120 mechanism for a single version or for an optionally named
1121 range of versions.
1122 </para>
1123
1124 <para>
1125 For more information on <filename>BBVERSIONS</filename>,
1126 see the
1127 "<link linkend='variants-class-extension-mechanism'>Variants - Class Extension Mechanism</link>"
1128 section.
1129 </para>
1130 </glossdef>
1131 </glossentry>
1132
1133 <glossentry id='var-BITBAKE_UI'><glossterm>BITBAKE_UI</glossterm>
1134 <glossdef>
1135 <para>
1136 Used to specify the UI module to use when running BitBake.
1137 Using this variable is equivalent to using the
1138 <filename>-u</filename> command-line option.
1139 <note>
1140 You must set this variable in the external environment
1141 in order for it to work.
1142 </note>
1143 </para>
1144 </glossdef>
1145 </glossentry>
1146
1147 <glossentry id='var-BUILDNAME'><glossterm>BUILDNAME</glossterm>
1148 <glossdef>
1149 <para>
1150 A name assigned to the build.
1151 The name defaults to a datetime stamp of when the build was
1152 started but can be defined by the metadata.
1153 </para>
1154 </glossdef>
1155 </glossentry>
1156
1157 </glossdiv>
1158
1159 <glossdiv id='var-glossary-c'><title>C</title>
1160
1161 <glossentry id='var-CACHE'><glossterm>CACHE</glossterm>
1162 <glossdef>
1163 <para>
1164 Specifies the directory BitBake uses to store a cache
1165 of the metadata so it does not need to be parsed every
1166 time BitBake is started.
1167 </para>
1168 </glossdef>
1169 </glossentry>
1170
1171 </glossdiv>
1172
1173 <glossdiv id='var-glossary-d'><title>D</title>
1174
1175 <glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
1176 <glossdef>
1177 <para>
1178 Specifies a weak bias for recipe selection priority.
1179 </para>
1180 <para>
1181 The most common usage of this is variable is to set
1182 it to "-1" within a recipe for a development version of a
1183 piece of software.
1184 Using the variable in this way causes the stable version
1185 of the recipe to build by default in the absence of
1186 <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
1187 being used to build the development version.
1188 </para>
1189 <note>
1190 The bias provided by <filename>DEFAULT_PREFERENCE</filename>
1191 is weak and is overridden by
1192 <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename>
1193 if that variable is different between two layers
1194 that contain different versions of the same recipe.
1195 </note>
1196 </glossdef>
1197 </glossentry>
1198
1199 <glossentry id='var-DEPENDS'><glossterm>DEPENDS</glossterm>
1200 <glossdef>
1201 <para>
1202 Lists a recipe's build-time dependencies
1203 (i.e. other recipe files).
1204 </para>
1205
1206 <para>
1207 Consider this simple example for two recipes named "a" and
1208 "b" that produce similarly named packages.
1209 In this example, the <filename>DEPENDS</filename>
1210 statement appears in the "a" recipe:
1211 <literallayout class='monospaced'>
1212 DEPENDS = "b"
1213 </literallayout>
1214 Here, the dependency is such that the
1215 <filename>do_configure</filename> task for recipe "a"
1216 depends on the <filename>do_populate_sysroot</filename>
1217 task of recipe "b".
1218 This means anything that recipe "b" puts into sysroot
1219 is available when recipe "a" is configuring itself.
1220 </para>
1221
1222 <para>
1223 For information on runtime dependencies, see the
1224 <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
1225 variable.
1226 </para>
1227 </glossdef>
1228 </glossentry>
1229
1230 <glossentry id='var-DESCRIPTION'><glossterm>DESCRIPTION</glossterm>
1231 <glossdef>
1232 <para>
1233 A long description for the recipe.
1234 </para>
1235 </glossdef>
1236 </glossentry>
1237
1238 <glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
1239 <glossdef>
1240 <para>
1241 The central download directory used by the build process to
1242 store downloads.
1243 By default, <filename>DL_DIR</filename> gets files
1244 suitable for mirroring for everything except Git
1245 repositories.
1246 If you want tarballs of Git repositories, use the
1247 <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
1248 variable.
1249 </para>
1250 </glossdef>
1251
1252 </glossentry>
1253 </glossdiv>
1254
1255 <glossdiv id='var-glossary-e'><title>E</title>
1256
1257 <glossentry id='var-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm>
1258 <glossdef>
1259 <para>
1260 Directs BitBake to exclude a recipe from world builds (i.e.
1261 <filename>bitbake world</filename>).
1262 During world builds, BitBake locates, parses and builds all
1263 recipes found in every layer exposed in the
1264 <filename>bblayers.conf</filename> configuration file.
1265 </para>
1266
1267 <para>
1268 To exclude a recipe from a world build using this variable,
1269 set the variable to "1" in the recipe.
1270 </para>
1271
1272 <note>
1273 Recipes added to <filename>EXCLUDE_FROM_WORLD</filename>
1274 may still be built during a world build in order to satisfy
1275 dependencies of other recipes.
1276 Adding a recipe to <filename>EXCLUDE_FROM_WORLD</filename>
1277 only ensures that the recipe is not explicitly added
1278 to the list of build targets in a world build.
1279 </note>
1280 </glossdef>
1281 </glossentry>
1282
1283 </glossdiv>
1284
1285 <glossdiv id='var-glossary-f'><title>F</title>
1286
1287 <glossentry id='var-FAKEROOT'><glossterm>FAKEROOT</glossterm>
1288 <glossdef>
1289 <para>
1290 Contains the command to use when running a shell script
1291 in a fakeroot environment.
1292 The <filename>FAKEROOT</filename> variable is obsolete
1293 and has been replaced by the other
1294 <filename>FAKEROOT*</filename> variables.
1295 See these entries in the glossary for more information.
1296 </para>
1297 </glossdef>
1298 </glossentry>
1299
1300 <glossentry id='var-FAKEROOTBASEENV'><glossterm>FAKEROOTBASEENV</glossterm>
1301 <glossdef>
1302 <para>
1303 Lists environment variables to set when executing
1304 the command defined by
1305 <link linkend='var-FAKEROOTCMD'><filename>FAKEROOTCMD</filename></link>
1306 that starts the bitbake-worker process
1307 in the fakeroot environment.
1308 </para>
1309 </glossdef>
1310 </glossentry>
1311
1312 <glossentry id='var-FAKEROOTCMD'><glossterm>FAKEROOTCMD</glossterm>
1313 <glossdef>
1314 <para>
1315 Contains the command that starts the bitbake-worker
1316 process in the fakeroot environment.
1317 </para>
1318 </glossdef>
1319 </glossentry>
1320
1321 <glossentry id='var-FAKEROOTDIRS'><glossterm>FAKEROOTDIRS</glossterm>
1322 <glossdef>
1323 <para>
1324 Lists directories to create before running a task in
1325 the fakeroot environment.
1326 </para>
1327 </glossdef>
1328 </glossentry>
1329
1330 <glossentry id='var-FAKEROOTENV'><glossterm>FAKEROOTENV</glossterm>
1331 <glossdef>
1332 <para>
1333 Lists environment variables to set when running a task
1334 in the fakeroot environment.
1335 For additional information on environment variables and
1336 the fakeroot environment, see the
1337 <link linkend='var-FAKEROOTBASEENV'><filename>FAKEROOTBASEENV</filename></link>
1338 variable.
1339 </para>
1340 </glossdef>
1341 </glossentry>
1342
1343 <glossentry id='var-FAKEROOTNOENV'><glossterm>FAKEROOTNOENV</glossterm>
1344 <glossdef>
1345 <para>
1346 Lists environment variables to set when running a task
1347 that is not in the fakeroot environment.
1348 For additional information on environment variables and
1349 the fakeroot environment, see the
1350 <link linkend='var-FAKEROOTENV'><filename>FAKEROOTENV</filename></link>
1351 variable.
1352 </para>
1353 </glossdef>
1354 </glossentry>
1355
1356 <glossentry id='var-FETCHCMD'><glossterm>FETCHCMD</glossterm>
1357 <glossdef>
1358 <para>
1359 Defines the command the BitBake fetcher module
1360 executes when running fetch operations.
1361 You need to use an override suffix when you use the
1362 variable (e.g. <filename>FETCHCMD_git</filename>
1363 or <filename>FETCHCMD_svn</filename>).
1364 </para>
1365 </glossdef>
1366 </glossentry>
1367
1368 <glossentry id='var-FILE'><glossterm>FILE</glossterm>
1369 <glossdef>
1370 <para>
1371 Points at the current file.
1372 BitBake sets this variable during the parsing process
1373 to identify the file being parsed.
1374 BitBake also sets this variable when a recipe is being
1375 executed to identify the recipe file.
1376 </para>
1377 </glossdef>
1378 </glossentry>
1379
1380 <glossentry id='var-FILESDIR'><glossterm>FILESDIR</glossterm>
1381 <glossdef>
1382 <para>
1383 Specifies directories BitBake uses when searching for
1384 patches and files.
1385 The "local" fetcher module uses these directories when
1386 handling <filename>file://</filename> URLs if the file
1387 was not found using
1388 <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>.
1389 <note>
1390 The <filename>FILESDIR</filename> variable is
1391 deprecated and you should use
1392 <filename>FILESPATH</filename> in all new code.
1393 </note>
1394 </para>
1395 </glossdef>
1396 </glossentry>
1397
1398 <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
1399 <glossdef>
1400 <para>
1401 Specifies directories BitBake uses when searching for
1402 patches and files.
1403 The "local" fetcher module uses these directories when
1404 handling <filename>file://</filename> URLs.
1405 The variable behaves like a shell <filename>PATH</filename>
1406 environment variable.
1407 The value is a colon-separated list of directories that
1408 are searched left-to-right in order.
1409 </para>
1410 </glossdef>
1411 </glossentry>
1412
1413 </glossdiv>
1414
1415<!--
1416 <glossdiv id='var-glossary-g'><title>G</title>
1417 </glossdiv>
1418-->
1419
1420 <glossdiv id='var-glossary-h'><title>H</title>
1421
1422 <glossentry id='var-HOMEPAGE'><glossterm>HOMEPAGE</glossterm>
1423 <glossdef>
1424 <para>Website where more information about the software the recipe is building
1425 can be found.</para>
1426 </glossdef>
1427 </glossentry>
1428
1429 </glossdiv>
1430
1431 <glossdiv id='var-glossary-i'><title>I</title>
1432
1433 <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
1434 <glossdef>
1435 <para>
1436 Causes the named class to be inherited at
1437 this point during parsing.
1438 The variable is only valid in configuration files.
1439 </para>
1440 </glossdef>
1441 </glossentry>
1442
1443 </glossdiv>
1444
1445<!--
1446 <glossdiv id='var-glossary-j'><title>J</title>
1447 </glossdiv>
1448
1449 <glossdiv id='var-glossary-k'><title>K</title>
1450 </glossdiv>
1451-->
1452
1453 <glossdiv id='var-glossary-l'><title>L</title>
1454
1455 <glossentry id='var-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm>
1456 <glossdef>
1457 <para>Lists the layers, separated by spaces, upon which this recipe depends.
1458 Optionally, you can specify a specific layer version for a dependency
1459 by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3"
1460 to be compared against
1461 <link linkend='var-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename>
1462 in this case).
1463 BitBake produces an error if any dependency is missing or
1464 the version numbers do not match exactly (if specified).</para>
1465 <para>
1466 You use this variable in the <filename>conf/layer.conf</filename> file.
1467 You must also use the specific layer name as a suffix
1468 to the variable (e.g. <filename>LAYERDEPENDS_mylayer</filename>).</para>
1469 </glossdef>
1470 </glossentry>
1471
1472 <glossentry id='var-LAYERDIR'><glossterm>LAYERDIR</glossterm>
1473 <glossdef>
1474 <para>When used inside the <filename>layer.conf</filename> configuration
1475 file, this variable provides the path of the current layer.
1476 This variable is not available outside of <filename>layer.conf</filename>
1477 and references are expanded immediately when parsing of the file completes.</para>
1478 </glossdef>
1479 </glossentry>
1480
1481 <glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
1482 <glossdef>
1483 <para>Optionally specifies the version of a layer as a single number.
1484 You can use this variable within
1485 <link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link>
1486 for another layer in order to depend on a specific version
1487 of the layer.</para>
1488 <para>
1489 You use this variable in the <filename>conf/layer.conf</filename> file.
1490 You must also use the specific layer name as a suffix
1491 to the variable (e.g. <filename>LAYERDEPENDS_mylayer</filename>).</para>
1492 </glossdef>
1493 </glossentry>
1494
1495 <glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
1496 <glossdef>
1497 <para>
1498 The list of source licenses for the recipe.
1499 </para>
1500 </glossdef>
1501 </glossentry>
1502
1503 </glossdiv>
1504
1505 <glossdiv id='var-glossary-m'><title>M</title>
1506
1507 <glossentry id='var-MIRRORS'><glossterm>MIRRORS</glossterm>
1508 <glossdef>
1509 <para>
1510 Specifies additional paths from which BitBake gets source code.
1511 When the build system searches for source code, it first
1512 tries the local download directory.
1513 If that location fails, the build system tries locations
1514 defined by
1515 <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>,
1516 the upstream source, and then locations specified by
1517 <filename>MIRRORS</filename> in that order.
1518 </para>
1519 </glossdef>
1520 </glossentry>
1521
1522 <glossentry id='var-MULTI_PROVIDER_WHITELIST'><glossterm>MULTI_PROVIDER_WHITELIST</glossterm>
1523 <glossdef>
1524 <para>
1525 Allows you to suppress BitBake warnings caused when
1526 building two separate recipes that provide the same
1527 output.
1528 </para>
1529
1530 <para>
1531 Bitbake normally issues a warning when building two
1532 different recipes where each provides the same output.
1533 This scenario is usually something the user does not
1534 want.
1535 However, cases do exist where it makes sense, particularly
1536 in the <filename>virtual/*</filename> namespace.
1537 You can use this variable to suppress BitBake's warnings.
1538 </para>
1539
1540 <para>
1541 To use the variable, list provider names (e.g.
1542 recipe names, <filename>virtual/kernel</filename>,
1543 and so forth).
1544 </para>
1545 </glossdef>
1546 </glossentry>
1547
1548 </glossdiv>
1549
1550<!--
1551 <glossdiv id='var-glossary-n'><title>N</title>
1552 </glossdiv>
1553-->
1554
1555 <glossdiv id='var-glossary-o'><title>O</title>
1556
1557 <glossentry id='var-OVERRIDES'><glossterm>OVERRIDES</glossterm>
1558 <glossdef>
1559 <para>
1560 BitBake uses <filename>OVERRIDES</filename> to control
1561 what variables are overridden after BitBake parses
1562 recipes and configuration files.
1563 You can find more information on how overrides are handled
1564 in the
1565 "<link linkend='conditional-syntax-overrides'>Conditional Syntax (Overrides)</link>"
1566 section.
1567 </para>
1568 </glossdef>
1569 </glossentry>
1570 </glossdiv>
1571
1572 <glossdiv id='var-glossary-p'><title>P</title>
1573
1574 <glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
1575 <glossdef>
1576 <para>The list of packages the recipe creates.
1577 </para>
1578 </glossdef>
1579 </glossentry>
1580
1581 <glossentry id='var-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm>
1582 <glossdef>
1583 <para>
1584 A promise that your recipe satisfies runtime dependencies
1585 for optional modules that are found in other recipes.
1586 <filename>PACKAGES_DYNAMIC</filename>
1587 does not actually satisfy the dependencies, it only states that
1588 they should be satisfied.
1589 For example, if a hard, runtime dependency
1590 (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
1591 of another package is satisfied during the build
1592 through the <filename>PACKAGES_DYNAMIC</filename>
1593 variable, but a package with the module name is never actually
1594 produced, then the other package will be broken.
1595 </para>
1596 </glossdef>
1597 </glossentry>
1598
1599 <glossentry id='var-PE'><glossterm>PE</glossterm>
1600 <glossdef>
1601 <para>
1602 The epoch of the recipe.
1603 By default, this variable is unset.
1604 The variable is used to make upgrades possible when the
1605 versioning scheme changes in some backwards incompatible
1606 way.
1607 </para>
1608 </glossdef>
1609 </glossentry>
1610
1611 <glossentry id='var-PERSISTENT_DIR'><glossterm>PERSISTENT_DIR</glossterm>
1612 <glossdef>
1613 <para>
1614 Specifies the directory BitBake uses to store data that
1615 should be preserved between builds.
1616 In particular, the data stored is the data that uses
1617 BitBake's persistent data API and the data used by the
1618 PR Server and PR Service.
1619 </para>
1620 </glossdef>
1621 </glossentry>
1622
1623 <glossentry id='var-PF'><glossterm>PF</glossterm>
1624 <glossdef>
1625 <para>
1626 Specifies the recipe or package name and includes all version and revision
1627 numbers (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
1628 <filename>bash-4.2-r1/</filename>).
1629 </para>
1630 </glossdef>
1631 </glossentry>
1632
1633 <glossentry id='var-PN'><glossterm>PN</glossterm>
1634 <glossdef>
1635 <para>The recipe name.</para>
1636 </glossdef>
1637 </glossentry>
1638
1639 <glossentry id='var-PR'><glossterm>PR</glossterm>
1640 <glossdef>
1641 <para>The revision of the recipe.
1642 </para>
1643 </glossdef>
1644 </glossentry>
1645
1646 <glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
1647 <glossdef>
1648 <para>
1649 Determines which recipe should be given preference when
1650 multiple recipes provide the same item.
1651 You should always suffix the variable with the name of the
1652 provided item, and you should set it to the
1653 <link linkend='var-PN'><filename>PN</filename></link>
1654 of the recipe to which you want to give precedence.
1655 Some examples:
1656 <literallayout class='monospaced'>
1657 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
1658 PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
1659 PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
1660 </literallayout>
1661 </para>
1662 </glossdef>
1663 </glossentry>
1664
1665 <glossentry id='var-PREFERRED_PROVIDERS'><glossterm>PREFERRED_PROVIDERS</glossterm>
1666 <glossdef>
1667 <para>
1668 Determines which recipe should be given preference for
1669 cases where multiple recipes provide the same item.
1670 Functionally,
1671 <filename>PREFERRED_PROVIDERS</filename> is identical to
1672 <link linkend='var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link>.
1673 However, the <filename>PREFERRED_PROVIDERS</filename>
1674 variable lets you define preferences for multiple
1675 situations using the following form:
1676 <literallayout class='monospaced'>
1677 PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..."
1678 </literallayout>
1679 This form is a convenient replacement for the following:
1680 <literallayout class='monospaced'>
1681 PREFERRED_PROVIDER_xxx = "yyy"
1682 PREFERRED_PROVIDER_aaa = "bbb"
1683 </literallayout>
1684 </para>
1685 </glossdef>
1686 </glossentry>
1687
1688 <glossentry id='var-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm>
1689 <glossdef>
1690 <para>
1691 If there are multiple versions of recipes available, this
1692 variable determines which recipe should be given preference.
1693 You must always suffix the variable with the
1694 <link linkend='var-PN'><filename>PN</filename></link>
1695 you want to select, and you should set
1696 <link linkend='var-PV'><filename>PV</filename></link>
1697 accordingly for precedence.
1698 You can use the "<filename>%</filename>" character as a
1699 wildcard to match any number of characters, which can be
1700 useful when specifying versions that contain long revision
1701 numbers that could potentially change.
1702 Here are two examples:
1703 <literallayout class='monospaced'>
1704 PREFERRED_VERSION_python = "2.7.3"
1705 PREFERRED_VERSION_linux-yocto = "3.10%"
1706 </literallayout>
1707 </para>
1708 </glossdef>
1709 </glossentry>
1710
1711 <glossentry id='var-PREMIRRORS'><glossterm>PREMIRRORS</glossterm>
1712 <glossdef>
1713 <para>
1714 Specifies additional paths from which BitBake gets source code.
1715 When the build system searches for source code, it first
1716 tries the local download directory.
1717 If that location fails, the build system tries locations
1718 defined by <filename>PREMIRRORS</filename>, the upstream
1719 source, and then locations specified by
1720 <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
1721 in that order.
1722 </para>
1723
1724 <para>
1725 Typically, you would add a specific server for the
1726 build system to attempt before any others by adding
1727 something like the following to your configuration:
1728 <literallayout class='monospaced'>
1729 PREMIRRORS_prepend = "\
1730 git://.*/.* http://www.yoctoproject.org/sources/ \n \
1731 ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
1732 http://.*/.* http://www.yoctoproject.org/sources/ \n \
1733 https://.*/.* http://www.yoctoproject.org/sources/ \n"
1734 </literallayout>
1735 These changes cause the build system to intercept
1736 Git, FTP, HTTP, and HTTPS requests and direct them to
1737 the <filename>http://</filename> sources mirror.
1738 You can use <filename>file://</filename> URLs to point
1739 to local directories or network shares as well.
1740 </para>
1741 </glossdef>
1742 </glossentry>
1743
1744 <glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm>
1745 <glossdef>
1746 <para>
1747 A list of aliases that a recipe also provides.
1748 These aliases are useful for satisfying dependencies of
1749 other recipes during the build (as specified by
1750 <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>).
1751 <note>
1752 A recipe's own
1753 <filename><link linkend='var-PN'>PN</link></filename>
1754 is implicitly already in its
1755 <filename>PROVIDES</filename> list.
1756 </note>
1757 </para>
1758 </glossdef>
1759 </glossentry>
1760
1761 <glossentry id='var-PRSERV_HOST'><glossterm>PRSERV_HOST</glossterm>
1762 <glossdef>
1763 <para>
1764 The network based
1765 <link linkend='var-PR'><filename>PR</filename></link>
1766 service host and port.
1767 </para>
1768
1769 <para>
1770 Following is an example of how the <filename>PRSERV_HOST</filename> variable is
1771 set:
1772 <literallayout class='monospaced'>
1773 PRSERV_HOST = "localhost:0"
1774 </literallayout>
1775 You must set the variable if you want to automatically
1776 start a local PR service.
1777 You can set <filename>PRSERV_HOST</filename> to other
1778 values to use a remote PR service.
1779 </para>
1780 </glossdef>
1781 </glossentry>
1782
1783 <glossentry id='var-PV'><glossterm>PV</glossterm>
1784 <glossdef>
1785 <para>The version of the recipe.
1786 </para>
1787 </glossdef>
1788 </glossentry>
1789
1790 </glossdiv>
1791
1792<!--
1793 <glossdiv id='var-glossary-q'><title>Q</title>
1794 </glossdiv>
1795-->
1796
1797 <glossdiv id='var-glossary-r'><title>R</title>
1798
1799 <glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
1800 <glossdef>
1801 <para>
1802 Lists a package's runtime dependencies (i.e. other packages)
1803 that must be installed in order for the built package to run
1804 correctly.
1805 If a package in this list cannot be found during the build,
1806 you will get a build error.
1807 </para>
1808
1809 <para>
1810 Because the <filename>RDEPENDS</filename> variable applies
1811 to packages being built, you should always use the variable
1812 in a form with an attached package name.
1813 For example, suppose you are building a development package
1814 that depends on the <filename>perl</filename> package.
1815 In this case, you would use the following
1816 <filename>RDEPENDS</filename> statement:
1817 <literallayout class='monospaced'>
1818 RDEPENDS_${PN}-dev += "perl"
1819 </literallayout>
1820 In the example, the development package depends on
1821 the <filename>perl</filename> package.
1822 Thus, the <filename>RDEPENDS</filename> variable has the
1823 <filename>${PN}-dev</filename> package name as part of the
1824 variable.
1825 </para>
1826
1827 <para>
1828 BitBake supports specifying versioned dependencies.
1829 Although the syntax varies depending on the packaging
1830 format, BitBake hides these differences from you.
1831 Here is the general syntax to specify versions with
1832 the <filename>RDEPENDS</filename> variable:
1833 <literallayout class='monospaced'>
1834 RDEPENDS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
1835 </literallayout>
1836 For <filename>operator</filename>, you can specify the
1837 following:
1838 <literallayout class='monospaced'>
1839 =
1840 &lt;
1841 &gt;
1842 &lt;=
1843 &gt;=
1844 </literallayout>
1845 For example, the following sets up a dependency on version
1846 1.2 or greater of the package <filename>foo</filename>:
1847 <literallayout class='monospaced'>
1848 RDEPENDS_${PN} = "foo (>= 1.2)"
1849 </literallayout>
1850 </para>
1851
1852 <para>
1853 For information on build-time dependencies, see the
1854 <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
1855 variable.
1856 </para>
1857 </glossdef>
1858 </glossentry>
1859
1860 <glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
1861 <glossdef>
1862 <para>
1863 A list of package name aliases that a package also provides.
1864 These aliases are useful for satisfying runtime dependencies
1865 of other packages both during the build and on the target
1866 (as specified by
1867 <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
1868 </para>
1869 <para>
1870 As with all package-controlling variables, you must always
1871 use the variable in conjunction with a package name override.
1872 Here is an example:
1873 <literallayout class='monospaced'>
1874 RPROVIDES_${PN} = "widget-abi-2"
1875 </literallayout>
1876 </para>
1877 </glossdef>
1878 </glossentry>
1879
1880 <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
1881 <glossdef>
1882 <para>
1883 A list of packages that extends the usability of a package
1884 being built.
1885 The package being built does not depend on this list of
1886 packages in order to successfully build, but needs them for
1887 the extended usability.
1888 To specify runtime dependencies for packages, see the
1889 <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
1890 variable.
1891 </para>
1892
1893 <para>
1894 BitBake supports specifying versioned recommends.
1895 Although the syntax varies depending on the packaging
1896 format, BitBake hides these differences from you.
1897 Here is the general syntax to specify versions with
1898 the <filename>RRECOMMENDS</filename> variable:
1899 <literallayout class='monospaced'>
1900 RRECOMMENDS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
1901 </literallayout>
1902 For <filename>operator</filename>, you can specify the
1903 following:
1904 <literallayout class='monospaced'>
1905 =
1906 &lt;
1907 &gt;
1908 &lt;=
1909 &gt;=
1910 </literallayout>
1911 For example, the following sets up a recommend on version
1912 1.2 or greater of the package <filename>foo</filename>:
1913 <literallayout class='monospaced'>
1914 RRECOMMENDS_${PN} = "foo (>= 1.2)"
1915 </literallayout>
1916 </para>
1917 </glossdef>
1918 </glossentry>
1919
1920 </glossdiv>
1921
1922 <glossdiv id='var-glossary-s'><title>S</title>
1923
1924 <glossentry id='var-SECTION'><glossterm>SECTION</glossterm>
1925 <glossdef>
1926 <para>The section in which packages should be categorized.</para>
1927 </glossdef>
1928 </glossentry>
1929
1930 <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
1931 <glossdef>
1932 <para>
1933 The list of source files - local or remote.
1934 This variable tells BitBake which bits
1935 to pull for the build and how to pull them.
1936 For example, if the recipe or append file needs to
1937 fetch a single tarball from the Internet, the recipe or
1938 append file uses a <filename>SRC_URI</filename>
1939 entry that specifies that tarball.
1940 On the other hand, if the recipe or append file needs to
1941 fetch a tarball and include a custom file, the recipe or
1942 append file needs an <filename>SRC_URI</filename> variable
1943 that specifies all those sources.</para>
1944 <para>The following list explains the available URI protocols:
1945 <itemizedlist>
1946 <listitem><para><emphasis><filename>file://</filename> -</emphasis>
1947 Fetches files, which are usually files shipped with
1948 the metadata,
1949 from the local machine.
1950 The path is relative to the
1951 <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
1952 variable.</para></listitem>
1953 <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a
1954 Bazaar revision control repository.</para></listitem>
1955 <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
1956 Git revision control repository.</para></listitem>
1957 <listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from
1958 an OSC (OpenSUSE Build service) revision control repository.</para></listitem>
1959 <listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from
1960 a repo (Git) repository.</para></listitem>
1961 <listitem><para><emphasis><filename>http://</filename> -</emphasis> Fetches files from
1962 the Internet using HTTP.</para></listitem>
1963 <listitem><para><emphasis><filename>https://</filename> -</emphasis> Fetches files
1964 from the Internet using HTTPS.</para></listitem>
1965 <listitem><para><emphasis><filename>ftp://</filename> -</emphasis> Fetches files
1966 from the Internet using FTP.</para></listitem>
1967 <listitem><para><emphasis><filename>cvs://</filename> -</emphasis> Fetches files from
1968 a CVS revision control repository.</para></listitem>
1969 <listitem><para><emphasis><filename>hg://</filename> -</emphasis> Fetches files from
1970 a Mercurial (<filename>hg</filename>) revision control repository.</para></listitem>
1971 <listitem><para><emphasis><filename>p4://</filename> -</emphasis> Fetches files from
1972 a Perforce (<filename>p4</filename>) revision control repository.</para></listitem>
1973 <listitem><para><emphasis><filename>ssh://</filename> -</emphasis> Fetches files from
1974 a secure shell.</para></listitem>
1975 <listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from
1976 a Subversion (<filename>svn</filename>) revision control repository.</para></listitem>
1977 </itemizedlist>
1978 </para>
1979 <para>Here are some additional options worth mentioning:
1980 <itemizedlist>
1981 <listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls
1982 whether or not to unpack the file if it is an archive.
1983 The default action is to unpack the file.</para></listitem>
1984 <listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file
1985 (or extracts its contents) into the specified
1986 subdirectory.
1987 This option is useful for unusual tarballs or other archives that
1988 do not have their files already in a subdirectory within the archive.
1989 </para></listitem>
1990 <listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a
1991 name to be used for association with <filename>SRC_URI</filename> checksums
1992 when you have more than one file specified in <filename>SRC_URI</filename>.
1993 </para></listitem>
1994 <listitem><para><emphasis><filename>downloadfilename</filename> -</emphasis> Specifies
1995 the filename used when storing the downloaded file.</para></listitem>
1996 </itemizedlist>
1997 </para>
1998 </glossdef>
1999 </glossentry>
2000
2001 <glossentry id='var-SRCDATE'><glossterm>SRCDATE</glossterm>
2002 <glossdef>
2003 <para>
2004 The date of the source code used to build the package.
2005 This variable applies only if the source was fetched from a Source Code Manager (SCM).
2006 </para>
2007 </glossdef>
2008 </glossentry>
2009
2010 <glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm>
2011 <glossdef>
2012 <para>
2013 The revision of the source code used to build the package.
2014 This variable applies only when using Subversion, Git, Mercurial and Bazaar.
2015 If you want to build a fixed revision and you want
2016 to avoid performing a query on the remote repository every time
2017 BitBake parses your recipe, you should specify a <filename>SRCREV</filename> that is a
2018 full revision identifier and not just a tag.
2019 </para>
2020 </glossdef>
2021 </glossentry>
2022
2023 <glossentry id='var-SRCREV_FORMAT'><glossterm>SRCREV_FORMAT</glossterm>
2024 <glossdef>
2025 <para>
2026 Helps construct valid
2027 <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
2028 values when multiple source controlled URLs are used in
2029 <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>.
2030 </para>
2031
2032 <para>
2033 The system needs help constructing these values under these
2034 circumstances.
2035 Each component in the <filename>SRC_URI</filename>
2036 is assigned a name and these are referenced
2037 in the <filename>SRCREV_FORMAT</filename> variable.
2038 Consider an example with URLs named "machine" and "meta".
2039 In this case, <filename>SRCREV_FORMAT</filename> could look
2040 like "machine_meta" and those names would have the SCM
2041 versions substituted into each position.
2042 Only one <filename>AUTOINC</filename> placeholder is added
2043 and if needed.
2044 And, this placeholder is placed at the start of the
2045 returned string.
2046 </para>
2047 </glossdef>
2048 </glossentry>
2049
2050 <glossentry id='var-STAMP'><glossterm>STAMP</glossterm>
2051 <glossdef>
2052 <para>
2053 Specifies the base path used to create recipe stamp files.
2054 The path to an actual stamp file is constructed by evaluating this
2055 string and then appending additional information.
2056 </para>
2057 </glossdef>
2058 </glossentry>
2059
2060 <glossentry id='var-STAMPCLEAN'><glossterm>STAMPCLEAN</glossterm>
2061 <glossdef>
2062 <para>
2063 Specifies the base path used to create recipe stamp files.
2064 Unlike the
2065 <link linkend='var-STAMP'><filename>STAMP</filename></link>
2066 variable, <filename>STAMPCLEAN</filename> can contain
2067 wildcards to match the range of files a clean operation
2068 should remove.
2069 BitBake uses a clean operation to remove any other stamps
2070 it should be removing when creating a new stamp.
2071 </para>
2072 </glossdef>
2073 </glossentry>
2074
2075 <glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
2076 <glossdef>
2077 <para>
2078 A short summary for the recipe, which is 72 characters or less.
2079 </para>
2080 </glossdef>
2081 </glossentry>
2082
2083 </glossdiv>
2084
2085 <glossdiv id='var-glossary-t'><title>T</title>
2086
2087 <glossentry id='var-T'><glossterm>T</glossterm>
2088 <glossdef>
2089 <para>Points to a directory were BitBake places
2090 temporary files, which consist mostly of task logs and
2091 scripts, when building a particular recipe.
2092 </para>
2093 </glossdef>
2094 </glossentry>
2095
2096 <glossentry id='var-TOPDIR'><glossterm>TOPDIR</glossterm>
2097 <glossdef>
2098 <para>
2099 Points to the build directory.
2100 BitBake automatically sets this variable.
2101 </para>
2102 </glossdef>
2103 </glossentry>
2104
2105 </glossdiv>
2106
2107<!--
2108 <glossdiv id='var-glossary-u'><title>U</title>
2109 </glossdiv>
2110
2111 <glossdiv id='var-glossary-v'><title>V</title>
2112 </glossdiv>
2113
2114 <glossdiv id='var-glossary-w'><title>W</title>
2115 </glossdiv>
2116
2117 <glossdiv id='var-glossary-x'><title>X</title>
2118 </glossdiv>
2119
2120 <glossdiv id='var-glossary-y'><title>Y</title>
2121 </glossdiv>
2122
2123 <glossdiv id='var-glossary-z'><title>Z</title>
2124 </glossdiv>
2125-->
2126
2127
2128</glossary>
2129</chapter>
2130<!--
2131vim: expandtab tw=80 ts=4
2132-->