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.xml2131
1 files changed, 2131 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 0000000000..6a5af89ffa
--- /dev/null
+++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
@@ -0,0 +1,2131 @@
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 <note>
1084 If you run BitBake from a directory outside of the
1085 build directory,
1086 you must be sure to set
1087 <filename>BBPATH</filename> to point to the
1088 build directory.
1089 Set the variable as you would any environment variable
1090 and then run BitBake:
1091 <literallayout class='monospaced'>
1092 $ BBPATH = "&lt;build_directory&gt;"
1093 $ export BBPATH
1094 $ bitbake &lt;target&gt;
1095 </literallayout>
1096 </note>
1097 </para>
1098 </glossdef>
1099 </glossentry>
1100
1101 <glossentry id='var-BBSERVER'><glossterm>BBSERVER</glossterm>
1102 <glossdef>
1103 <para>
1104 Points to the server that runs memory-resident BitBake.
1105 The variable is only used when you employ memory-resident
1106 BitBake.
1107 </para>
1108 </glossdef>
1109 </glossentry>
1110
1111 <glossentry id='var-BBVERSIONS'><glossterm>BBVERSIONS</glossterm>
1112 <glossdef>
1113 <para>
1114 Allows a single recipe to build multiple versions of a
1115 project from a single recipe file.
1116 You also able to specify conditional metadata
1117 using the
1118 <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
1119 mechanism for a single version or for an optionally named
1120 range of versions.
1121 </para>
1122
1123 <para>
1124 For more information on <filename>BBVERSIONS</filename>,
1125 see the
1126 "<link linkend='variants-class-extension-mechanism'>Variants - Class Extension Mechanism</link>"
1127 section.
1128 </para>
1129 </glossdef>
1130 </glossentry>
1131
1132 <glossentry id='var-BITBAKE_UI'><glossterm>BITBAKE_UI</glossterm>
1133 <glossdef>
1134 <para>
1135 Used to specify the UI module to use when running BitBake.
1136 Using this variable is equivalent to using the
1137 <filename>-u</filename> command-line option.
1138 <note>
1139 You must set this variable in the external environment
1140 in order for it to work.
1141 </note>
1142 </para>
1143 </glossdef>
1144 </glossentry>
1145
1146 <glossentry id='var-BUILDNAME'><glossterm>BUILDNAME</glossterm>
1147 <glossdef>
1148 <para>
1149 A name assigned to the build.
1150 The name defaults to a datetime stamp of when the build was
1151 started but can be defined by the metadata.
1152 </para>
1153 </glossdef>
1154 </glossentry>
1155
1156 </glossdiv>
1157
1158 <glossdiv id='var-glossary-c'><title>C</title>
1159
1160 <glossentry id='var-CACHE'><glossterm>CACHE</glossterm>
1161 <glossdef>
1162 <para>
1163 Specifies the directory BitBake uses to store a cache
1164 of the metadata so it does not need to be parsed every
1165 time BitBake is started.
1166 </para>
1167 </glossdef>
1168 </glossentry>
1169
1170 </glossdiv>
1171
1172 <glossdiv id='var-glossary-d'><title>D</title>
1173
1174 <glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
1175 <glossdef>
1176 <para>
1177 Specifies a weak bias for recipe selection priority.
1178 </para>
1179 <para>
1180 The most common usage of this is variable is to set
1181 it to "-1" within a recipe for a development version of a
1182 piece of software.
1183 Using the variable in this way causes the stable version
1184 of the recipe to build by default in the absence of
1185 <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
1186 being used to build the development version.
1187 </para>
1188 <note>
1189 The bias provided by <filename>DEFAULT_PREFERENCE</filename>
1190 is weak and is overridden by
1191 <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename>
1192 if that variable is different between two layers
1193 that contain different versions of the same recipe.
1194 </note>
1195 </glossdef>
1196 </glossentry>
1197
1198 <glossentry id='var-DEPENDS'><glossterm>DEPENDS</glossterm>
1199 <glossdef>
1200 <para>
1201 Lists a recipe's build-time dependencies
1202 (i.e. other recipe files).
1203 </para>
1204
1205 <para>
1206 Consider this simple example for two recipes named "a" and
1207 "b" that produce similarly named packages.
1208 In this example, the <filename>DEPENDS</filename>
1209 statement appears in the "a" recipe:
1210 <literallayout class='monospaced'>
1211 DEPENDS = "b"
1212 </literallayout>
1213 Here, the dependency is such that the
1214 <filename>do_configure</filename> task for recipe "a"
1215 depends on the <filename>do_populate_sysroot</filename>
1216 task of recipe "b".
1217 This means anything that recipe "b" puts into sysroot
1218 is available when recipe "a" is configuring itself.
1219 </para>
1220
1221 <para>
1222 For information on runtime dependencies, see the
1223 <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
1224 variable.
1225 </para>
1226 </glossdef>
1227 </glossentry>
1228
1229 <glossentry id='var-DESCRIPTION'><glossterm>DESCRIPTION</glossterm>
1230 <glossdef>
1231 <para>
1232 A long description for the recipe.
1233 </para>
1234 </glossdef>
1235 </glossentry>
1236
1237 <glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
1238 <glossdef>
1239 <para>
1240 The central download directory used by the build process to
1241 store downloads.
1242 By default, <filename>DL_DIR</filename> gets files
1243 suitable for mirroring for everything except Git
1244 repositories.
1245 If you want tarballs of Git repositories, use the
1246 <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
1247 variable.
1248 </para>
1249 </glossdef>
1250
1251 </glossentry>
1252 </glossdiv>
1253
1254 <glossdiv id='var-glossary-e'><title>E</title>
1255
1256 <glossentry id='var-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm>
1257 <glossdef>
1258 <para>
1259 Directs BitBake to exclude a recipe from world builds (i.e.
1260 <filename>bitbake world</filename>).
1261 During world builds, BitBake locates, parses and builds all
1262 recipes found in every layer exposed in the
1263 <filename>bblayers.conf</filename> configuration file.
1264 </para>
1265
1266 <para>
1267 To exclude a recipe from a world build using this variable,
1268 set the variable to "1" in the recipe.
1269 </para>
1270
1271 <note>
1272 Recipes added to <filename>EXCLUDE_FROM_WORLD</filename>
1273 may still be built during a world build in order to satisfy
1274 dependencies of other recipes.
1275 Adding a recipe to <filename>EXCLUDE_FROM_WORLD</filename>
1276 only ensures that the recipe is not explicitly added
1277 to the list of build targets in a world build.
1278 </note>
1279 </glossdef>
1280 </glossentry>
1281
1282 </glossdiv>
1283
1284 <glossdiv id='var-glossary-f'><title>F</title>
1285
1286 <glossentry id='var-FAKEROOT'><glossterm>FAKEROOT</glossterm>
1287 <glossdef>
1288 <para>
1289 Contains the command to use when running a shell script
1290 in a fakeroot environment.
1291 The <filename>FAKEROOT</filename> variable is obsolete
1292 and has been replaced by the other
1293 <filename>FAKEROOT*</filename> variables.
1294 See these entries in the glossary for more information.
1295 </para>
1296 </glossdef>
1297 </glossentry>
1298
1299 <glossentry id='var-FAKEROOTBASEENV'><glossterm>FAKEROOTBASEENV</glossterm>
1300 <glossdef>
1301 <para>
1302 Lists environment variables to set when executing
1303 the command defined by
1304 <link linkend='var-FAKEROOTCMD'><filename>FAKEROOTCMD</filename></link>
1305 that starts the bitbake-worker process
1306 in the fakeroot environment.
1307 </para>
1308 </glossdef>
1309 </glossentry>
1310
1311 <glossentry id='var-FAKEROOTCMD'><glossterm>FAKEROOTCMD</glossterm>
1312 <glossdef>
1313 <para>
1314 Contains the command that starts the bitbake-worker
1315 process in the fakeroot environment.
1316 </para>
1317 </glossdef>
1318 </glossentry>
1319
1320 <glossentry id='var-FAKEROOTDIRS'><glossterm>FAKEROOTDIRS</glossterm>
1321 <glossdef>
1322 <para>
1323 Lists directories to create before running a task in
1324 the fakeroot environment.
1325 </para>
1326 </glossdef>
1327 </glossentry>
1328
1329 <glossentry id='var-FAKEROOTENV'><glossterm>FAKEROOTENV</glossterm>
1330 <glossdef>
1331 <para>
1332 Lists environment variables to set when running a task
1333 in the fakeroot environment.
1334 For additional information on environment variables and
1335 the fakeroot environment, see the
1336 <link linkend='var-FAKEROOTBASEENV'><filename>FAKEROOTBASEENV</filename></link>
1337 variable.
1338 </para>
1339 </glossdef>
1340 </glossentry>
1341
1342 <glossentry id='var-FAKEROOTNOENV'><glossterm>FAKEROOTNOENV</glossterm>
1343 <glossdef>
1344 <para>
1345 Lists environment variables to set when running a task
1346 that is not in the fakeroot environment.
1347 For additional information on environment variables and
1348 the fakeroot environment, see the
1349 <link linkend='var-FAKEROOTENV'><filename>FAKEROOTENV</filename></link>
1350 variable.
1351 </para>
1352 </glossdef>
1353 </glossentry>
1354
1355 <glossentry id='var-FETCHCMD'><glossterm>FETCHCMD</glossterm>
1356 <glossdef>
1357 <para>
1358 Defines the command the BitBake fetcher module
1359 executes when running fetch operations.
1360 You need to use an override suffix when you use the
1361 variable (e.g. <filename>FETCHCMD_git</filename>
1362 or <filename>FETCHCMD_svn</filename>).
1363 </para>
1364 </glossdef>
1365 </glossentry>
1366
1367 <glossentry id='var-FILE'><glossterm>FILE</glossterm>
1368 <glossdef>
1369 <para>
1370 Points at the current file.
1371 BitBake sets this variable during the parsing process
1372 to identify the file being parsed.
1373 BitBake also sets this variable when a recipe is being
1374 executed to identify the recipe file.
1375 </para>
1376 </glossdef>
1377 </glossentry>
1378
1379 <glossentry id='var-FILESDIR'><glossterm>FILESDIR</glossterm>
1380 <glossdef>
1381 <para>
1382 Specifies directories BitBake uses when searching for
1383 patches and files.
1384 The "local" fetcher module uses these directories when
1385 handling <filename>file://</filename> URLs if the file
1386 was not found using
1387 <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>.
1388 <note>
1389 The <filename>FILESDIR</filename> variable is
1390 deprecated and you should use
1391 <filename>FILESPATH</filename> in all new code.
1392 </note>
1393 </para>
1394 </glossdef>
1395 </glossentry>
1396
1397 <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
1398 <glossdef>
1399 <para>
1400 Specifies directories BitBake uses when searching for
1401 patches and files.
1402 The "local" fetcher module uses these directories when
1403 handling <filename>file://</filename> URLs.
1404 The variable behaves like a shell <filename>PATH</filename>
1405 environment variable.
1406 The value is a colon-separated list of directories that
1407 are searched left-to-right in order.
1408 </para>
1409 </glossdef>
1410 </glossentry>
1411
1412 </glossdiv>
1413
1414<!--
1415 <glossdiv id='var-glossary-g'><title>G</title>
1416 </glossdiv>
1417-->
1418
1419 <glossdiv id='var-glossary-h'><title>H</title>
1420
1421 <glossentry id='var-HOMEPAGE'><glossterm>HOMEPAGE</glossterm>
1422 <glossdef>
1423 <para>Website where more information about the software the recipe is building
1424 can be found.</para>
1425 </glossdef>
1426 </glossentry>
1427
1428 </glossdiv>
1429
1430 <glossdiv id='var-glossary-i'><title>I</title>
1431
1432 <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
1433 <glossdef>
1434 <para>
1435 Causes the named class to be inherited at
1436 this point during parsing.
1437 The variable is only valid in configuration files.
1438 </para>
1439 </glossdef>
1440 </glossentry>
1441
1442 </glossdiv>
1443
1444<!--
1445 <glossdiv id='var-glossary-j'><title>J</title>
1446 </glossdiv>
1447
1448 <glossdiv id='var-glossary-k'><title>K</title>
1449 </glossdiv>
1450-->
1451
1452 <glossdiv id='var-glossary-l'><title>L</title>
1453
1454 <glossentry id='var-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm>
1455 <glossdef>
1456 <para>Lists the layers, separated by spaces, upon which this recipe depends.
1457 Optionally, you can specify a specific layer version for a dependency
1458 by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3"
1459 to be compared against
1460 <link linkend='var-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename>
1461 in this case).
1462 BitBake produces an error if any dependency is missing or
1463 the version numbers do not match exactly (if specified).</para>
1464 <para>
1465 You use this variable in the <filename>conf/layer.conf</filename> file.
1466 You must also use the specific layer name as a suffix
1467 to the variable (e.g. <filename>LAYERDEPENDS_mylayer</filename>).</para>
1468 </glossdef>
1469 </glossentry>
1470
1471 <glossentry id='var-LAYERDIR'><glossterm>LAYERDIR</glossterm>
1472 <glossdef>
1473 <para>When used inside the <filename>layer.conf</filename> configuration
1474 file, this variable provides the path of the current layer.
1475 This variable is not available outside of <filename>layer.conf</filename>
1476 and references are expanded immediately when parsing of the file completes.</para>
1477 </glossdef>
1478 </glossentry>
1479
1480 <glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
1481 <glossdef>
1482 <para>Optionally specifies the version of a layer as a single number.
1483 You can use this variable within
1484 <link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link>
1485 for another layer in order to depend on a specific version
1486 of the layer.</para>
1487 <para>
1488 You use this variable in the <filename>conf/layer.conf</filename> file.
1489 You must also use the specific layer name as a suffix
1490 to the variable (e.g. <filename>LAYERDEPENDS_mylayer</filename>).</para>
1491 </glossdef>
1492 </glossentry>
1493
1494 <glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
1495 <glossdef>
1496 <para>
1497 The list of source licenses for the recipe.
1498 </para>
1499 </glossdef>
1500 </glossentry>
1501
1502 </glossdiv>
1503
1504 <glossdiv id='var-glossary-m'><title>M</title>
1505
1506 <glossentry id='var-MIRRORS'><glossterm>MIRRORS</glossterm>
1507 <glossdef>
1508 <para>
1509 Specifies additional paths from which BitBake gets source code.
1510 When the build system searches for source code, it first
1511 tries the local download directory.
1512 If that location fails, the build system tries locations
1513 defined by
1514 <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>,
1515 the upstream source, and then locations specified by
1516 <filename>MIRRORS</filename> in that order.
1517 </para>
1518 </glossdef>
1519 </glossentry>
1520
1521 <glossentry id='var-MULTI_PROVIDER_WHITELIST'><glossterm>MULTI_PROVIDER_WHITELIST</glossterm>
1522 <glossdef>
1523 <para>
1524 Allows you to suppress BitBake warnings caused when
1525 building two separate recipes that provide the same
1526 output.
1527 </para>
1528
1529 <para>
1530 Bitbake normally issues a warning when building two
1531 different recipes where each provides the same output.
1532 This scenario is usually something the user does not
1533 want.
1534 However, cases do exist where it makes sense, particularly
1535 in the <filename>virtual/*</filename> namespace.
1536 You can use this variable to suppress BitBake's warnings.
1537 </para>
1538
1539 <para>
1540 To use the variable, list provider names (e.g.
1541 recipe names, <filename>virtual/kernel</filename>,
1542 and so forth).
1543 </para>
1544 </glossdef>
1545 </glossentry>
1546
1547 </glossdiv>
1548
1549<!--
1550 <glossdiv id='var-glossary-n'><title>N</title>
1551 </glossdiv>
1552-->
1553
1554 <glossdiv id='var-glossary-o'><title>O</title>
1555
1556 <glossentry id='var-OVERRIDES'><glossterm>OVERRIDES</glossterm>
1557 <glossdef>
1558 <para>
1559 BitBake uses <filename>OVERRIDES</filename> to control
1560 what variables are overridden after BitBake parses
1561 recipes and configuration files.
1562 You can find more information on how overrides are handled
1563 in the
1564 "<link linkend='conditional-syntax-overrides'>Conditional Syntax (Overrides)</link>"
1565 section.
1566 </para>
1567 </glossdef>
1568 </glossentry>
1569 </glossdiv>
1570
1571 <glossdiv id='var-glossary-p'><title>P</title>
1572
1573 <glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
1574 <glossdef>
1575 <para>The list of packages the recipe creates.
1576 </para>
1577 </glossdef>
1578 </glossentry>
1579
1580 <glossentry id='var-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm>
1581 <glossdef>
1582 <para>
1583 A promise that your recipe satisfies runtime dependencies
1584 for optional modules that are found in other recipes.
1585 <filename>PACKAGES_DYNAMIC</filename>
1586 does not actually satisfy the dependencies, it only states that
1587 they should be satisfied.
1588 For example, if a hard, runtime dependency
1589 (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
1590 of another package is satisfied during the build
1591 through the <filename>PACKAGES_DYNAMIC</filename>
1592 variable, but a package with the module name is never actually
1593 produced, then the other package will be broken.
1594 </para>
1595 </glossdef>
1596 </glossentry>
1597
1598 <glossentry id='var-PE'><glossterm>PE</glossterm>
1599 <glossdef>
1600 <para>
1601 The epoch of the recipe.
1602 By default, this variable is unset.
1603 The variable is used to make upgrades possible when the
1604 versioning scheme changes in some backwards incompatible
1605 way.
1606 </para>
1607 </glossdef>
1608 </glossentry>
1609
1610 <glossentry id='var-PERSISTENT_DIR'><glossterm>PERSISTENT_DIR</glossterm>
1611 <glossdef>
1612 <para>
1613 Specifies the directory BitBake uses to store data that
1614 should be preserved between builds.
1615 In particular, the data stored is the data that uses
1616 BitBake's persistent data API and the data used by the
1617 PR Server and PR Service.
1618 </para>
1619 </glossdef>
1620 </glossentry>
1621
1622 <glossentry id='var-PF'><glossterm>PF</glossterm>
1623 <glossdef>
1624 <para>
1625 Specifies the recipe or package name and includes all version and revision
1626 numbers (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
1627 <filename>bash-4.2-r1/</filename>).
1628 </para>
1629 </glossdef>
1630 </glossentry>
1631
1632 <glossentry id='var-PN'><glossterm>PN</glossterm>
1633 <glossdef>
1634 <para>The recipe name.</para>
1635 </glossdef>
1636 </glossentry>
1637
1638 <glossentry id='var-PR'><glossterm>PR</glossterm>
1639 <glossdef>
1640 <para>The revision of the recipe.
1641 </para>
1642 </glossdef>
1643 </glossentry>
1644
1645 <glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
1646 <glossdef>
1647 <para>
1648 Determines which recipe should be given preference when
1649 multiple recipes provide the same item.
1650 You should always suffix the variable with the name of the
1651 provided item, and you should set it to the
1652 <link linkend='var-PN'><filename>PN</filename></link>
1653 of the recipe to which you want to give precedence.
1654 Some examples:
1655 <literallayout class='monospaced'>
1656 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
1657 PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
1658 PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
1659 </literallayout>
1660 </para>
1661 </glossdef>
1662 </glossentry>
1663
1664 <glossentry id='var-PREFERRED_PROVIDERS'><glossterm>PREFERRED_PROVIDERS</glossterm>
1665 <glossdef>
1666 <para>
1667 Determines which recipe should be given preference for
1668 cases where multiple recipes provide the same item.
1669 Functionally,
1670 <filename>PREFERRED_PROVIDERS</filename> is identical to
1671 <link linkend='var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link>.
1672 However, the <filename>PREFERRED_PROVIDERS</filename>
1673 variable lets you define preferences for multiple
1674 situations using the following form:
1675 <literallayout class='monospaced'>
1676 PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..."
1677 </literallayout>
1678 This form is a convenient replacement for the following:
1679 <literallayout class='monospaced'>
1680 PREFERRED_PROVIDER_xxx = "yyy"
1681 PREFERRED_PROVIDER_aaa = "bbb"
1682 </literallayout>
1683 </para>
1684 </glossdef>
1685 </glossentry>
1686
1687 <glossentry id='var-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm>
1688 <glossdef>
1689 <para>
1690 If there are multiple versions of recipes available, this
1691 variable determines which recipe should be given preference.
1692 You must always suffix the variable with the
1693 <link linkend='var-PN'><filename>PN</filename></link>
1694 you want to select, and you should set
1695 <link linkend='var-PV'><filename>PV</filename></link>
1696 accordingly for precedence.
1697 You can use the "<filename>%</filename>" character as a
1698 wildcard to match any number of characters, which can be
1699 useful when specifying versions that contain long revision
1700 numbers that could potentially change.
1701 Here are two examples:
1702 <literallayout class='monospaced'>
1703 PREFERRED_VERSION_python = "2.7.3"
1704 PREFERRED_VERSION_linux-yocto = "3.10%"
1705 </literallayout>
1706 </para>
1707 </glossdef>
1708 </glossentry>
1709
1710 <glossentry id='var-PREMIRRORS'><glossterm>PREMIRRORS</glossterm>
1711 <glossdef>
1712 <para>
1713 Specifies additional paths from which BitBake gets source code.
1714 When the build system searches for source code, it first
1715 tries the local download directory.
1716 If that location fails, the build system tries locations
1717 defined by <filename>PREMIRRORS</filename>, the upstream
1718 source, and then locations specified by
1719 <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
1720 in that order.
1721 </para>
1722
1723 <para>
1724 Typically, you would add a specific server for the
1725 build system to attempt before any others by adding
1726 something like the following to your configuration:
1727 <literallayout class='monospaced'>
1728 PREMIRRORS_prepend = "\
1729 git://.*/.* http://www.yoctoproject.org/sources/ \n \
1730 ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
1731 http://.*/.* http://www.yoctoproject.org/sources/ \n \
1732 https://.*/.* http://www.yoctoproject.org/sources/ \n"
1733 </literallayout>
1734 These changes cause the build system to intercept
1735 Git, FTP, HTTP, and HTTPS requests and direct them to
1736 the <filename>http://</filename> sources mirror.
1737 You can use <filename>file://</filename> URLs to point
1738 to local directories or network shares as well.
1739 </para>
1740 </glossdef>
1741 </glossentry>
1742
1743 <glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm>
1744 <glossdef>
1745 <para>
1746 A list of aliases that a recipe also provides.
1747 These aliases are useful for satisfying dependencies of
1748 other recipes during the build (as specified by
1749 <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>).
1750 <note>
1751 A recipe's own
1752 <filename><link linkend='var-PN'>PN</link></filename>
1753 is implicitly already in its
1754 <filename>PROVIDES</filename> list.
1755 </note>
1756 </para>
1757 </glossdef>
1758 </glossentry>
1759
1760 <glossentry id='var-PRSERV_HOST'><glossterm>PRSERV_HOST</glossterm>
1761 <glossdef>
1762 <para>
1763 The network based
1764 <link linkend='var-PR'><filename>PR</filename></link>
1765 service host and port.
1766 </para>
1767
1768 <para>
1769 Following is an example of how the <filename>PRSERV_HOST</filename> variable is
1770 set:
1771 <literallayout class='monospaced'>
1772 PRSERV_HOST = "localhost:0"
1773 </literallayout>
1774 You must set the variable if you want to automatically
1775 start a local PR service.
1776 You can set <filename>PRSERV_HOST</filename> to other
1777 values to use a remote PR service.
1778 </para>
1779 </glossdef>
1780 </glossentry>
1781
1782 <glossentry id='var-PV'><glossterm>PV</glossterm>
1783 <glossdef>
1784 <para>The version of the recipe.
1785 </para>
1786 </glossdef>
1787 </glossentry>
1788
1789 </glossdiv>
1790
1791<!--
1792 <glossdiv id='var-glossary-q'><title>Q</title>
1793 </glossdiv>
1794-->
1795
1796 <glossdiv id='var-glossary-r'><title>R</title>
1797
1798 <glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
1799 <glossdef>
1800 <para>
1801 Lists a package's runtime dependencies (i.e. other packages)
1802 that must be installed in order for the built package to run
1803 correctly.
1804 If a package in this list cannot be found during the build,
1805 you will get a build error.
1806 </para>
1807
1808 <para>
1809 Because the <filename>RDEPENDS</filename> variable applies
1810 to packages being built, you should always use the variable
1811 in a form with an attached package name.
1812 For example, suppose you are building a development package
1813 that depends on the <filename>perl</filename> package.
1814 In this case, you would use the following
1815 <filename>RDEPENDS</filename> statement:
1816 <literallayout class='monospaced'>
1817 RDEPENDS_${PN}-dev += "perl"
1818 </literallayout>
1819 In the example, the development package depends on
1820 the <filename>perl</filename> package.
1821 Thus, the <filename>RDEPENDS</filename> variable has the
1822 <filename>${PN}-dev</filename> package name as part of the
1823 variable.
1824 </para>
1825
1826 <para>
1827 BitBake supports specifying versioned dependencies.
1828 Although the syntax varies depending on the packaging
1829 format, BitBake hides these differences from you.
1830 Here is the general syntax to specify versions with
1831 the <filename>RDEPENDS</filename> variable:
1832 <literallayout class='monospaced'>
1833 RDEPENDS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
1834 </literallayout>
1835 For <filename>operator</filename>, you can specify the
1836 following:
1837 <literallayout class='monospaced'>
1838 =
1839 &lt;
1840 &gt;
1841 &lt;=
1842 &gt;=
1843 </literallayout>
1844 For example, the following sets up a dependency on version
1845 1.2 or greater of the package <filename>foo</filename>:
1846 <literallayout class='monospaced'>
1847 RDEPENDS_${PN} = "foo (>= 1.2)"
1848 </literallayout>
1849 </para>
1850
1851 <para>
1852 For information on build-time dependencies, see the
1853 <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
1854 variable.
1855 </para>
1856 </glossdef>
1857 </glossentry>
1858
1859 <glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
1860 <glossdef>
1861 <para>
1862 A list of package name aliases that a package also provides.
1863 These aliases are useful for satisfying runtime dependencies
1864 of other packages both during the build and on the target
1865 (as specified by
1866 <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
1867 </para>
1868 <para>
1869 As with all package-controlling variables, you must always
1870 use the variable in conjunction with a package name override.
1871 Here is an example:
1872 <literallayout class='monospaced'>
1873 RPROVIDES_${PN} = "widget-abi-2"
1874 </literallayout>
1875 </para>
1876 </glossdef>
1877 </glossentry>
1878
1879 <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
1880 <glossdef>
1881 <para>
1882 A list of packages that extends the usability of a package
1883 being built.
1884 The package being built does not depend on this list of
1885 packages in order to successfully build, but needs them for
1886 the extended usability.
1887 To specify runtime dependencies for packages, see the
1888 <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
1889 variable.
1890 </para>
1891
1892 <para>
1893 BitBake supports specifying versioned recommends.
1894 Although the syntax varies depending on the packaging
1895 format, BitBake hides these differences from you.
1896 Here is the general syntax to specify versions with
1897 the <filename>RRECOMMENDS</filename> variable:
1898 <literallayout class='monospaced'>
1899 RRECOMMENDS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
1900 </literallayout>
1901 For <filename>operator</filename>, you can specify the
1902 following:
1903 <literallayout class='monospaced'>
1904 =
1905 &lt;
1906 &gt;
1907 &lt;=
1908 &gt;=
1909 </literallayout>
1910 For example, the following sets up a recommend on version
1911 1.2 or greater of the package <filename>foo</filename>:
1912 <literallayout class='monospaced'>
1913 RRECOMMENDS_${PN} = "foo (>= 1.2)"
1914 </literallayout>
1915 </para>
1916 </glossdef>
1917 </glossentry>
1918
1919 </glossdiv>
1920
1921 <glossdiv id='var-glossary-s'><title>S</title>
1922
1923 <glossentry id='var-SECTION'><glossterm>SECTION</glossterm>
1924 <glossdef>
1925 <para>The section in which packages should be categorized.</para>
1926 </glossdef>
1927 </glossentry>
1928
1929 <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
1930 <glossdef>
1931 <para>
1932 The list of source files - local or remote.
1933 This variable tells BitBake which bits
1934 to pull for the build and how to pull them.
1935 For example, if the recipe or append file needs to
1936 fetch a single tarball from the Internet, the recipe or
1937 append file uses a <filename>SRC_URI</filename>
1938 entry that specifies that tarball.
1939 On the other hand, if the recipe or append file needs to
1940 fetch a tarball and include a custom file, the recipe or
1941 append file needs an <filename>SRC_URI</filename> variable
1942 that specifies all those sources.</para>
1943 <para>The following list explains the available URI protocols:
1944 <itemizedlist>
1945 <listitem><para><emphasis><filename>file://</filename> -</emphasis>
1946 Fetches files, which are usually files shipped with
1947 the metadata,
1948 from the local machine.
1949 The path is relative to the
1950 <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
1951 variable.</para></listitem>
1952 <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a
1953 Bazaar revision control repository.</para></listitem>
1954 <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
1955 Git revision control repository.</para></listitem>
1956 <listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from
1957 an OSC (OpenSUSE Build service) revision control repository.</para></listitem>
1958 <listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from
1959 a repo (Git) repository.</para></listitem>
1960 <listitem><para><emphasis><filename>http://</filename> -</emphasis> Fetches files from
1961 the Internet using HTTP.</para></listitem>
1962 <listitem><para><emphasis><filename>https://</filename> -</emphasis> Fetches files
1963 from the Internet using HTTPS.</para></listitem>
1964 <listitem><para><emphasis><filename>ftp://</filename> -</emphasis> Fetches files
1965 from the Internet using FTP.</para></listitem>
1966 <listitem><para><emphasis><filename>cvs://</filename> -</emphasis> Fetches files from
1967 a CVS revision control repository.</para></listitem>
1968 <listitem><para><emphasis><filename>hg://</filename> -</emphasis> Fetches files from
1969 a Mercurial (<filename>hg</filename>) revision control repository.</para></listitem>
1970 <listitem><para><emphasis><filename>p4://</filename> -</emphasis> Fetches files from
1971 a Perforce (<filename>p4</filename>) revision control repository.</para></listitem>
1972 <listitem><para><emphasis><filename>ssh://</filename> -</emphasis> Fetches files from
1973 a secure shell.</para></listitem>
1974 <listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from
1975 a Subversion (<filename>svn</filename>) revision control repository.</para></listitem>
1976 </itemizedlist>
1977 </para>
1978 <para>Here are some additional options worth mentioning:
1979 <itemizedlist>
1980 <listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls
1981 whether or not to unpack the file if it is an archive.
1982 The default action is to unpack the file.</para></listitem>
1983 <listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file
1984 (or extracts its contents) into the specified
1985 subdirectory.
1986 This option is useful for unusual tarballs or other archives that
1987 do not have their files already in a subdirectory within the archive.
1988 </para></listitem>
1989 <listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a
1990 name to be used for association with <filename>SRC_URI</filename> checksums
1991 when you have more than one file specified in <filename>SRC_URI</filename>.
1992 </para></listitem>
1993 <listitem><para><emphasis><filename>downloadfilename</filename> -</emphasis> Specifies
1994 the filename used when storing the downloaded file.</para></listitem>
1995 </itemizedlist>
1996 </para>
1997 </glossdef>
1998 </glossentry>
1999
2000 <glossentry id='var-SRCDATE'><glossterm>SRCDATE</glossterm>
2001 <glossdef>
2002 <para>
2003 The date of the source code used to build the package.
2004 This variable applies only if the source was fetched from a Source Code Manager (SCM).
2005 </para>
2006 </glossdef>
2007 </glossentry>
2008
2009 <glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm>
2010 <glossdef>
2011 <para>
2012 The revision of the source code used to build the package.
2013 This variable applies only when using Subversion, Git, Mercurial and Bazaar.
2014 If you want to build a fixed revision and you want
2015 to avoid performing a query on the remote repository every time
2016 BitBake parses your recipe, you should specify a <filename>SRCREV</filename> that is a
2017 full revision identifier and not just a tag.
2018 </para>
2019 </glossdef>
2020 </glossentry>
2021
2022 <glossentry id='var-SRCREV_FORMAT'><glossterm>SRCREV_FORMAT</glossterm>
2023 <glossdef>
2024 <para>
2025 Helps construct valid
2026 <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
2027 values when multiple source controlled URLs are used in
2028 <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>.
2029 </para>
2030
2031 <para>
2032 The system needs help constructing these values under these
2033 circumstances.
2034 Each component in the <filename>SRC_URI</filename>
2035 is assigned a name and these are referenced
2036 in the <filename>SRCREV_FORMAT</filename> variable.
2037 Consider an example with URLs named "machine" and "meta".
2038 In this case, <filename>SRCREV_FORMAT</filename> could look
2039 like "machine_meta" and those names would have the SCM
2040 versions substituted into each position.
2041 Only one <filename>AUTOINC</filename> placeholder is added
2042 and if needed.
2043 And, this placeholder is placed at the start of the
2044 returned string.
2045 </para>
2046 </glossdef>
2047 </glossentry>
2048
2049 <glossentry id='var-STAMP'><glossterm>STAMP</glossterm>
2050 <glossdef>
2051 <para>
2052 Specifies the base path used to create recipe stamp files.
2053 The path to an actual stamp file is constructed by evaluating this
2054 string and then appending additional information.
2055 </para>
2056 </glossdef>
2057 </glossentry>
2058
2059 <glossentry id='var-STAMPCLEAN'><glossterm>STAMPCLEAN</glossterm>
2060 <glossdef>
2061 <para>
2062 Specifies the base path used to create recipe stamp files.
2063 Unlike the
2064 <link linkend='var-STAMP'><filename>STAMP</filename></link>
2065 variable, <filename>STAMPCLEAN</filename> can contain
2066 wildcards to match the range of files a clean operation
2067 should remove.
2068 BitBake uses a clean operation to remove any other stamps
2069 it should be removing when creating a new stamp.
2070 </para>
2071 </glossdef>
2072 </glossentry>
2073
2074 <glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
2075 <glossdef>
2076 <para>
2077 A short summary for the recipe, which is 72 characters or less.
2078 </para>
2079 </glossdef>
2080 </glossentry>
2081
2082 </glossdiv>
2083
2084 <glossdiv id='var-glossary-t'><title>T</title>
2085
2086 <glossentry id='var-T'><glossterm>T</glossterm>
2087 <glossdef>
2088 <para>Points to a directory were BitBake places
2089 temporary files, which consist mostly of task logs and
2090 scripts, when building a particular recipe.
2091 </para>
2092 </glossdef>
2093 </glossentry>
2094
2095 <glossentry id='var-TOPDIR'><glossterm>TOPDIR</glossterm>
2096 <glossdef>
2097 <para>
2098 Points to the build directory.
2099 BitBake automatically sets this variable.
2100 </para>
2101 </glossdef>
2102 </glossentry>
2103
2104 </glossdiv>
2105
2106<!--
2107 <glossdiv id='var-glossary-u'><title>U</title>
2108 </glossdiv>
2109
2110 <glossdiv id='var-glossary-v'><title>V</title>
2111 </glossdiv>
2112
2113 <glossdiv id='var-glossary-w'><title>W</title>
2114 </glossdiv>
2115
2116 <glossdiv id='var-glossary-x'><title>X</title>
2117 </glossdiv>
2118
2119 <glossdiv id='var-glossary-y'><title>Y</title>
2120 </glossdiv>
2121
2122 <glossdiv id='var-glossary-z'><title>Z</title>
2123 </glossdiv>
2124-->
2125
2126
2127</glossary>
2128</chapter>
2129<!--
2130vim: expandtab tw=80 ts=4
2131-->
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-24 18:39:04 +0000