diff options
| -rw-r--r-- | bitbake/doc/user-manual/user-manual-ref-variables.xml | 1321 | ||||
| -rw-r--r-- | bitbake/doc/user-manual/user-manual.xml | 2 |
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 = "<action>,<dir>,<threshold> [...]" | ||
| 100 | |||
| 101 | where: | ||
| 102 | |||
| 103 | <action> 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 | <dir> 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 | <threshold> 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 = "<disk_space_interval>,<disk_inode_interval>" | ||
| 209 | |||
| 210 | where: | ||
| 211 | |||
| 212 | <disk_space_interval> 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 | <disk_inode_interval> 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:<multilib_name></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:<multilib_name>" | ||
| 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 = "<build_directory>" | ||
| 452 | $ export BBPATH | ||
| 453 | $ bitbake <target> | ||
| 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} = "<package> (<operator> <version>)" | ||
| 984 | </literallayout> | ||
| 985 | For <filename>operator</filename>, you can specify the | ||
| 986 | following: | ||
| 987 | <literallayout class='monospaced'> | ||
| 988 | = | ||
| 989 | < | ||
| 990 | > | ||
| 991 | <= | ||
| 992 | >= | ||
| 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} = "<package> (<operator> <version>)" | ||
| 1050 | </literallayout> | ||
| 1051 | For <filename>operator</filename>, you can specify the | ||
| 1052 | following: | ||
| 1053 | <literallayout class='monospaced'> | ||
| 1054 | = | ||
| 1055 | < | ||
| 1056 | > | ||
| 1057 | <= | ||
| 1058 | >= | ||
| 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 | <!-- | ||
| 1320 | vim: 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> |
