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