summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2014-01-20 13:09:43 -0600
committerRichard Purdie <richard.purdie@linuxfoundation.org>2014-01-27 21:03:25 +0000
commite501280162b7be83d897c058ea44e33c1ba9cc6e (patch)
treee3e3837b7a47a2a1a78259b992247bf9a9b158da
parentbd4140578ebf3150691e453232ba9dc8fbcd96bc (diff)
downloadpoky-e501280162b7be83d897c058ea44e33c1ba9cc6e.tar.gz
bitbake: user-manual-ref-variavbles.xml: Added new glossary chapter.
Added a scrubbed copy of the YP ref-manual glossary. The content was scrubbed to contain BB variables only. Removed broken cross-references, made sure the PDF file built. (Bitbake rev: aae6bcb7fb6e056eb7b1027a8054f6ea5f8ab2b2) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat
-rw-r--r--bitbake/doc/user-manual/user-manual-ref-variables.xml1321
-rw-r--r--bitbake/doc/user-manual/user-manual.xml2
2 files changed, 1323 insertions, 0 deletions
diff --git a/bitbake/doc/user-manual/user-manual-ref-variables.xml b/bitbake/doc/user-manual/user-manual-ref-variables.xml
new file mode 100644
index 0000000000..0f62a8d1b7
--- /dev/null
+++ b/bitbake/doc/user-manual/user-manual-ref-variables.xml
@@ -0,0 +1,1321 @@
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<glossary id='ref-variables-glossary'>
16
17
18 <para>
19<!-- <link linkend='var-ALLOW_EMPTY'>A</link> -->
20 <link linkend='var-B'>B</link>
21<!-- <link linkend='var-CFLAGS'>C</link> -->
22 <link linkend='var-DEFAULT_PREFERENCE'>D</link>
23 <link linkend='var-EXCLUDE_FROM_WORLD'>E</link>
24 <link linkend='var-FILESPATH'>F</link>
25<!-- <link linkend='var-GROUPADD_PARAM'>G</link> -->
26 <link linkend='var-HOMEPAGE'>H</link>
27<!-- <link linkend='var-ICECC_DISABLED'>I</link> -->
28<!-- <link linkend='var-glossary-j'>J</link> -->
29<!-- <link linkend='var-KARCH'>K</link> -->
30 <link linkend='var-LAYERDEPENDS'>L</link>
31 <link linkend='var-MIRRORS'>M</link>
32<!-- <link linkend='var-glossary-n'>N</link> -->
33 <link linkend='var-OVERRIDES'>O</link>
34 <link linkend='var-PACKAGES'>P</link>
35<!-- <link linkend='var-QMAKE_PROFILES'>Q</link> -->
36 <link linkend='var-RDEPENDS'>R</link>
37 <link linkend='var-SECTION'>S</link>
38 <link linkend='var-T'>T</link>
39<!-- <link linkend='var-UBOOT_CONFIG'>U</link> -->
40<!-- <link linkend='var-glossary-v'>V</link> -->
41<!-- <link linkend='var-WARN_QA'>W</link> -->
42<!-- <link linkend='var-glossary-x'>X</link> -->
43<!-- <link linkend='var-glossary-y'>Y</link> -->
44<!-- <link linkend='var-glossary-z'>Z</link>-->
45 </para>
46
47
48<!--
49 <glossdiv id='var-glossary-a'><title>A</title>
50 </glossdiv>
51-->
52
53 <glossdiv id='var-glossary-b'><title>B</title>
54
55 <glossentry id='var-B'><glossterm>B</glossterm>
56 <glossdef>
57 <para>
58 The directory in which BitBake will execute functions
59 during a recipe's build process.
60 </para>
61 </glossdef>
62 </glossentry>
63
64 <glossentry id='var-BB_DANGLINGAPPENDS_WARNONLY'><glossterm>BB_DANGLINGAPPENDS_WARNONLY</glossterm>
65 <glossdef>
66 <para>
67 Defines how BitBake handles situations where an append
68 file (<filename>.bbappend</filename>) has no
69 corresponding recipe file (<filename>.bb</filename>).
70 This condition often occurs when layers get out of sync
71 (e.g. <filename>oe-core</filename> bumps a
72 recipe version and the old recipe no longer exists and the
73 other layer has not been updated to the new version
74 of the recipe yet).
75 </para>
76
77 <para>
78 The default fatal behavior is safest because it is
79 the sane reaction given something is out of sync.
80 It is important to realize when your changes are no longer
81 being applied.
82 </para>
83
84 </glossdef>
85 </glossentry>
86
87 <glossentry id='var-BB_DISKMON_DIRS'><glossterm>BB_DISKMON_DIRS</glossterm>
88 <glossdef>
89 <para>
90 Monitors disk space and available inodes during the build
91 and allows you to control the build based on these
92 parameters.
93 </para>
94
95 <para>
96 Disk space monitoring is disabled by default.
97 When setting this variable, use the following form:
98 <literallayout class='monospaced'>
99 BB_DISKMON_DIRS = "&lt;action&gt;,&lt;dir&gt;,&lt;threshold&gt; [...]"
100
101 where:
102
103 &lt;action&gt; is:
104 ABORT: Immediately abort the build when
105 a threshold is broken.
106 STOPTASKS: Stop the build after the currently
107 executing tasks have finished when
108 a threshold is broken.
109 WARN: Issue a warning but continue the
110 build when a threshold is broken.
111 Subsequent warnings are issued as
112 defined by the
113 <link linkend='var-BB_DISKMON_WARNINTERVAL'>BB_DISKMON_WARNINTERVAL</link> variable,
114 which must be defined.
115
116 &lt;dir&gt; is:
117 Any directory you choose. You can specify one or
118 more directories to monitor by separating the
119 groupings with a space. If two directories are
120 on the same device, only the first directory
121 is monitored.
122
123 &lt;threshold&gt; is:
124 Either the minimum available disk space,
125 the minimum number of free inodes, or
126 both. You must specify at least one. To
127 omit one or the other, simply omit the value.
128 Specify the threshold using G, M, K for Gbytes,
129 Mbytes, and Kbytes, respectively. If you do
130 not specify G, M, or K, Kbytes is assumed by
131 default. Do not use GB, MB, or KB.
132 </literallayout>
133 </para>
134
135 <para>
136 Here are some examples:
137 <literallayout class='monospaced'>
138 BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
139 BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
140 BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
141 </literallayout>
142 The first example works only if you also set
143 the <link linkend='var-BB_DISKMON_WARNINTERVAL'><filename>BB_DISKMON_WARNINTERVAL</filename></link> variable.
144 This example causes the build system to immediately
145 abort when either the disk space in <filename>${TMPDIR}</filename> drops
146 below 1 Gbyte or the available free inodes drops below
147 100 Kbytes.
148 Because two directories are provided with the variable, the
149 build system also issue a
150 warning when the disk space in the
151 <filename>${SSTATE_DIR}</filename> directory drops
152 below 1 Gbyte or the number of free inodes drops
153 below 100 Kbytes.
154 Subsequent warnings are issued during intervals as
155 defined by the <filename>BB_DISKMON_WARNINTERVAL</filename>
156 variable.
157 </para>
158
159 <para>
160 The second example stops the build after all currently
161 executing tasks complete when the minimum disk space
162 in the <filename>${TMPDIR}</filename>
163 directory drops below 1 Gbyte.
164 No disk monitoring occurs for the free inodes in this case.
165 </para>
166
167 <para>
168 The final example immediately aborts the build when the
169 number of free inodes in the <filename>${TMPDIR}</filename> directory
170 drops below 100 Kbytes.
171 No disk space monitoring for the directory itself occurs
172 in this case.
173 </para>
174 </glossdef>
175 </glossentry>
176
177 <glossentry id='var-BB_DISKMON_WARNINTERVAL'><glossterm>BB_DISKMON_WARNINTERVAL</glossterm>
178 <glossdef>
179 <para>
180 Defines the disk space and free inode warning intervals.
181 </para>
182
183 <para>
184 If you are going to use the
185 <filename>BB_DISKMON_WARNINTERVAL</filename> variable, you must
186 also use the
187 <link linkend='var-BB_DISKMON_DIRS'><filename>BB_DISKMON_DIRS</filename></link> variable
188 and define its action as "WARN".
189 During the build, subsequent warnings are issued each time
190 disk space or number of free inodes further reduces by
191 the respective interval.
192 </para>
193
194 <para>
195 If you do not provide a <filename>BB_DISKMON_WARNINTERVAL</filename>
196 variable and you do use <filename>BB_DISKMON_DIRS</filename> with
197 the "WARN" action, the disk monitoring interval defaults to
198 the following:
199 <literallayout class='monospaced'>
200 BB_DISKMON_WARNINTERVAL = "50M,5K"
201 </literallayout>
202 </para>
203
204 <para>
205 When specifying the variable in your configuration file,
206 use the following form:
207 <literallayout class='monospaced'>
208 BB_DISKMON_WARNINTERVAL = "&lt;disk_space_interval&gt;,&lt;disk_inode_interval&gt;"
209
210 where:
211
212 &lt;disk_space_interval&gt; is:
213 An interval of memory expressed in either
214 G, M, or K for Gbytes, Mbytes, or Kbytes,
215 respectively. You cannot use GB, MB, or KB.
216
217 &lt;disk_inode_interval&gt; is:
218 An interval of free inodes expressed in either
219 G, M, or K for Gbytes, Mbytes, or Kbytes,
220 respectively. You cannot use GB, MB, or KB.
221 </literallayout>
222 </para>
223
224 <para>
225 Here is an example:
226 <literallayout class='monospaced'>
227 BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
228 BB_DISKMON_WARNINTERVAL = "50M,5K"
229 </literallayout>
230 These variables cause BitBake to
231 issue subsequent warnings each time the available
232 disk space further reduces by 50 Mbytes or the number
233 of free inodes further reduces by 5 Kbytes in the
234 <filename>${SSTATE_DIR}</filename> directory.
235 Subsequent warnings based on the interval occur each time
236 a respective interval is reached beyond the initial warning
237 (i.e. 1 Gbytes and 100 Kbytes).
238 </para>
239 </glossdef>
240 </glossentry>
241
242 <glossentry id='var-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm>
243 <glossdef>
244 <para>
245 Causes tarballs of the Git repositories, including the
246 Git metadata, to be placed in the
247 <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
248 directory.
249 </para>
250
251 <para>
252 For performance reasons, creating and placing tarballs of
253 the Git repositories is not the default action by BitBake.
254 <literallayout class='monospaced'>
255 BB_GENERATE_MIRROR_TARBALLS = "1"
256 </literallayout>
257 </para>
258 </glossdef>
259 </glossentry>
260
261 <glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
262 <glossdef>
263 <para>The maximum number of tasks BitBake should run in parallel at any one time.
264 If your host development system supports multiple cores, a good rule of thumb
265 is to set this variable to twice the number of cores.</para>
266 </glossdef>
267 </glossentry>
268
269 <glossentry id='var-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm>
270 <glossdef>
271 <para>
272 Allows you to extend a recipe so that it builds variants of the software.
273 Common variants for recipes exist such as "natives" like <filename>quilt-native</filename>,
274 which is a copy of Quilt built to run on the build system;
275 "crosses" such as <filename>gcc-cross</filename>,
276 which is a compiler built to run on the build machine but produces binaries
277 that run on the target <filename>MACHINE</filename>;
278 "nativesdk", which targets the SDK machine instead of <filename>MACHINE</filename>;
279 and "mulitlibs" in the form "<filename>multilib:&lt;multilib_name&gt;</filename>".
280 </para>
281
282 <para>
283 To build a different variant of the recipe with a minimal amount of code, it usually
284 is as simple as adding the following to your recipe:
285 <literallayout class='monospaced'>
286 BBCLASSEXTEND =+ "native nativesdk"
287 BBCLASSEXTEND =+ "multilib:&lt;multilib_name&gt;"
288 </literallayout>
289 </para>
290 </glossdef>
291 </glossentry>
292
293 <glossentry id='var-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm>
294 <glossdef>
295 <para>Lists the names of configured layers.
296 These names are used to find the other <filename>BBFILE_*</filename>
297 variables.
298 Typically, each layer will append its name to this variable in its
299 <filename>conf/layer.conf</filename> file.
300 </para>
301 </glossdef>
302 </glossentry>
303
304 <glossentry id='var-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm>
305 <glossdef>
306 <para>Variable that expands to match files from
307 <link linkend='var-BBFILES'><filename>BBFILES</filename></link>
308 in a particular layer.
309 This variable is used in the <filename>conf/layer.conf</filename> file and must
310 be suffixed with the name of the specific layer (e.g.
311 <filename>BBFILE_PATTERN_emenlow</filename>).</para>
312 </glossdef>
313 </glossentry>
314
315 <glossentry id='var-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm>
316 <glossdef>
317 <para>Assigns the priority for recipe files in each layer.</para>
318 <para>This variable is useful in situations where the same recipe appears in
319 more than one layer.
320 Setting this variable allows you to prioritize a
321 layer against other layers that contain the same recipe - effectively
322 letting you control the precedence for the multiple layers.
323 The precedence established through this variable stands regardless of a
324 recipe's version
325 (<link linkend='var-PV'><filename>PV</filename></link> variable).
326 For example, a layer that has a recipe with a higher <filename>PV</filename> value but for
327 which the <filename>BBFILE_PRIORITY</filename> is set to have a lower precedence still has a
328 lower precedence.</para>
329 <para>A larger value for the <filename>BBFILE_PRIORITY</filename> variable results in a higher
330 precedence.
331 For example, the value 6 has a higher precedence than the value 5.
332 If not specified, the <filename>BBFILE_PRIORITY</filename> variable is set based on layer
333 dependencies (see the
334 <filename><link linkend='var-LAYERDEPENDS'>LAYERDEPENDS</link></filename> variable for
335 more information.
336 The default priority, if unspecified
337 for a layer with no dependencies, is the lowest defined priority + 1
338 (or 1 if no priorities are defined).</para>
339 <tip>
340 You can use the command <filename>bitbake-layers show-layers</filename> to list
341 all configured layers along with their priorities.
342 </tip>
343 </glossdef>
344 </glossentry>
345
346 <glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm>
347 <glossdef>
348 <para>List of recipe files used by BitBake to build software.</para>
349 </glossdef>
350 </glossentry>
351
352 <glossentry id='var-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm>
353 <glossdef>
354 <para>Variable that controls how BitBake displays logs on build failure.</para>
355 </glossdef>
356 </glossentry>
357
358 <glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm>
359 <glossdef>
360 <para>Lists the layers to enable during the build.
361 This variable is defined in the <filename>bblayers.conf</filename> configuration
362 file in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
363 Here is an example:
364 <literallayout class='monospaced'>
365 BBLAYERS = " \
366 /home/scottrif/poky/meta \
367 /home/scottrif/poky/meta-yocto \
368 /home/scottrif/poky/meta-yocto-bsp \
369 /home/scottrif/poky/meta-mykernel \
370 "
371
372 </literallayout>
373 This example enables four layers, one of which is a custom, user-defined layer
374 named <filename>meta-mykernel</filename>.
375 </para>
376 </glossdef>
377 </glossentry>
378
379 <glossentry id='var-BBMASK'><glossterm>BBMASK</glossterm>
380 <glossdef>
381 <para>
382 Prevents BitBake from processing recipes and recipe
383 append files.
384 </para>
385
386 <para>
387 You can use the <filename>BBMASK</filename> variable
388 to "hide" these <filename>.bb</filename> and
389 <filename>.bbappend</filename> files.
390 BitBake ignores any recipe or recipe append files that
391 match the expression.
392 It is as if BitBake does not see them at all.
393 Consequently, matching files are not parsed or otherwise
394 used by BitBake.</para>
395 <para>
396 The value you provide is passed to Python's regular
397 expression compiler.
398 The expression is compared against the full paths to
399 the files.
400 For complete syntax information, see Python's
401 documentation at
402 <ulink url='http://docs.python.org/release/2.3/lib/re-syntax.html'></ulink>.
403 </para>
404
405 <para>
406 The following example uses a complete regular expression
407 to tell BitBake to ignore all recipe and recipe append
408 files in the <filename>meta-ti/recipes-misc/</filename>
409 directory:
410 <literallayout class='monospaced'>
411 BBMASK = "meta-ti/recipes-misc/"
412 </literallayout>
413 If you want to mask out multiple directories or recipes,
414 use the vertical bar to separate the regular expression
415 fragments.
416 This next example masks out multiple directories and
417 individual recipes:
418 <literallayout class='monospaced'>
419 BBMASK = "meta-ti/recipes-misc/|meta-ti/recipes-ti/packagegroup/"
420 BBMASK .= "|.*meta-oe/recipes-support/"
421 BBMASK .= "|.*openldap"
422 BBMASK .= "|.*opencv"
423 BBMASK .= "|.*lzma"
424 </literallayout>
425 Notice how the vertical bar is used to append the fragments.
426 <note>
427 When specifying a directory name, use the trailing
428 slash character to ensure you match just that directory
429 name.
430 </note>
431 </para>
432 </glossdef>
433 </glossentry>
434
435 <glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm>
436 <glossdef>
437 <para>
438 Used by BitBake to locate
439 <filename>.bbclass</filename> and configuration files.
440 This variable is analogous to the
441 <filename>PATH</filename> variable.
442 <note>
443 If you run BitBake from a directory outside of the
444 <ulink url='&YOCTO_DOCS_DEV_URL;build-directory'>Build Directory</ulink>,
445 you must be sure to set
446 <filename>BBPATH</filename> to point to the
447 Build Directory.
448 Set the variable as you would any environment variable
449 and then run BitBake:
450 <literallayout class='monospaced'>
451 $ BBPATH = "&lt;build_directory&gt;"
452 $ export BBPATH
453 $ bitbake &lt;target&gt;
454 </literallayout>
455 </note>
456 </para>
457 </glossdef>
458 </glossentry>
459
460 <glossentry id='var-BBSERVER'><glossterm>BBSERVER</glossterm>
461 <glossdef>
462 <para>
463 Points to the server that runs memory-resident BitBake.
464 The variable is only used when you employ memory-resident
465 BitBake.
466 </para>
467 </glossdef>
468 </glossentry>
469
470 </glossdiv>
471
472<!--
473 <glossdiv id='var-glossary-c'><title>C</title>
474 </glossdiv>
475-->
476
477 <glossdiv id='var-glossary-d'><title>D</title>
478
479 <glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
480 <glossdef>
481 <para>
482 Specifies a weak bias for recipe selection priority.
483 </para>
484 <para>
485 The most common usage of this is variable is to set
486 it to "-1" within a recipe for a development version of a
487 piece of software.
488 Using the variable in this way causes the stable version
489 of the recipe to build by default in the absence of
490 <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
491 being used to build the development version.
492 </para>
493 <note>
494 The bias provided by <filename>DEFAULT_PREFERENCE</filename>
495 is weak and is overridden by
496 <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename>
497 if that variable is different between two layers
498 that contain different versions of the same recipe.
499 </note>
500 </glossdef>
501 </glossentry>
502
503 <glossentry id='var-DEPENDS'><glossterm>DEPENDS</glossterm>
504 <glossdef>
505 <para>
506 Lists a recipe's build-time dependencies
507 (i.e. other recipe files).
508 </para>
509
510 <para>
511 Consider this simple example for two recipes named "a" and
512 "b" that produce similarly named packages.
513 In this example, the <filename>DEPENDS</filename>
514 statement appears in the "a" recipe:
515 <literallayout class='monospaced'>
516 DEPENDS = "b"
517 </literallayout>
518 Here, the dependency is such that the
519 <filename>do_configure</filename> task for recipe "a"
520 depends on the <filename>do_populate_sysroot</filename>
521 task of recipe "b".
522 This means anything that recipe "b" puts into sysroot
523 is available when recipe "a" is configuring itself.
524 </para>
525
526 <para>
527 For information on runtime dependencies, see the
528 <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
529 variable.
530 </para>
531 </glossdef>
532 </glossentry>
533
534 <glossentry id='var-DESCRIPTION'><glossterm>DESCRIPTION</glossterm>
535 <glossdef>
536 <para>
537 A long description for the recipe.
538 </para>
539 </glossdef>
540 </glossentry>
541
542 <glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
543 <glossdef>
544 <para>
545 The central download directory used by the build process to
546 store downloads.
547 By default, <filename>DL_DIR</filename> gets files
548 suitable for mirroring for everything except Git
549 repositories.
550 If you want tarballs of Git repositories, use the
551 <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
552 variable.
553 </para>
554 </glossdef>
555
556 </glossentry>
557 </glossdiv>
558
559 <glossdiv id='var-glossary-e'><title>E</title>
560
561 <glossentry id='var-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm>
562 <glossdef>
563 <para>
564 Directs BitBake to exclude a recipe from world builds (i.e.
565 <filename>bitbake world</filename>).
566 During world builds, BitBake locates, parses and builds all
567 recipes found in every layer exposed in the
568 <filename>bblayers.conf</filename> configuration file.
569 </para>
570
571 <para>
572 To exclude a recipe from a world build using this variable,
573 set the variable to "1" in the recipe.
574 </para>
575
576 <note>
577 Recipes added to <filename>EXCLUDE_FROM_WORLD</filename>
578 may still be built during a world build in order to satisfy
579 dependencies of other recipes.
580 Adding a recipe to <filename>EXCLUDE_FROM_WORLD</filename>
581 only ensures that the recipe is not explicitly added
582 to the list of build targets in a world build.
583 </note>
584 </glossdef>
585 </glossentry>
586
587 </glossdiv>
588
589 <glossdiv id='var-glossary-f'><title>F</title>
590
591 <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
592 <glossdef>
593 <para>
594 The default set of directories BitBake
595 uses when searching for patches and files.
596 During the build process, BitBake searches each directory in
597 <filename>FILESPATH</filename> in the specified order when
598 looking for files and patches specified by each
599 <filename>file://</filename> URI in a recipe.
600 </para>
601 </glossdef>
602 </glossentry>
603
604 </glossdiv>
605
606<!--
607 <glossdiv id='var-glossary-g'><title>G</title>
608 </glossdiv>
609-->
610
611 <glossdiv id='var-glossary-h'><title>H</title>
612
613 <glossentry id='var-HOMEPAGE'><glossterm>HOMEPAGE</glossterm>
614 <glossdef>
615 <para>Website where more information about the software the recipe is building
616 can be found.</para>
617 </glossdef>
618 </glossentry>
619
620 </glossdiv>
621
622 <glossdiv id='var-glossary-i'><title>I</title>
623
624 <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
625 <glossdef>
626 <para>
627 Causes the named class to be inherited at
628 this point during parsing.
629 The variable is only valid in configuration files.
630 </para>
631 </glossdef>
632 </glossentry>
633
634 </glossdiv>
635
636<!--
637 <glossdiv id='var-glossary-j'><title>J</title>
638 </glossdiv>
639
640 <glossdiv id='var-glossary-k'><title>K</title>
641 </glossdiv>
642-->
643
644 <glossdiv id='var-glossary-l'><title>L</title>
645
646 <glossentry id='var-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm>
647 <glossdef>
648 <para>Lists the layers that this recipe depends upon, separated by spaces.
649 Optionally, you can specify a specific layer version for a dependency
650 by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3"
651 to be compared against
652 <link linkend='var-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename>
653 in this case).
654 An error will be produced if any dependency is missing or
655 the version numbers do not match exactly (if specified).
656 This variable is used in the <filename>conf/layer.conf</filename> file
657 and must be suffixed with the name of the specific layer (e.g.
658 <filename>LAYERDEPENDS_mylayer</filename>).</para>
659 </glossdef>
660 </glossentry>
661
662 <glossentry id='var-LAYERDIR'><glossterm>LAYERDIR</glossterm>
663 <glossdef>
664 <para>When used inside the <filename>layer.conf</filename> configuration
665 file, this variable provides the path of the current layer.
666 This variable is not available outside of <filename>layer.conf</filename>
667 and references are expanded immediately when parsing of the file completes.</para>
668 </glossdef>
669 </glossentry>
670
671 <glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
672 <glossdef>
673 <para>Optionally specifies the version of a layer as a single number.
674 You can use this within
675 <link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link>
676 for another layer in order to depend on a specific version
677 of the layer.
678 This variable is used in the <filename>conf/layer.conf</filename> file
679 and must be suffixed with the name of the specific layer (e.g.
680 <filename>LAYERVERSION_mylayer</filename>).</para>
681 </glossdef>
682 </glossentry>
683
684 <glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
685 <glossdef>
686 <para>
687 The list of source licenses for the recipe.
688 </para>
689 </glossdef>
690 </glossentry>
691
692 </glossdiv>
693
694 <glossdiv id='var-glossary-m'><title>M</title>
695
696 <glossentry id='var-MIRRORS'><glossterm>MIRRORS</glossterm>
697 <glossdef>
698 <para>
699 Specifies additional paths from which the BitBake gets source code.
700 When the build system searches for source code, it first
701 tries the local download directory.
702 If that location fails, the build system tries locations
703 defined by
704 <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>,
705 the upstream source, and then locations specified by
706 <filename>MIRRORS</filename> in that order.
707 </para>
708
709 <para>
710 Assuming your distribution (<filename>DISTRO</filename>)
711 is "poky", the default value for
712 <filename>MIRRORS</filename> is defined in the
713 <filename>conf/distro/poky.conf</filename> file in the
714 <filename>meta-yocto</filename> Git repository.
715 </para>
716 </glossdef>
717 </glossentry>
718
719 </glossdiv>
720
721<!--
722 <glossdiv id='var-glossary-n'><title>N</title>
723 </glossdiv>
724-->
725
726 <glossdiv id='var-glossary-o'><title>O</title>
727
728 <glossentry id='var-OVERRIDES'><glossterm>OVERRIDES</glossterm>
729 <glossdef>
730 <para>
731 BitBake uses <filename>OVERRIDES</filename> to control
732 what variables are overridden after BitBake parses
733 recipes and configuration files.
734 You can find more information on how overrides are handled
735 in the BitBake Manual that is located at
736 <filename>bitbake/doc/manual</filename> in the
737 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
738 </para>
739 </glossdef>
740 </glossentry>
741 </glossdiv>
742
743 <glossdiv id='var-glossary-p'><title>P</title>
744
745 <glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
746 <glossdef>
747 <para>The list of packages to be created from the recipe.
748 </para>
749 </glossdef>
750 </glossentry>
751
752 <glossentry id='var-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm>
753 <glossdef>
754 <para>
755 A promise that your recipe satisfies runtime dependencies
756 for optional modules that are found in other recipes.
757 <filename>PACKAGES_DYNAMIC</filename>
758 does not actually satisfy the dependencies, it only states that
759 they should be satisfied.
760 For example, if a hard, runtime dependency
761 (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
762 of another package is satisfied
763 at build time through the <filename>PACKAGES_DYNAMIC</filename>
764 variable, but a package with the module name is never actually
765 produced, then the other package will be broken.
766 Thus, if you attempt to include that package in an image,
767 you will get a dependency failure from the packaging system
768 during <filename>do_rootfs</filename>.
769 </para>
770 </glossdef>
771 </glossentry>
772
773 <glossentry id='var-PE'><glossterm>PE</glossterm>
774 <glossdef>
775 <para>
776 The epoch of the recipe.
777 By default, this variable is unset.
778 The field is used to make upgrades possible when the
779 versioning scheme changes in some backwards incompatible
780 way.
781 </para>
782 </glossdef>
783 </glossentry>
784
785 <glossentry id='var-PF'><glossterm>PF</glossterm>
786 <glossdef>
787 <para>
788 Specifies the recipe or package name and includes all version and revision
789 numbers (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
790 <filename>bash-4.2-r1/</filename>).
791 </para>
792 </glossdef>
793 </glossentry>
794
795 <glossentry id='var-PN'><glossterm>PN</glossterm>
796 <glossdef>
797 <para>The recipe name.</para>
798 </glossdef>
799 </glossentry>
800
801 <glossentry id='var-PR'><glossterm>PR</glossterm>
802 <glossdef>
803 <para>The revision of the recipe.
804 </para>
805 </glossdef>
806 </glossentry>
807
808 <glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
809 <glossdef>
810 <para>
811 If multiple recipes provide an item, this variable
812 determines which recipe should be given preference.
813 You should always suffix the variable with the name of the
814 provided item, and you should set it to the
815 <link linkend='var-PN'><filename>PN</filename></link>
816 of the recipe to which you want to give precedence.
817 Some examples:
818 <literallayout class='monospaced'>
819 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
820 PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
821 PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
822 </literallayout>
823 </para>
824 </glossdef>
825 </glossentry>
826
827 <glossentry id='var-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm>
828 <glossdef>
829 <para>
830 If there are multiple versions of recipes available, this
831 variable determines which recipe should be given preference.
832 You must always suffix the variable with the
833 <link linkend='var-PN'><filename>PN</filename></link>
834 you want to select, and you should set the
835 <link linkend='var-PV'><filename>PV</filename></link>
836 accordingly for precedence.
837 You can use the "<filename>%</filename>" character as a
838 wildcard to match any number of characters, which can be
839 useful when specifying versions that contain long revision
840 numbers that could potentially change.
841 Here are two examples:
842 <literallayout class='monospaced'>
843 PREFERRED_VERSION_python = "2.7.3"
844 PREFERRED_VERSION_linux-yocto = "3.10%"
845 </literallayout>
846 </para>
847 </glossdef>
848 </glossentry>
849
850 <glossentry id='var-PREMIRRORS'><glossterm>PREMIRRORS</glossterm>
851 <glossdef>
852 <para>
853 Specifies additional paths from which BitBake gets source code.
854 When the build system searches for source code, it first
855 tries the local download directory.
856 If that location fails, the build system tries locations
857 defined by <filename>PREMIRRORS</filename>, the upstream
858 source, and then locations specified by
859 <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
860 in that order.
861 </para>
862
863 <para>
864 Assuming your distribution
865 (<filename>DISTRO</filename>)
866 is "poky", the default value for
867 <filename>PREMIRRORS</filename> is defined in the
868 <filename>conf/distro/poky.conf</filename> file in the
869 <filename>meta-yocto</filename> Git repository.
870 </para>
871
872 <para>
873 Typically, you could add a specific server for the
874 build system to attempt before any others by adding
875 something like the following to your configuration:
876 <literallayout class='monospaced'>
877 PREMIRRORS_prepend = "\
878 git://.*/.* http://www.yoctoproject.org/sources/ \n \
879 ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
880 http://.*/.* http://www.yoctoproject.org/sources/ \n \
881 https://.*/.* http://www.yoctoproject.org/sources/ \n"
882 </literallayout>
883 These changes cause the build system to intercept
884 Git, FTP, HTTP, and HTTPS requests and direct them to
885 the <filename>http://</filename> sources mirror.
886 You can use <filename>file://</filename> URLs to point
887 to local directories or network shares as well.
888 </para>
889 </glossdef>
890 </glossentry>
891
892 <glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm>
893 <glossdef>
894 <para>
895 A list of aliases that a recipe also provides.
896 These aliases are useful for satisfying dependencies of
897 other recipes during the build (as specified by
898 <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>).
899 <note>
900 A recipe's own
901 <filename><link linkend='var-PN'>PN</link></filename>
902 is implicitly already in its
903 <filename>PROVIDES</filename> list.
904 </note>
905 </para>
906 </glossdef>
907 </glossentry>
908
909 <glossentry id='var-PRSERV_HOST'><glossterm>PRSERV_HOST</glossterm>
910 <glossdef>
911 <para>
912 The network based
913 <link linkend='var-PR'><filename>PR</filename></link>
914 service host and port.
915 </para>
916
917 <para>
918 An example of how the <filename>PRSERV_HOST</filename> variable is
919 set:
920 <literallayout class='monospaced'>
921 PRSERV_HOST = "localhost:0"
922 </literallayout>
923 You must set the variable if you want to automatically
924 start a local
925 <ulink url='&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service'>PR service</ulink>.
926 You can set <filename>PRSERV_HOST</filename> to other
927 values to use a remote PR service.
928 </para>
929 </glossdef>
930 </glossentry>
931
932 <glossentry id='var-PV'><glossterm>PV</glossterm>
933 <glossdef>
934 <para>The version of the recipe.
935 </para>
936 </glossdef>
937 </glossentry>
938
939 </glossdiv>
940
941<!--
942 <glossdiv id='var-glossary-q'><title>Q</title>
943 </glossdiv>
944-->
945
946 <glossdiv id='var-glossary-r'><title>R</title>
947
948 <glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
949 <glossdef>
950 <para>
951 Lists a package's runtime dependencies (i.e. other packages)
952 that must be installed in order for the built package to run
953 correctly.
954 If a package in this list cannot be found during the build,
955 you will get a build error.
956 </para>
957
958 <para>
959 Because the <filename>RDEPENDS</filename> variable applies
960 to packages being built, you should always use the variable
961 in a form with an attached package name.
962 For example, suppose you are building a development package
963 that depends on the <filename>perl</filename> package.
964 In this case, you would use the following
965 <filename>RDEPENDS</filename> statement:
966 <literallayout class='monospaced'>
967 RDEPENDS_${PN}-dev += "perl"
968 </literallayout>
969 In the example, the development package depends on
970 the <filename>perl</filename> package.
971 Thus, the <filename>RDEPENDS</filename> variable has the
972 <filename>${PN}-dev</filename> package name as part of the
973 variable.
974 </para>
975
976 <para>
977 BitBake supports specifying versioned dependencies.
978 Although the syntax varies depending on the packaging
979 format, BitBake hides these differences from you.
980 Here is the general syntax to specify versions with
981 the <filename>RDEPENDS</filename> variable:
982 <literallayout class='monospaced'>
983 RDEPENDS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
984 </literallayout>
985 For <filename>operator</filename>, you can specify the
986 following:
987 <literallayout class='monospaced'>
988 =
989 &lt;
990 &gt;
991 &lt;=
992 &gt;=
993 </literallayout>
994 For example, the following sets up a dependency on version
995 1.2 or greater of the package <filename>foo</filename>:
996 <literallayout class='monospaced'>
997 RDEPENDS_${PN} = "foo (>= 1.2)"
998 </literallayout>
999 </para>
1000
1001 <para>
1002 For information on build-time dependencies, see the
1003 <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
1004 variable.
1005 </para>
1006 </glossdef>
1007 </glossentry>
1008
1009 <glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
1010 <glossdef>
1011 <para>
1012 A list of package name aliases that a package also provides.
1013 These aliases are useful for satisfying runtime dependencies
1014 of other packages both during the build and on the target
1015 (as specified by
1016 <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
1017 </para>
1018 <para>
1019 As with all package-controlling variables, you must always
1020 use the variable in conjunction with a package name override.
1021 Here is an example:
1022 <literallayout class='monospaced'>
1023 RPROVIDES_${PN} = "widget-abi-2"
1024 </literallayout>
1025 </para>
1026 </glossdef>
1027 </glossentry>
1028
1029 <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
1030 <glossdef>
1031 <para>
1032 A list of packages that extends the usability of a package
1033 being built.
1034 The package being built does not depend on this list of
1035 packages in order to successfully build, but needs them for
1036 the extended usability.
1037 To specify runtime dependencies for packages, see the
1038 <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
1039 variable.
1040 </para>
1041
1042 <para>
1043 BitBake supports specifying versioned recommends.
1044 Although the syntax varies depending on the packaging
1045 format, BitBake hides these differences from you.
1046 Here is the general syntax to specify versions with
1047 the <filename>RRECOMMENDS</filename> variable:
1048 <literallayout class='monospaced'>
1049 RRECOMMENDS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
1050 </literallayout>
1051 For <filename>operator</filename>, you can specify the
1052 following:
1053 <literallayout class='monospaced'>
1054 =
1055 &lt;
1056 &gt;
1057 &lt;=
1058 &gt;=
1059 </literallayout>
1060 For example, the following sets up a recommend on version
1061 1.2 or greater of the package <filename>foo</filename>:
1062 <literallayout class='monospaced'>
1063 RRECOMMENDS_${PN} = "foo (>= 1.2)"
1064 </literallayout>
1065 </para>
1066 </glossdef>
1067 </glossentry>
1068
1069 </glossdiv>
1070
1071 <glossdiv id='var-glossary-s'><title>S</title>
1072
1073 <glossentry id='var-SECTION'><glossterm>SECTION</glossterm>
1074 <glossdef>
1075 <para>The section in which packages should be categorized.</para>
1076 </glossdef>
1077 </glossentry>
1078
1079 <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
1080 <glossdef>
1081 <para>The list of source files - local or remote.
1082 This variable tells BitBake which bits
1083 to pull in for the build and how to pull them in.
1084 For example, if the recipe or append file only needs to
1085 fetch a tarball from the Internet, the recipe or
1086 append file uses a single <filename>SRC_URI</filename>
1087 entry.
1088 On the other hand, if the recipe or append file needs to
1089 fetch a tarball, apply two patches, and include a custom
1090 file, the recipe or append file would include four
1091 instances of the variable.</para>
1092 <para>The following list explains the available URI protocols:
1093 <itemizedlist>
1094 <listitem><para><emphasis><filename>file://</filename> -</emphasis>
1095 Fetches files, which are usually files shipped with
1096 the
1097 <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
1098 from the local machine.
1099 The path is relative to the
1100 <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
1101 variable.
1102 Thus, the build system searches, in order, from the
1103 following directories, which are assumed to be a
1104 subdirectories of the directory in which the
1105 recipe file (<filename>.bb</filename>) or
1106 append file (<filename>.bbappend</filename>)
1107 resides:
1108 <itemizedlist>
1109 <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis>
1110 The base recipe name without any special
1111 suffix or version numbers.
1112 </para></listitem>
1113 <listitem><para><emphasis><filename>${BP}</filename> -</emphasis>
1114 <filename>${BPN}-${PV}</filename>.
1115 The base recipe name and version but without
1116 any special package name suffix.
1117 </para></listitem>
1118 <listitem><para><emphasis>files -</emphasis>
1119 Files within a directory, which is named
1120 <filename>files</filename> and is also
1121 alongside the recipe or append file.
1122 </para></listitem>
1123 </itemizedlist>
1124 <note>
1125 If you want the build system to pick up files
1126 specified through a
1127 <filename>SRC_URI</filename>
1128 statement from your append file, you need to be
1129 sure to extend the
1130 <filename>FILESPATH</filename>
1131 variable by also using the
1132 <filename>FILESEXTRAPATHS</filename>
1133 variable from within your append file.
1134 </note>
1135 </para></listitem>
1136 <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a
1137 Bazaar revision control repository.</para></listitem>
1138 <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
1139 Git revision control repository.</para></listitem>
1140 <listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from
1141 an OSC (OpenSUSE Build service) revision control repository.</para></listitem>
1142 <listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from
1143 a repo (Git) repository.</para></listitem>
1144 <listitem><para><emphasis><filename>svk://</filename> -</emphasis> Fetches files from
1145 an SVK revision control repository.</para></listitem>
1146 <listitem><para><emphasis><filename>http://</filename> -</emphasis> Fetches files from
1147 the Internet using <filename>http</filename>.</para></listitem>
1148 <listitem><para><emphasis><filename>https://</filename> -</emphasis> Fetches files
1149 from the Internet using <filename>https</filename>.</para></listitem>
1150 <listitem><para><emphasis><filename>ftp://</filename> -</emphasis> Fetches files
1151 from the Internet using <filename>ftp</filename>.</para></listitem>
1152 <listitem><para><emphasis><filename>cvs://</filename> -</emphasis> Fetches files from
1153 a CVS revision control repository.</para></listitem>
1154 <listitem><para><emphasis><filename>hg://</filename> -</emphasis> Fetches files from
1155 a Mercurial (<filename>hg</filename>) revision control repository.</para></listitem>
1156 <listitem><para><emphasis><filename>p4://</filename> -</emphasis> Fetches files from
1157 a Perforce (<filename>p4</filename>) revision control repository.</para></listitem>
1158 <listitem><para><emphasis><filename>ssh://</filename> -</emphasis> Fetches files from
1159 a secure shell.</para></listitem>
1160 <listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from
1161 a Subversion (<filename>svn</filename>) revision control repository.</para></listitem>
1162 </itemizedlist>
1163 </para>
1164 <para>Standard and recipe-specific options for <filename>SRC_URI</filename> exist.
1165 Here are standard options:
1166 <itemizedlist>
1167 <listitem><para><emphasis><filename>apply</filename> -</emphasis> Whether to apply
1168 the patch or not.
1169 The default action is to apply the patch.</para></listitem>
1170 <listitem><para><emphasis><filename>striplevel</filename> -</emphasis> Which
1171 striplevel to use when applying the patch.
1172 The default level is 1.</para></listitem>
1173 <listitem><para><emphasis><filename>patchdir</filename> -</emphasis> Specifies
1174 the directory in which the patch should be applied.
1175 The default is <filename>${S}</filename>.
1176 </para></listitem>
1177 </itemizedlist>
1178 </para>
1179 <para>Here are options specific to recipes building code from a revision control system:
1180 <itemizedlist>
1181 <listitem><para><emphasis><filename>mindate</filename> -</emphasis>
1182 Apply the patch only if
1183 <link linkend='var-SRCDATE'><filename>SRCDATE</filename></link>
1184 is equal to or greater than <filename>mindate</filename>.
1185 </para></listitem>
1186 <listitem><para><emphasis><filename>maxdate</filename> -</emphasis>
1187 Apply the patch only if <filename>SRCDATE</filename>
1188 is not later than <filename>mindate</filename>.
1189 </para></listitem>
1190 <listitem><para><emphasis><filename>minrev</filename> -</emphasis>
1191 Apply the patch only if <filename>SRCREV</filename>
1192 is equal to or greater than <filename>minrev</filename>.
1193 </para></listitem>
1194 <listitem><para><emphasis><filename>maxrev</filename> -</emphasis>
1195 Apply the patch only if <filename>SRCREV</filename>
1196 is not later than <filename>maxrev</filename>.
1197 </para></listitem>
1198 <listitem><para><emphasis><filename>rev</filename> -</emphasis>
1199 Apply the patch only if <filename>SRCREV</filename>
1200 is equal to <filename>rev</filename>.
1201 </para></listitem>
1202 <listitem><para><emphasis><filename>notrev</filename> -</emphasis>
1203 Apply the patch only if <filename>SRCREV</filename>
1204 is not equal to <filename>rev</filename>.
1205 </para></listitem>
1206 </itemizedlist>
1207 </para>
1208 <para>Here are some additional options worth mentioning:
1209 <itemizedlist>
1210 <listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls
1211 whether or not to unpack the file if it is an archive.
1212 The default action is to unpack the file.</para></listitem>
1213 <listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file
1214 (or extracts its contents) into the specified
1215 subdirectory of <filename>WORKDIR</filename>.
1216 This option is useful for unusual tarballs or other archives that
1217 do not have their files already in a subdirectory within the archive.
1218 </para></listitem>
1219 <listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a
1220 name to be used for association with <filename>SRC_URI</filename> checksums
1221 when you have more than one file specified in <filename>SRC_URI</filename>.
1222 </para></listitem>
1223 <listitem><para><emphasis><filename>downloadfilename</filename> -</emphasis> Specifies
1224 the filename used when storing the downloaded file.</para></listitem>
1225 </itemizedlist>
1226 </para>
1227 </glossdef>
1228 </glossentry>
1229
1230 <glossentry id='var-SRCDATE'><glossterm>SRCDATE</glossterm>
1231 <glossdef>
1232 <para>
1233 The date of the source code used to build the package.
1234 This variable applies only if the source was fetched from a Source Code Manager (SCM).
1235 </para>
1236 </glossdef>
1237 </glossentry>
1238
1239 <glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm>
1240 <glossdef>
1241 <para>
1242 The revision of the source code used to build the package.
1243 This variable applies to Subversion, Git, Mercurial and Bazaar
1244 only.
1245 Note that if you wish to build a fixed revision and you wish
1246 to avoid performing a query on the remote repository every time
1247 BitBake parses your recipe, you should specify a <filename>SRCREV</filename> that is a
1248 full revision identifier and not just a tag.
1249 </para>
1250 </glossdef>
1251 </glossentry>
1252
1253 <glossentry id='var-STAMP'><glossterm>STAMP</glossterm>
1254 <glossdef>
1255 <para>
1256 Specifies the base path used to create recipe stamp files.
1257 The path to an actual stamp file is constructed by evaluating this
1258 string and then appending additional information.
1259 </para>
1260 </glossdef>
1261 </glossentry>
1262
1263 <glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
1264 <glossdef>
1265 <para>
1266 A short (72 characters or less) summary for the recipe.
1267 </para>
1268 </glossdef>
1269 </glossentry>
1270
1271 </glossdiv>
1272
1273 <glossdiv id='var-glossary-t'><title>T</title>
1274
1275 <glossentry id='var-T'><glossterm>T</glossterm>
1276 <glossdef>
1277 <para>This variable points to a directory were BitBake places
1278 temporary files, which consist mostly of task logs and
1279 scripts, when building a particular recipe.
1280 </para>
1281 </glossdef>
1282 </glossentry>
1283
1284 <glossentry id='var-TOPDIR'><glossterm>TOPDIR</glossterm>
1285 <glossdef>
1286 <para>
1287 This variable points to the
1288 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
1289 BitBake automatically sets this variable.
1290 </para>
1291 </glossdef>
1292 </glossentry>
1293
1294 </glossdiv>
1295
1296<!--
1297 <glossdiv id='var-glossary-u'><title>U</title>
1298 </glossdiv>
1299
1300 <glossdiv id='var-glossary-v'><title>V</title>
1301 </glossdiv>
1302
1303 <glossdiv id='var-glossary-w'><title>W</title>
1304 </glossdiv>
1305
1306 <glossdiv id='var-glossary-x'><title>X</title>
1307 </glossdiv>
1308
1309 <glossdiv id='var-glossary-y'><title>Y</title>
1310 </glossdiv>
1311
1312 <glossdiv id='var-glossary-z'><title>Z</title>
1313 </glossdiv>
1314-->
1315
1316
1317</glossary>
1318</chapter>
1319<!--
1320vim: expandtab tw=80 ts=4
1321-->
diff --git a/bitbake/doc/user-manual/user-manual.xml b/bitbake/doc/user-manual/user-manual.xml
index cbe4509b75..e6307ee198 100644
--- a/bitbake/doc/user-manual/user-manual.xml
+++ b/bitbake/doc/user-manual/user-manual.xml
@@ -81,4 +81,6 @@
81 81
82 <xi:include href="user-manual-bitbakecommand.xml"/> 82 <xi:include href="user-manual-bitbakecommand.xml"/>
83 83
84 <xi:include href="user-manual-ref-variables.xml"/>
85
84</book> 86</book>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-05 19:15:23 +0000