diff options
author | Michael Opdenacker <michael.opdenacker@bootlin.com> | 2021-04-23 18:06:47 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-04-26 15:26:14 +0100 |
commit | 91aacf4ed312a6bbb07a3ccabf76618575b0e637 (patch) | |
tree | 6a0ef8345df063fe4d45761bd9d8b452c42d0120 /bitbake/doc | |
parent | a836bd6fc042f144e02be33cc69378dbaabd345c (diff) | |
download | poky-91aacf4ed312a6bbb07a3ccabf76618575b0e637.tar.gz |
bitbake: doc: bitbake-user-manual: simplify colon usage
- This replaces instances of ": ::" by "::", which
generates identical HTML output
(Bitbake rev: fd8ce4dcaff3aae395f9945fb0a3be54905e1727)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/doc')
6 files changed, 193 insertions, 193 deletions
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.rst index 56abf7735a..14c342a6a7 100644 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.rst +++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.rst | |||
@@ -16,7 +16,7 @@ data, or simply return information about the execution environment. | |||
16 | 16 | ||
17 | This chapter describes BitBake's execution process from start to finish | 17 | This chapter describes BitBake's execution process from start to finish |
18 | when you use it to create an image. The execution process is launched | 18 | when you use it to create an image. The execution process is launched |
19 | using the following command form: :: | 19 | using the following command form:: |
20 | 20 | ||
21 | $ bitbake target | 21 | $ bitbake target |
22 | 22 | ||
@@ -32,7 +32,7 @@ the BitBake command and its options, see ":ref:`The BitBake Command | |||
32 | your project's ``local.conf`` configuration file. | 32 | your project's ``local.conf`` configuration file. |
33 | 33 | ||
34 | A common method to determine this value for your build host is to run | 34 | A common method to determine this value for your build host is to run |
35 | the following: :: | 35 | the following:: |
36 | 36 | ||
37 | $ grep processor /proc/cpuinfo | 37 | $ grep processor /proc/cpuinfo |
38 | 38 | ||
@@ -139,7 +139,7 @@ in ``BBPATH`` in the same way as configuration files. | |||
139 | 139 | ||
140 | A good way to get an idea of the configuration files and the class files | 140 | A good way to get an idea of the configuration files and the class files |
141 | used in your execution environment is to run the following BitBake | 141 | used in your execution environment is to run the following BitBake |
142 | command: :: | 142 | command:: |
143 | 143 | ||
144 | $ bitbake -e > mybb.log | 144 | $ bitbake -e > mybb.log |
145 | 145 | ||
@@ -155,7 +155,7 @@ execution environment. | |||
155 | pair of curly braces in a shell function, the closing curly brace | 155 | pair of curly braces in a shell function, the closing curly brace |
156 | must not be located at the start of the line without leading spaces. | 156 | must not be located at the start of the line without leading spaces. |
157 | 157 | ||
158 | Here is an example that causes BitBake to produce a parsing error: :: | 158 | Here is an example that causes BitBake to produce a parsing error:: |
159 | 159 | ||
160 | fakeroot create_shar() { | 160 | fakeroot create_shar() { |
161 | cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh | 161 | cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh |
@@ -185,7 +185,7 @@ During the configuration phase, BitBake will have set | |||
185 | :term:`BBFILES`. BitBake now uses it to construct a | 185 | :term:`BBFILES`. BitBake now uses it to construct a |
186 | list of recipes to parse, along with any append files (``.bbappend``) to | 186 | list of recipes to parse, along with any append files (``.bbappend``) to |
187 | apply. ``BBFILES`` is a space-separated list of available files and | 187 | apply. ``BBFILES`` is a space-separated list of available files and |
188 | supports wildcards. An example would be: :: | 188 | supports wildcards. An example would be:: |
189 | 189 | ||
190 | BBFILES = "/path/to/bbfiles/*.bb /path/to/appends/*.bbappend" | 190 | BBFILES = "/path/to/bbfiles/*.bb /path/to/appends/*.bbappend" |
191 | 191 | ||
@@ -206,7 +206,7 @@ parses in order any append files found in ``BBFILES``. | |||
206 | One common convention is to use the recipe filename to define pieces of | 206 | One common convention is to use the recipe filename to define pieces of |
207 | metadata. For example, in ``bitbake.conf`` the recipe name and version | 207 | metadata. For example, in ``bitbake.conf`` the recipe name and version |
208 | are used to set the variables :term:`PN` and | 208 | are used to set the variables :term:`PN` and |
209 | :term:`PV`: :: | 209 | :term:`PV`:: |
210 | 210 | ||
211 | PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" | 211 | PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" |
212 | PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" | 212 | PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" |
@@ -238,7 +238,7 @@ Recipe file collections exist to allow the user to have multiple | |||
238 | repositories of ``.bb`` files that contain the same exact package. For | 238 | repositories of ``.bb`` files that contain the same exact package. For |
239 | example, one could easily use them to make one's own local copy of an | 239 | example, one could easily use them to make one's own local copy of an |
240 | upstream repository, but with custom modifications that one does not | 240 | upstream repository, but with custom modifications that one does not |
241 | want upstream. Here is an example: :: | 241 | want upstream. Here is an example:: |
242 | 242 | ||
243 | BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb" | 243 | BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb" |
244 | BBFILE_COLLECTIONS = "upstream local" | 244 | BBFILE_COLLECTIONS = "upstream local" |
@@ -270,7 +270,7 @@ variable, which is optional. | |||
270 | When a recipe uses ``PROVIDES``, that recipe's functionality can be | 270 | When a recipe uses ``PROVIDES``, that recipe's functionality can be |
271 | found under an alternative name or names other than the implicit ``PN`` | 271 | found under an alternative name or names other than the implicit ``PN`` |
272 | name. As an example, suppose a recipe named ``keyboard_1.0.bb`` | 272 | name. As an example, suppose a recipe named ``keyboard_1.0.bb`` |
273 | contained the following: :: | 273 | contained the following:: |
274 | 274 | ||
275 | PROVIDES += "fullkeyboard" | 275 | PROVIDES += "fullkeyboard" |
276 | 276 | ||
@@ -291,7 +291,7 @@ needs to prioritize providers by determining provider preferences. | |||
291 | A common example in which a target has multiple providers is | 291 | A common example in which a target has multiple providers is |
292 | "virtual/kernel", which is on the ``PROVIDES`` list for each kernel | 292 | "virtual/kernel", which is on the ``PROVIDES`` list for each kernel |
293 | recipe. Each machine often selects the best kernel provider by using a | 293 | recipe. Each machine often selects the best kernel provider by using a |
294 | line similar to the following in the machine configuration file: :: | 294 | line similar to the following in the machine configuration file:: |
295 | 295 | ||
296 | PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" | 296 | PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" |
297 | 297 | ||
@@ -331,7 +331,7 @@ If the first recipe is named ``a_1.1.bb``, then the | |||
331 | 331 | ||
332 | Thus, if a recipe named ``a_1.2.bb`` exists, BitBake will choose 1.2 by | 332 | Thus, if a recipe named ``a_1.2.bb`` exists, BitBake will choose 1.2 by |
333 | default. However, if you define the following variable in a ``.conf`` | 333 | default. However, if you define the following variable in a ``.conf`` |
334 | file that BitBake parses, you can change that preference: :: | 334 | file that BitBake parses, you can change that preference:: |
335 | 335 | ||
336 | PREFERRED_VERSION_a = "1.1" | 336 | PREFERRED_VERSION_a = "1.1" |
337 | 337 | ||
@@ -498,7 +498,7 @@ to the task. | |||
498 | 498 | ||
499 | Like the working directory case, situations exist where dependencies | 499 | Like the working directory case, situations exist where dependencies |
500 | should be ignored. For these cases, you can instruct the build process | 500 | should be ignored. For these cases, you can instruct the build process |
501 | to ignore a dependency by using a line like the following: :: | 501 | to ignore a dependency by using a line like the following:: |
502 | 502 | ||
503 | PACKAGE_ARCHS[vardepsexclude] = "MACHINE" | 503 | PACKAGE_ARCHS[vardepsexclude] = "MACHINE" |
504 | 504 | ||
@@ -508,7 +508,7 @@ even if it does reference it. | |||
508 | 508 | ||
509 | Equally, there are cases where we need to add dependencies BitBake is | 509 | Equally, there are cases where we need to add dependencies BitBake is |
510 | not able to find. You can accomplish this by using a line like the | 510 | not able to find. You can accomplish this by using a line like the |
511 | following: :: | 511 | following:: |
512 | 512 | ||
513 | PACKAGE_ARCHS[vardeps] = "MACHINE" | 513 | PACKAGE_ARCHS[vardeps] = "MACHINE" |
514 | 514 | ||
@@ -536,7 +536,7 @@ configuration file, we can give BitBake some extra information to help | |||
536 | it construct the basehash. The following statement effectively results | 536 | it construct the basehash. The following statement effectively results |
537 | in a list of global variable dependency excludes - variables never | 537 | in a list of global variable dependency excludes - variables never |
538 | included in any checksum. This example uses variables from OpenEmbedded | 538 | included in any checksum. This example uses variables from OpenEmbedded |
539 | to help illustrate the concept: :: | 539 | to help illustrate the concept:: |
540 | 540 | ||
541 | BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \ | 541 | BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \ |
542 | SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL \ | 542 | SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL \ |
@@ -557,7 +557,7 @@ OpenEmbedded-Core uses: "OEBasic" and "OEBasicHash". By default, there | |||
557 | is a dummy "noop" signature handler enabled in BitBake. This means that | 557 | is a dummy "noop" signature handler enabled in BitBake. This means that |
558 | behavior is unchanged from previous versions. ``OE-Core`` uses the | 558 | behavior is unchanged from previous versions. ``OE-Core`` uses the |
559 | "OEBasicHash" signature handler by default through this setting in the | 559 | "OEBasicHash" signature handler by default through this setting in the |
560 | ``bitbake.conf`` file: :: | 560 | ``bitbake.conf`` file:: |
561 | 561 | ||
562 | BB_SIGNATURE_HANDLER ?= "OEBasicHash" | 562 | BB_SIGNATURE_HANDLER ?= "OEBasicHash" |
563 | 563 | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst index 626278e444..3167ab1380 100644 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst +++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst | |||
@@ -27,7 +27,7 @@ and unpacking the files is often optionally followed by patching. | |||
27 | Patching, however, is not covered by this module. | 27 | Patching, however, is not covered by this module. |
28 | 28 | ||
29 | The code to execute the first part of this process, a fetch, looks | 29 | The code to execute the first part of this process, a fetch, looks |
30 | something like the following: :: | 30 | something like the following:: |
31 | 31 | ||
32 | src_uri = (d.getVar('SRC_URI') or "").split() | 32 | src_uri = (d.getVar('SRC_URI') or "").split() |
33 | fetcher = bb.fetch2.Fetch(src_uri, d) | 33 | fetcher = bb.fetch2.Fetch(src_uri, d) |
@@ -37,7 +37,7 @@ This code sets up an instance of the fetch class. The instance uses a | |||
37 | space-separated list of URLs from the :term:`SRC_URI` | 37 | space-separated list of URLs from the :term:`SRC_URI` |
38 | variable and then calls the ``download`` method to download the files. | 38 | variable and then calls the ``download`` method to download the files. |
39 | 39 | ||
40 | The instantiation of the fetch class is usually followed by: :: | 40 | The instantiation of the fetch class is usually followed by:: |
41 | 41 | ||
42 | rootdir = l.getVar('WORKDIR') | 42 | rootdir = l.getVar('WORKDIR') |
43 | fetcher.unpack(rootdir) | 43 | fetcher.unpack(rootdir) |
@@ -72,7 +72,7 @@ URLs by looking for source files in a specific search order: | |||
72 | For each URL passed to the fetcher, the fetcher calls the submodule that | 72 | For each URL passed to the fetcher, the fetcher calls the submodule that |
73 | handles that particular URL type. This behavior can be the source of | 73 | handles that particular URL type. This behavior can be the source of |
74 | some confusion when you are providing URLs for the ``SRC_URI`` variable. | 74 | some confusion when you are providing URLs for the ``SRC_URI`` variable. |
75 | Consider the following two URLs: :: | 75 | Consider the following two URLs:: |
76 | 76 | ||
77 | http://git.yoctoproject.org/git/poky;protocol=git | 77 | http://git.yoctoproject.org/git/poky;protocol=git |
78 | git://git.yoctoproject.org/git/poky;protocol=http | 78 | git://git.yoctoproject.org/git/poky;protocol=http |
@@ -81,7 +81,7 @@ In the former case, the URL is passed to the ``wget`` fetcher, which does not | |||
81 | understand "git". Therefore, the latter case is the correct form since the Git | 81 | understand "git". Therefore, the latter case is the correct form since the Git |
82 | fetcher does know how to use HTTP as a transport. | 82 | fetcher does know how to use HTTP as a transport. |
83 | 83 | ||
84 | Here are some examples that show commonly used mirror definitions: :: | 84 | Here are some examples that show commonly used mirror definitions:: |
85 | 85 | ||
86 | PREMIRRORS ?= "\ | 86 | PREMIRRORS ?= "\ |
87 | bzr://.*/.\* http://somemirror.org/sources/ \\n \ | 87 | bzr://.*/.\* http://somemirror.org/sources/ \\n \ |
@@ -111,19 +111,19 @@ File integrity is of key importance for reproducing builds. For | |||
111 | non-local archive downloads, the fetcher code can verify SHA-256 and MD5 | 111 | non-local archive downloads, the fetcher code can verify SHA-256 and MD5 |
112 | checksums to ensure the archives have been downloaded correctly. You can | 112 | checksums to ensure the archives have been downloaded correctly. You can |
113 | specify these checksums by using the ``SRC_URI`` variable with the | 113 | specify these checksums by using the ``SRC_URI`` variable with the |
114 | appropriate varflags as follows: :: | 114 | appropriate varflags as follows:: |
115 | 115 | ||
116 | SRC_URI[md5sum] = "value" | 116 | SRC_URI[md5sum] = "value" |
117 | SRC_URI[sha256sum] = "value" | 117 | SRC_URI[sha256sum] = "value" |
118 | 118 | ||
119 | You can also specify the checksums as | 119 | You can also specify the checksums as |
120 | parameters on the ``SRC_URI`` as shown below: :: | 120 | parameters on the ``SRC_URI`` as shown below:: |
121 | 121 | ||
122 | SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d" | 122 | SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d" |
123 | 123 | ||
124 | If multiple URIs exist, you can specify the checksums either directly as | 124 | If multiple URIs exist, you can specify the checksums either directly as |
125 | in the previous example, or you can name the URLs. The following syntax | 125 | in the previous example, or you can name the URLs. The following syntax |
126 | shows how you name the URIs: :: | 126 | shows how you name the URIs:: |
127 | 127 | ||
128 | SRC_URI = "http://example.com/foobar.tar.bz2;name=foo" | 128 | SRC_URI = "http://example.com/foobar.tar.bz2;name=foo" |
129 | SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d | 129 | SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d |
@@ -201,7 +201,7 @@ time the ``download()`` method is called. | |||
201 | If you specify a directory, the entire directory is unpacked. | 201 | If you specify a directory, the entire directory is unpacked. |
202 | 202 | ||
203 | Here are a couple of example URLs, the first relative and the second | 203 | Here are a couple of example URLs, the first relative and the second |
204 | absolute: :: | 204 | absolute:: |
205 | 205 | ||
206 | SRC_URI = "file://relativefile.patch" | 206 | SRC_URI = "file://relativefile.patch" |
207 | SRC_URI = "file:///Users/ich/very_important_software" | 207 | SRC_URI = "file:///Users/ich/very_important_software" |
@@ -222,7 +222,7 @@ downloaded file is useful for avoiding collisions in | |||
222 | :term:`DL_DIR` when dealing with multiple files that | 222 | :term:`DL_DIR` when dealing with multiple files that |
223 | have the same name. | 223 | have the same name. |
224 | 224 | ||
225 | Some example URLs are as follows: :: | 225 | Some example URLs are as follows:: |
226 | 226 | ||
227 | SRC_URI = "http://oe.handhelds.org/not_there.aac" | 227 | SRC_URI = "http://oe.handhelds.org/not_there.aac" |
228 | SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac" | 228 | SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac" |
@@ -318,7 +318,7 @@ The supported parameters are as follows: | |||
318 | 318 | ||
319 | - *"port":* The port to which the CVS server connects. | 319 | - *"port":* The port to which the CVS server connects. |
320 | 320 | ||
321 | Some example URLs are as follows: :: | 321 | Some example URLs are as follows:: |
322 | 322 | ||
323 | SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext" | 323 | SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext" |
324 | SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat" | 324 | SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat" |
@@ -360,7 +360,7 @@ The supported parameters are as follows: | |||
360 | username is different than the username used in the main URL, which | 360 | username is different than the username used in the main URL, which |
361 | is passed to the subversion command. | 361 | is passed to the subversion command. |
362 | 362 | ||
363 | Following are three examples using svn: :: | 363 | Following are three examples using svn:: |
364 | 364 | ||
365 | SRC_URI = "svn://myrepos/proj1;module=vip;protocol=http;rev=667" | 365 | SRC_URI = "svn://myrepos/proj1;module=vip;protocol=http;rev=667" |
366 | SRC_URI = "svn://myrepos/proj1;module=opie;protocol=svn+ssh" | 366 | SRC_URI = "svn://myrepos/proj1;module=opie;protocol=svn+ssh" |
@@ -433,7 +433,7 @@ This fetcher supports the following parameters: | |||
433 | parameter implies no branch and only works when the transfer protocol | 433 | parameter implies no branch and only works when the transfer protocol |
434 | is ``file://``. | 434 | is ``file://``. |
435 | 435 | ||
436 | Here are some example URLs: :: | 436 | Here are some example URLs:: |
437 | 437 | ||
438 | SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1" | 438 | SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1" |
439 | SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http" | 439 | SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http" |
@@ -481,7 +481,7 @@ repository. | |||
481 | 481 | ||
482 | To use this fetcher, make sure your recipe has proper | 482 | To use this fetcher, make sure your recipe has proper |
483 | :term:`SRC_URI`, :term:`SRCREV`, and | 483 | :term:`SRC_URI`, :term:`SRCREV`, and |
484 | :term:`PV` settings. Here is an example: :: | 484 | :term:`PV` settings. Here is an example:: |
485 | 485 | ||
486 | SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module" | 486 | SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module" |
487 | SRCREV = "EXAMPLE_CLEARCASE_TAG" | 487 | SRCREV = "EXAMPLE_CLEARCASE_TAG" |
@@ -503,7 +503,7 @@ Following are options for the ``SRC_URI`` statement: | |||
503 | The module and vob options are combined to create the load rule in the | 503 | The module and vob options are combined to create the load rule in the |
504 | view config spec. As an example, consider the vob and module values from | 504 | view config spec. As an example, consider the vob and module values from |
505 | the SRC_URI statement at the start of this section. Combining those values | 505 | the SRC_URI statement at the start of this section. Combining those values |
506 | results in the following: :: | 506 | results in the following:: |
507 | 507 | ||
508 | load /example_vob/example_module | 508 | load /example_vob/example_module |
509 | 509 | ||
@@ -555,7 +555,7 @@ the server's URL and port number, and you can specify a username and | |||
555 | password directly in your recipe within ``SRC_URI``. | 555 | password directly in your recipe within ``SRC_URI``. |
556 | 556 | ||
557 | Here is an example that relies on ``P4CONFIG`` to specify the server URL | 557 | Here is an example that relies on ``P4CONFIG`` to specify the server URL |
558 | and port, username, and password, and fetches the Head Revision: :: | 558 | and port, username, and password, and fetches the Head Revision:: |
559 | 559 | ||
560 | SRC_URI = "p4://example-depot/main/source/..." | 560 | SRC_URI = "p4://example-depot/main/source/..." |
561 | SRCREV = "${AUTOREV}" | 561 | SRCREV = "${AUTOREV}" |
@@ -563,7 +563,7 @@ and port, username, and password, and fetches the Head Revision: :: | |||
563 | S = "${WORKDIR}/p4" | 563 | S = "${WORKDIR}/p4" |
564 | 564 | ||
565 | Here is an example that specifies the server URL and port, username, and | 565 | Here is an example that specifies the server URL and port, username, and |
566 | password, and fetches a Revision based on a Label: :: | 566 | password, and fetches a Revision based on a Label:: |
567 | 567 | ||
568 | P4PORT = "tcp:p4server.example.net:1666" | 568 | P4PORT = "tcp:p4server.example.net:1666" |
569 | SRC_URI = "p4://user:passwd@example-depot/main/source/..." | 569 | SRC_URI = "p4://user:passwd@example-depot/main/source/..." |
@@ -589,7 +589,7 @@ paths locally is desirable, the fetcher supports two parameters: | |||
589 | paths locally for the specified location, even in combination with the | 589 | paths locally for the specified location, even in combination with the |
590 | ``module`` parameter. | 590 | ``module`` parameter. |
591 | 591 | ||
592 | Here is an example use of the the ``module`` parameter: :: | 592 | Here is an example use of the the ``module`` parameter:: |
593 | 593 | ||
594 | SRC_URI = "p4://user:passwd@example-depot/main;module=source/..." | 594 | SRC_URI = "p4://user:passwd@example-depot/main;module=source/..." |
595 | 595 | ||
@@ -597,7 +597,7 @@ In this case, the content of the top-level directory ``source/`` will be fetched | |||
597 | to ``${P4DIR}``, including the directory itself. The top-level directory will | 597 | to ``${P4DIR}``, including the directory itself. The top-level directory will |
598 | be accesible at ``${P4DIR}/source/``. | 598 | be accesible at ``${P4DIR}/source/``. |
599 | 599 | ||
600 | Here is an example use of the the ``remotepath`` parameter: :: | 600 | Here is an example use of the the ``remotepath`` parameter:: |
601 | 601 | ||
602 | SRC_URI = "p4://user:passwd@example-depot/main;module=source/...;remotepath=keep" | 602 | SRC_URI = "p4://user:passwd@example-depot/main;module=source/...;remotepath=keep" |
603 | 603 | ||
@@ -625,7 +625,7 @@ This fetcher supports the following parameters: | |||
625 | 625 | ||
626 | - *"manifest":* Name of the manifest file (default: ``default.xml``). | 626 | - *"manifest":* Name of the manifest file (default: ``default.xml``). |
627 | 627 | ||
628 | Here are some example URLs: :: | 628 | Here are some example URLs:: |
629 | 629 | ||
630 | SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml" | 630 | SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml" |
631 | SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml" | 631 | SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml" |
@@ -648,11 +648,11 @@ Such functionality is set by the variable: | |||
648 | delegate access to resources, if this variable is set, the Az Fetcher will | 648 | delegate access to resources, if this variable is set, the Az Fetcher will |
649 | use it when fetching artifacts from the cloud. | 649 | use it when fetching artifacts from the cloud. |
650 | 650 | ||
651 | You can specify the AZ_SAS variable as shown below: :: | 651 | You can specify the AZ_SAS variable as shown below:: |
652 | 652 | ||
653 | AZ_SAS = "se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>" | 653 | AZ_SAS = "se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>" |
654 | 654 | ||
655 | Here is an example URL: :: | 655 | Here is an example URL:: |
656 | 656 | ||
657 | SRC_URI = "az://<azure-storage-account>.blob.core.windows.net/<foo_container>/<bar_file>" | 657 | SRC_URI = "az://<azure-storage-account>.blob.core.windows.net/<foo_container>/<bar_file>" |
658 | 658 | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.rst index e3fd321588..62a0b597dd 100644 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.rst +++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.rst | |||
@@ -20,7 +20,7 @@ Obtaining BitBake | |||
20 | 20 | ||
21 | See the :ref:`bitbake-user-manual/bitbake-user-manual-hello:obtaining bitbake` section for | 21 | See the :ref:`bitbake-user-manual/bitbake-user-manual-hello:obtaining bitbake` section for |
22 | information on how to obtain BitBake. Once you have the source code on | 22 | information on how to obtain BitBake. Once you have the source code on |
23 | your machine, the BitBake directory appears as follows: :: | 23 | your machine, the BitBake directory appears as follows:: |
24 | 24 | ||
25 | $ ls -al | 25 | $ ls -al |
26 | total 100 | 26 | total 100 |
@@ -49,7 +49,7 @@ Setting Up the BitBake Environment | |||
49 | 49 | ||
50 | First, you need to be sure that you can run BitBake. Set your working | 50 | First, you need to be sure that you can run BitBake. Set your working |
51 | directory to where your local BitBake files are and run the following | 51 | directory to where your local BitBake files are and run the following |
52 | command: :: | 52 | command:: |
53 | 53 | ||
54 | $ ./bin/bitbake --version | 54 | $ ./bin/bitbake --version |
55 | BitBake Build Tool Core version 1.23.0, bitbake version 1.23.0 | 55 | BitBake Build Tool Core version 1.23.0, bitbake version 1.23.0 |
@@ -61,14 +61,14 @@ The recommended method to run BitBake is from a directory of your | |||
61 | choice. To be able to run BitBake from any directory, you need to add | 61 | choice. To be able to run BitBake from any directory, you need to add |
62 | the executable binary to your binary to your shell's environment | 62 | the executable binary to your binary to your shell's environment |
63 | ``PATH`` variable. First, look at your current ``PATH`` variable by | 63 | ``PATH`` variable. First, look at your current ``PATH`` variable by |
64 | entering the following: :: | 64 | entering the following:: |
65 | 65 | ||
66 | $ echo $PATH | 66 | $ echo $PATH |
67 | 67 | ||
68 | Next, add the directory location | 68 | Next, add the directory location |
69 | for the BitBake binary to the ``PATH``. Here is an example that adds the | 69 | for the BitBake binary to the ``PATH``. Here is an example that adds the |
70 | ``/home/scott-lenovo/bitbake/bin`` directory to the front of the | 70 | ``/home/scott-lenovo/bitbake/bin`` directory to the front of the |
71 | ``PATH`` variable: :: | 71 | ``PATH`` variable:: |
72 | 72 | ||
73 | $ export PATH=/home/scott-lenovo/bitbake/bin:$PATH | 73 | $ export PATH=/home/scott-lenovo/bitbake/bin:$PATH |
74 | 74 | ||
@@ -116,7 +116,7 @@ Following is the complete "Hello World" example. | |||
116 | 116 | ||
117 | #. **Create a Project Directory:** First, set up a directory for the | 117 | #. **Create a Project Directory:** First, set up a directory for the |
118 | "Hello World" project. Here is how you can do so in your home | 118 | "Hello World" project. Here is how you can do so in your home |
119 | directory: :: | 119 | directory:: |
120 | 120 | ||
121 | $ mkdir ~/hello | 121 | $ mkdir ~/hello |
122 | $ cd ~/hello | 122 | $ cd ~/hello |
@@ -127,7 +127,7 @@ Following is the complete "Hello World" example. | |||
127 | directory is a good way to isolate your project. | 127 | directory is a good way to isolate your project. |
128 | 128 | ||
129 | #. **Run BitBake:** At this point, you have nothing but a project | 129 | #. **Run BitBake:** At this point, you have nothing but a project |
130 | directory. Run the ``bitbake`` command and see what it does: :: | 130 | directory. Run the ``bitbake`` command and see what it does:: |
131 | 131 | ||
132 | $ bitbake | 132 | $ bitbake |
133 | The BBPATH variable is not set and bitbake did not | 133 | The BBPATH variable is not set and bitbake did not |
@@ -161,7 +161,7 @@ Following is the complete "Hello World" example. | |||
161 | ``BBPATH`` variable up in a configuration file for each project. | 161 | ``BBPATH`` variable up in a configuration file for each project. |
162 | 162 | ||
163 | From your shell, enter the following commands to set and export the | 163 | From your shell, enter the following commands to set and export the |
164 | ``BBPATH`` variable: :: | 164 | ``BBPATH`` variable:: |
165 | 165 | ||
166 | $ BBPATH="projectdirectory" | 166 | $ BBPATH="projectdirectory" |
167 | $ export BBPATH | 167 | $ export BBPATH |
@@ -176,7 +176,7 @@ Following is the complete "Hello World" example. | |||
176 | shell would. | 176 | shell would. |
177 | 177 | ||
178 | #. **Run BitBake:** Now that you have ``BBPATH`` defined, run the | 178 | #. **Run BitBake:** Now that you have ``BBPATH`` defined, run the |
179 | ``bitbake`` command again: :: | 179 | ``bitbake`` command again:: |
180 | 180 | ||
181 | $ bitbake | 181 | $ bitbake |
182 | ERROR: Traceback (most recent call last): | 182 | ERROR: Traceback (most recent call last): |
@@ -208,13 +208,13 @@ Following is the complete "Hello World" example. | |||
208 | http://git.openembedded.org/bitbake/tree/conf/bitbake.conf. | 208 | http://git.openembedded.org/bitbake/tree/conf/bitbake.conf. |
209 | 209 | ||
210 | Use the following commands to create the ``conf`` directory in the | 210 | Use the following commands to create the ``conf`` directory in the |
211 | project directory: :: | 211 | project directory:: |
212 | 212 | ||
213 | $ mkdir conf | 213 | $ mkdir conf |
214 | 214 | ||
215 | From within the ``conf`` directory, | 215 | From within the ``conf`` directory, |
216 | use some editor to create the ``bitbake.conf`` so that it contains | 216 | use some editor to create the ``bitbake.conf`` so that it contains |
217 | the following: :: | 217 | the following:: |
218 | 218 | ||
219 | PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" | 219 | PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" |
220 | 220 | ||
@@ -251,7 +251,7 @@ Following is the complete "Hello World" example. | |||
251 | glossary. | 251 | glossary. |
252 | 252 | ||
253 | #. **Run BitBake:** After making sure that the ``conf/bitbake.conf`` file | 253 | #. **Run BitBake:** After making sure that the ``conf/bitbake.conf`` file |
254 | exists, you can run the ``bitbake`` command again: :: | 254 | exists, you can run the ``bitbake`` command again:: |
255 | 255 | ||
256 | $ bitbake | 256 | $ bitbake |
257 | ERROR: Traceback (most recent call last): | 257 | ERROR: Traceback (most recent call last): |
@@ -278,7 +278,7 @@ Following is the complete "Hello World" example. | |||
278 | in the ``classes`` directory of the project (i.e ``hello/classes`` | 278 | in the ``classes`` directory of the project (i.e ``hello/classes`` |
279 | in this example). | 279 | in this example). |
280 | 280 | ||
281 | Create the ``classes`` directory as follows: :: | 281 | Create the ``classes`` directory as follows:: |
282 | 282 | ||
283 | $ cd $HOME/hello | 283 | $ cd $HOME/hello |
284 | $ mkdir classes | 284 | $ mkdir classes |
@@ -291,7 +291,7 @@ Following is the complete "Hello World" example. | |||
291 | environments BitBake is supporting. | 291 | environments BitBake is supporting. |
292 | 292 | ||
293 | #. **Run BitBake:** After making sure that the ``classes/base.bbclass`` | 293 | #. **Run BitBake:** After making sure that the ``classes/base.bbclass`` |
294 | file exists, you can run the ``bitbake`` command again: :: | 294 | file exists, you can run the ``bitbake`` command again:: |
295 | 295 | ||
296 | $ bitbake | 296 | $ bitbake |
297 | Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information. | 297 | Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information. |
@@ -314,7 +314,7 @@ Following is the complete "Hello World" example. | |||
314 | Minimally, you need a recipe file and a layer configuration file in | 314 | Minimally, you need a recipe file and a layer configuration file in |
315 | your layer. The configuration file needs to be in the ``conf`` | 315 | your layer. The configuration file needs to be in the ``conf`` |
316 | directory inside the layer. Use these commands to set up the layer | 316 | directory inside the layer. Use these commands to set up the layer |
317 | and the ``conf`` directory: :: | 317 | and the ``conf`` directory:: |
318 | 318 | ||
319 | $ cd $HOME | 319 | $ cd $HOME |
320 | $ mkdir mylayer | 320 | $ mkdir mylayer |
@@ -322,7 +322,7 @@ Following is the complete "Hello World" example. | |||
322 | $ mkdir conf | 322 | $ mkdir conf |
323 | 323 | ||
324 | Move to the ``conf`` directory and create a ``layer.conf`` file that has the | 324 | Move to the ``conf`` directory and create a ``layer.conf`` file that has the |
325 | following: :: | 325 | following:: |
326 | 326 | ||
327 | BBPATH .= ":${LAYERDIR}" | 327 | BBPATH .= ":${LAYERDIR}" |
328 | BBFILES += "${LAYERDIR}/\*.bb" | 328 | BBFILES += "${LAYERDIR}/\*.bb" |
@@ -335,7 +335,7 @@ Following is the complete "Hello World" example. | |||
335 | 335 | ||
336 | You need to create the recipe file next. Inside your layer at the | 336 | You need to create the recipe file next. Inside your layer at the |
337 | top-level, use an editor and create a recipe file named | 337 | top-level, use an editor and create a recipe file named |
338 | ``printhello.bb`` that has the following: :: | 338 | ``printhello.bb`` that has the following:: |
339 | 339 | ||
340 | DESCRIPTION = "Prints Hello World" | 340 | DESCRIPTION = "Prints Hello World" |
341 | PN = 'printhello' | 341 | PN = 'printhello' |
@@ -356,7 +356,7 @@ Following is the complete "Hello World" example. | |||
356 | follow the links to the glossary. | 356 | follow the links to the glossary. |
357 | 357 | ||
358 | #. **Run BitBake With a Target:** Now that a BitBake target exists, run | 358 | #. **Run BitBake With a Target:** Now that a BitBake target exists, run |
359 | the command and provide that target: :: | 359 | the command and provide that target:: |
360 | 360 | ||
361 | $ cd $HOME/hello | 361 | $ cd $HOME/hello |
362 | $ bitbake printhello | 362 | $ bitbake printhello |
@@ -376,7 +376,7 @@ Following is the complete "Hello World" example. | |||
376 | ``hello/conf`` for this example). | 376 | ``hello/conf`` for this example). |
377 | 377 | ||
378 | Set your working directory to the ``hello/conf`` directory and then | 378 | Set your working directory to the ``hello/conf`` directory and then |
379 | create the ``bblayers.conf`` file so that it contains the following: :: | 379 | create the ``bblayers.conf`` file so that it contains the following:: |
380 | 380 | ||
381 | BBLAYERS ?= " \ | 381 | BBLAYERS ?= " \ |
382 | /home/<you>/mylayer \ | 382 | /home/<you>/mylayer \ |
@@ -386,7 +386,7 @@ Following is the complete "Hello World" example. | |||
386 | 386 | ||
387 | #. **Run BitBake With a Target:** Now that you have supplied the | 387 | #. **Run BitBake With a Target:** Now that you have supplied the |
388 | ``bblayers.conf`` file, run the ``bitbake`` command and provide the | 388 | ``bblayers.conf`` file, run the ``bitbake`` command and provide the |
389 | target: :: | 389 | target:: |
390 | 390 | ||
391 | $ bitbake printhello | 391 | $ bitbake printhello |
392 | Parsing recipes: 100% |##################################################################################| | 392 | Parsing recipes: 100% |##################################################################################| |
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.rst index 6f9d392935..b3cea61fff 100644 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.rst +++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.rst | |||
@@ -248,13 +248,13 @@ underlying, similarly-named recipe files. | |||
248 | 248 | ||
249 | When you name an append file, you can use the "``%``" wildcard character | 249 | When you name an append file, you can use the "``%``" wildcard character |
250 | to allow for matching recipe names. For example, suppose you have an | 250 | to allow for matching recipe names. For example, suppose you have an |
251 | append file named as follows: :: | 251 | append file named as follows:: |
252 | 252 | ||
253 | busybox_1.21.%.bbappend | 253 | busybox_1.21.%.bbappend |
254 | 254 | ||
255 | That append file | 255 | That append file |
256 | would match any ``busybox_1.21.``\ x\ ``.bb`` version of the recipe. So, | 256 | would match any ``busybox_1.21.``\ x\ ``.bb`` version of the recipe. So, |
257 | the append file would match the following recipe names: :: | 257 | the append file would match the following recipe names:: |
258 | 258 | ||
259 | busybox_1.21.1.bb | 259 | busybox_1.21.1.bb |
260 | busybox_1.21.2.bb | 260 | busybox_1.21.2.bb |
@@ -290,7 +290,7 @@ You can obtain BitBake several different ways: | |||
290 | are using. The metadata is generally backwards compatible but not | 290 | are using. The metadata is generally backwards compatible but not |
291 | forward compatible. | 291 | forward compatible. |
292 | 292 | ||
293 | Here is an example that clones the BitBake repository: :: | 293 | Here is an example that clones the BitBake repository:: |
294 | 294 | ||
295 | $ git clone git://git.openembedded.org/bitbake | 295 | $ git clone git://git.openembedded.org/bitbake |
296 | 296 | ||
@@ -298,7 +298,7 @@ You can obtain BitBake several different ways: | |||
298 | Git repository into a directory called ``bitbake``. Alternatively, | 298 | Git repository into a directory called ``bitbake``. Alternatively, |
299 | you can designate a directory after the ``git clone`` command if you | 299 | you can designate a directory after the ``git clone`` command if you |
300 | want to call the new directory something other than ``bitbake``. Here | 300 | want to call the new directory something other than ``bitbake``. Here |
301 | is an example that names the directory ``bbdev``: :: | 301 | is an example that names the directory ``bbdev``:: |
302 | 302 | ||
303 | $ git clone git://git.openembedded.org/bitbake bbdev | 303 | $ git clone git://git.openembedded.org/bitbake bbdev |
304 | 304 | ||
@@ -317,7 +317,7 @@ You can obtain BitBake several different ways: | |||
317 | method for getting BitBake. Cloning the repository makes it easier | 317 | method for getting BitBake. Cloning the repository makes it easier |
318 | to update as patches are added to the stable branches. | 318 | to update as patches are added to the stable branches. |
319 | 319 | ||
320 | The following example downloads a snapshot of BitBake version 1.17.0: :: | 320 | The following example downloads a snapshot of BitBake version 1.17.0:: |
321 | 321 | ||
322 | $ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz | 322 | $ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz |
323 | $ tar zxpvf bitbake-1.17.0.tar.gz | 323 | $ tar zxpvf bitbake-1.17.0.tar.gz |
@@ -347,7 +347,7 @@ execution examples. | |||
347 | Usage and syntax | 347 | Usage and syntax |
348 | ---------------- | 348 | ---------------- |
349 | 349 | ||
350 | Following is the usage and syntax for BitBake: :: | 350 | Following is the usage and syntax for BitBake:: |
351 | 351 | ||
352 | $ bitbake -h | 352 | $ bitbake -h |
353 | Usage: bitbake [options] [recipename/target recipe:do_task ...] | 353 | Usage: bitbake [options] [recipename/target recipe:do_task ...] |
@@ -469,11 +469,11 @@ default task, which is "build". BitBake obeys inter-task dependencies | |||
469 | when doing so. | 469 | when doing so. |
470 | 470 | ||
471 | The following command runs the build task, which is the default task, on | 471 | The following command runs the build task, which is the default task, on |
472 | the ``foo_1.0.bb`` recipe file: :: | 472 | the ``foo_1.0.bb`` recipe file:: |
473 | 473 | ||
474 | $ bitbake -b foo_1.0.bb | 474 | $ bitbake -b foo_1.0.bb |
475 | 475 | ||
476 | The following command runs the clean task on the ``foo.bb`` recipe file: :: | 476 | The following command runs the clean task on the ``foo.bb`` recipe file:: |
477 | 477 | ||
478 | $ bitbake -b foo.bb -c clean | 478 | $ bitbake -b foo.bb -c clean |
479 | 479 | ||
@@ -497,13 +497,13 @@ functionality, or when there are multiple versions of a recipe. | |||
497 | The ``bitbake`` command, when not using "--buildfile" or "-b" only | 497 | The ``bitbake`` command, when not using "--buildfile" or "-b" only |
498 | accepts a "PROVIDES". You cannot provide anything else. By default, a | 498 | accepts a "PROVIDES". You cannot provide anything else. By default, a |
499 | recipe file generally "PROVIDES" its "packagename" as shown in the | 499 | recipe file generally "PROVIDES" its "packagename" as shown in the |
500 | following example: :: | 500 | following example:: |
501 | 501 | ||
502 | $ bitbake foo | 502 | $ bitbake foo |
503 | 503 | ||
504 | This next example "PROVIDES" the | 504 | This next example "PROVIDES" the |
505 | package name and also uses the "-c" option to tell BitBake to just | 505 | package name and also uses the "-c" option to tell BitBake to just |
506 | execute the ``do_clean`` task: :: | 506 | execute the ``do_clean`` task:: |
507 | 507 | ||
508 | $ bitbake -c clean foo | 508 | $ bitbake -c clean foo |
509 | 509 | ||
@@ -514,7 +514,7 @@ The BitBake command line supports specifying different tasks for | |||
514 | individual targets when you specify multiple targets. For example, | 514 | individual targets when you specify multiple targets. For example, |
515 | suppose you had two targets (or recipes) ``myfirstrecipe`` and | 515 | suppose you had two targets (or recipes) ``myfirstrecipe`` and |
516 | ``mysecondrecipe`` and you needed BitBake to run ``taskA`` for the first | 516 | ``mysecondrecipe`` and you needed BitBake to run ``taskA`` for the first |
517 | recipe and ``taskB`` for the second recipe: :: | 517 | recipe and ``taskB`` for the second recipe:: |
518 | 518 | ||
519 | $ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB | 519 | $ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB |
520 | 520 | ||
@@ -540,7 +540,7 @@ produce more readable graphs. This way, you can remove from the graph | |||
540 | ``DEPENDS`` from inherited classes such as ``base.bbclass``. | 540 | ``DEPENDS`` from inherited classes such as ``base.bbclass``. |
541 | 541 | ||
542 | Here are two examples that create dependency graphs. The second example | 542 | Here are two examples that create dependency graphs. The second example |
543 | omits depends common in OpenEmbedded from the graph: :: | 543 | omits depends common in OpenEmbedded from the graph:: |
544 | 544 | ||
545 | $ bitbake -g foo | 545 | $ bitbake -g foo |
546 | 546 | ||
@@ -582,17 +582,17 @@ accomplished by setting the | |||
582 | configuration files for ``target1`` and ``target2`` defined in the build | 582 | configuration files for ``target1`` and ``target2`` defined in the build |
583 | directory. The following statement in the ``local.conf`` file both | 583 | directory. The following statement in the ``local.conf`` file both |
584 | enables BitBake to perform multiple configuration builds and specifies | 584 | enables BitBake to perform multiple configuration builds and specifies |
585 | the two extra multiconfigs: :: | 585 | the two extra multiconfigs:: |
586 | 586 | ||
587 | BBMULTICONFIG = "target1 target2" | 587 | BBMULTICONFIG = "target1 target2" |
588 | 588 | ||
589 | Once the target configuration files are in place and BitBake has been | 589 | Once the target configuration files are in place and BitBake has been |
590 | enabled to perform multiple configuration builds, use the following | 590 | enabled to perform multiple configuration builds, use the following |
591 | command form to start the builds: :: | 591 | command form to start the builds:: |
592 | 592 | ||
593 | $ bitbake [mc:multiconfigname:]target [[[mc:multiconfigname:]target] ... ] | 593 | $ bitbake [mc:multiconfigname:]target [[[mc:multiconfigname:]target] ... ] |
594 | 594 | ||
595 | Here is an example for two extra multiconfigs: ``target1`` and ``target2``: :: | 595 | Here is an example for two extra multiconfigs: ``target1`` and ``target2``:: |
596 | 596 | ||
597 | $ bitbake mc::target mc:target1:target mc:target2:target | 597 | $ bitbake mc::target mc:target1:target mc:target2:target |
598 | 598 | ||
@@ -613,12 +613,12 @@ multiconfig. | |||
613 | 613 | ||
614 | To enable dependencies in a multiple configuration build, you must | 614 | To enable dependencies in a multiple configuration build, you must |
615 | declare the dependencies in the recipe using the following statement | 615 | declare the dependencies in the recipe using the following statement |
616 | form: :: | 616 | form:: |
617 | 617 | ||
618 | task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend" | 618 | task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend" |
619 | 619 | ||
620 | To better show how to use this statement, consider an example with two | 620 | To better show how to use this statement, consider an example with two |
621 | multiconfigs: ``target1`` and ``target2``: :: | 621 | multiconfigs: ``target1`` and ``target2``:: |
622 | 622 | ||
623 | image_task[mcdepends] = "mc:target1:target2:image2:rootfs_task" | 623 | image_task[mcdepends] = "mc:target1:target2:image2:rootfs_task" |
624 | 624 | ||
@@ -629,7 +629,7 @@ completion of the rootfs_task used to build out image2, which is | |||
629 | associated with the "target2" multiconfig. | 629 | associated with the "target2" multiconfig. |
630 | 630 | ||
631 | Once you set up this dependency, you can build the "target1" multiconfig | 631 | Once you set up this dependency, you can build the "target1" multiconfig |
632 | using a BitBake command as follows: :: | 632 | using a BitBake command as follows:: |
633 | 633 | ||
634 | $ bitbake mc:target1:image1 | 634 | $ bitbake mc:target1:image1 |
635 | 635 | ||
@@ -639,7 +639,7 @@ the ``rootfs_task`` for the "target2" multiconfig build. | |||
639 | 639 | ||
640 | Having a recipe depend on the root filesystem of another build might not | 640 | Having a recipe depend on the root filesystem of another build might not |
641 | seem that useful. Consider this change to the statement in the image1 | 641 | seem that useful. Consider this change to the statement in the image1 |
642 | recipe: :: | 642 | recipe:: |
643 | 643 | ||
644 | image_task[mcdepends] = "mc:target1:target2:image2:image_task" | 644 | image_task[mcdepends] = "mc:target1:target2:image2:image_task" |
645 | 645 | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst index d4190c26ee..615c9f9ce1 100644 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst +++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst | |||
@@ -26,7 +26,7 @@ assignment. :: | |||
26 | VARIABLE = "value" | 26 | VARIABLE = "value" |
27 | 27 | ||
28 | As expected, if you include leading or | 28 | As expected, if you include leading or |
29 | trailing spaces as part of an assignment, the spaces are retained: :: | 29 | trailing spaces as part of an assignment, the spaces are retained:: |
30 | 30 | ||
31 | VARIABLE = " value" | 31 | VARIABLE = " value" |
32 | VARIABLE = "value " | 32 | VARIABLE = "value " |
@@ -40,7 +40,7 @@ blank space (i.e. these are not the same values). :: | |||
40 | 40 | ||
41 | You can use single quotes instead of double quotes when setting a | 41 | You can use single quotes instead of double quotes when setting a |
42 | variable's value. Doing so allows you to use values that contain the | 42 | variable's value. Doing so allows you to use values that contain the |
43 | double quote character: :: | 43 | double quote character:: |
44 | 44 | ||
45 | VARIABLE = 'I have a " in my value' | 45 | VARIABLE = 'I have a " in my value' |
46 | 46 | ||
@@ -77,7 +77,7 @@ occurs, you can use BitBake to check the actual value of the suspect | |||
77 | variable. You can make these checks for both configuration and recipe | 77 | variable. You can make these checks for both configuration and recipe |
78 | level changes: | 78 | level changes: |
79 | 79 | ||
80 | - For configuration changes, use the following: :: | 80 | - For configuration changes, use the following:: |
81 | 81 | ||
82 | $ bitbake -e | 82 | $ bitbake -e |
83 | 83 | ||
@@ -91,7 +91,7 @@ level changes: | |||
91 | Variables that are exported to the environment are preceded by the | 91 | Variables that are exported to the environment are preceded by the |
92 | string "export" in the command's output. | 92 | string "export" in the command's output. |
93 | 93 | ||
94 | - For recipe changes, use the following: :: | 94 | - For recipe changes, use the following:: |
95 | 95 | ||
96 | $ bitbake recipe -e \| grep VARIABLE=" | 96 | $ bitbake recipe -e \| grep VARIABLE=" |
97 | 97 | ||
@@ -105,7 +105,7 @@ Outside of :ref:`functions <bitbake-user-manual/bitbake-user-manual-metadata:fun | |||
105 | BitBake joins any line ending in | 105 | BitBake joins any line ending in |
106 | a backslash character ("\") with the following line before parsing | 106 | a backslash character ("\") with the following line before parsing |
107 | statements. The most common use for the "\" character is to split | 107 | statements. The most common use for the "\" character is to split |
108 | variable assignments over multiple lines, as in the following example: :: | 108 | variable assignments over multiple lines, as in the following example:: |
109 | 109 | ||
110 | FOO = "bar \ | 110 | FOO = "bar \ |
111 | baz \ | 111 | baz \ |
@@ -116,7 +116,7 @@ character that follow it are removed when joining lines. Thus, no | |||
116 | newline characters end up in the value of ``FOO``. | 116 | newline characters end up in the value of ``FOO``. |
117 | 117 | ||
118 | Consider this additional example where the two assignments both assign | 118 | Consider this additional example where the two assignments both assign |
119 | "barbaz" to ``FOO``: :: | 119 | "barbaz" to ``FOO``:: |
120 | 120 | ||
121 | FOO = "barbaz" | 121 | FOO = "barbaz" |
122 | FOO = "bar\ | 122 | FOO = "bar\ |
@@ -149,7 +149,7 @@ The "=" operator does not immediately expand variable references in the | |||
149 | right-hand side. Instead, expansion is deferred until the variable | 149 | right-hand side. Instead, expansion is deferred until the variable |
150 | assigned to is actually used. The result depends on the current values | 150 | assigned to is actually used. The result depends on the current values |
151 | of the referenced variables. The following example should clarify this | 151 | of the referenced variables. The following example should clarify this |
152 | behavior: :: | 152 | behavior:: |
153 | 153 | ||
154 | A = "${B} baz" | 154 | A = "${B} baz" |
155 | B = "${C} bar" | 155 | B = "${C} bar" |
@@ -177,7 +177,7 @@ Setting a default value (?=) | |||
177 | You can use the "?=" operator to achieve a "softer" assignment for a | 177 | You can use the "?=" operator to achieve a "softer" assignment for a |
178 | variable. This type of assignment allows you to define a variable if it | 178 | variable. This type of assignment allows you to define a variable if it |
179 | is undefined when the statement is parsed, but to leave the value alone | 179 | is undefined when the statement is parsed, but to leave the value alone |
180 | if the variable has a value. Here is an example: :: | 180 | if the variable has a value. Here is an example:: |
181 | 181 | ||
182 | A ?= "aval" | 182 | A ?= "aval" |
183 | 183 | ||
@@ -199,7 +199,7 @@ by using the "??=" operator. This assignment behaves identical to "?=" | |||
199 | except that the assignment is made at the end of the parsing process | 199 | except that the assignment is made at the end of the parsing process |
200 | rather than immediately. Consequently, when multiple "??=" assignments | 200 | rather than immediately. Consequently, when multiple "??=" assignments |
201 | exist, the last one is used. Also, any "=" or "?=" assignment will | 201 | exist, the last one is used. Also, any "=" or "?=" assignment will |
202 | override the value set with "??=". Here is an example: :: | 202 | override the value set with "??=". Here is an example:: |
203 | 203 | ||
204 | A ??= "somevalue" | 204 | A ??= "somevalue" |
205 | A ??= "someothervalue" | 205 | A ??= "someothervalue" |
@@ -215,7 +215,7 @@ Immediate variable expansion (:=) | |||
215 | --------------------------------- | 215 | --------------------------------- |
216 | 216 | ||
217 | The ":=" operator results in a variable's contents being expanded | 217 | The ":=" operator results in a variable's contents being expanded |
218 | immediately, rather than when the variable is actually used: :: | 218 | immediately, rather than when the variable is actually used:: |
219 | 219 | ||
220 | T = "123" | 220 | T = "123" |
221 | A := "test ${T}" | 221 | A := "test ${T}" |
@@ -241,7 +241,7 @@ the "+=" and "=+" operators. These operators insert a space between the | |||
241 | current value and prepended or appended value. | 241 | current value and prepended or appended value. |
242 | 242 | ||
243 | These operators take immediate effect during parsing. Here are some | 243 | These operators take immediate effect during parsing. Here are some |
244 | examples: :: | 244 | examples:: |
245 | 245 | ||
246 | B = "bval" | 246 | B = "bval" |
247 | B += "additionaldata" | 247 | B += "additionaldata" |
@@ -260,7 +260,7 @@ If you want to append or prepend values without an inserted space, use | |||
260 | the ".=" and "=." operators. | 260 | the ".=" and "=." operators. |
261 | 261 | ||
262 | These operators take immediate effect during parsing. Here are some | 262 | These operators take immediate effect during parsing. Here are some |
263 | examples: :: | 263 | examples:: |
264 | 264 | ||
265 | B = "bval" | 265 | B = "bval" |
266 | B .= "additionaldata" | 266 | B .= "additionaldata" |
@@ -278,7 +278,7 @@ style syntax. When you use this syntax, no spaces are inserted. | |||
278 | 278 | ||
279 | These operators differ from the ":=", ".=", "=.", "+=", and "=+" | 279 | These operators differ from the ":=", ".=", "=.", "+=", and "=+" |
280 | operators in that their effects are applied at variable expansion time | 280 | operators in that their effects are applied at variable expansion time |
281 | rather than being immediately applied. Here are some examples: :: | 281 | rather than being immediately applied. Here are some examples:: |
282 | 282 | ||
283 | B = "bval" | 283 | B = "bval" |
284 | B_append = " additional data" | 284 | B_append = " additional data" |
@@ -309,7 +309,7 @@ syntax. Specifying a value for removal causes all occurrences of that | |||
309 | value to be removed from the variable. | 309 | value to be removed from the variable. |
310 | 310 | ||
311 | When you use this syntax, BitBake expects one or more strings. | 311 | When you use this syntax, BitBake expects one or more strings. |
312 | Surrounding spaces and spacing are preserved. Here is an example: :: | 312 | Surrounding spaces and spacing are preserved. Here is an example:: |
313 | 313 | ||
314 | FOO = "123 456 789 123456 123 456 123 456" | 314 | FOO = "123 456 789 123456 123 456 123 456" |
315 | FOO_remove = "123" | 315 | FOO_remove = "123" |
@@ -334,27 +334,27 @@ An advantage of the override style operations "_append", "_prepend", and | |||
334 | "_remove" as compared to the "+=" and "=+" operators is that the | 334 | "_remove" as compared to the "+=" and "=+" operators is that the |
335 | override style operators provide guaranteed operations. For example, | 335 | override style operators provide guaranteed operations. For example, |
336 | consider a class ``foo.bbclass`` that needs to add the value "val" to | 336 | consider a class ``foo.bbclass`` that needs to add the value "val" to |
337 | the variable ``FOO``, and a recipe that uses ``foo.bbclass`` as follows: :: | 337 | the variable ``FOO``, and a recipe that uses ``foo.bbclass`` as follows:: |
338 | 338 | ||
339 | inherit foo | 339 | inherit foo |
340 | FOO = "initial" | 340 | FOO = "initial" |
341 | 341 | ||
342 | If ``foo.bbclass`` uses the "+=" operator, | 342 | If ``foo.bbclass`` uses the "+=" operator, |
343 | as follows, then the final value of ``FOO`` will be "initial", which is | 343 | as follows, then the final value of ``FOO`` will be "initial", which is |
344 | not what is desired: :: | 344 | not what is desired:: |
345 | 345 | ||
346 | FOO += "val" | 346 | FOO += "val" |
347 | 347 | ||
348 | If, on the other hand, ``foo.bbclass`` | 348 | If, on the other hand, ``foo.bbclass`` |
349 | uses the "_append" operator, then the final value of ``FOO`` will be | 349 | uses the "_append" operator, then the final value of ``FOO`` will be |
350 | "initial val", as intended: :: | 350 | "initial val", as intended:: |
351 | 351 | ||
352 | FOO_append = " val" | 352 | FOO_append = " val" |
353 | 353 | ||
354 | .. note:: | 354 | .. note:: |
355 | 355 | ||
356 | It is never necessary to use "+=" together with "_append". The following | 356 | It is never necessary to use "+=" together with "_append". The following |
357 | sequence of assignments appends "barbaz" to FOO: :: | 357 | sequence of assignments appends "barbaz" to FOO:: |
358 | 358 | ||
359 | FOO_append = "bar" | 359 | FOO_append = "bar" |
360 | FOO_append = "baz" | 360 | FOO_append = "baz" |
@@ -381,7 +381,7 @@ standard syntax operations previously mentioned work for variable flags | |||
381 | except for override style syntax (i.e. "_prepend", "_append", and | 381 | except for override style syntax (i.e. "_prepend", "_append", and |
382 | "_remove"). | 382 | "_remove"). |
383 | 383 | ||
384 | Here are some examples showing how to set variable flags: :: | 384 | Here are some examples showing how to set variable flags:: |
385 | 385 | ||
386 | FOO[a] = "abc" | 386 | FOO[a] = "abc" |
387 | FOO[b] = "123" | 387 | FOO[b] = "123" |
@@ -393,7 +393,7 @@ respectively. The ``[a]`` flag becomes "abc 456". | |||
393 | 393 | ||
394 | No need exists to pre-define variable flags. You can simply start using | 394 | No need exists to pre-define variable flags. You can simply start using |
395 | them. One extremely common application is to attach some brief | 395 | them. One extremely common application is to attach some brief |
396 | documentation to a BitBake variable as follows: :: | 396 | documentation to a BitBake variable as follows:: |
397 | 397 | ||
398 | CACHE[doc] = "The directory holding the cache of the metadata." | 398 | CACHE[doc] = "The directory holding the cache of the metadata." |
399 | 399 | ||
@@ -401,7 +401,7 @@ Inline Python Variable Expansion | |||
401 | -------------------------------- | 401 | -------------------------------- |
402 | 402 | ||
403 | You can use inline Python variable expansion to set variables. Here is | 403 | You can use inline Python variable expansion to set variables. Here is |
404 | an example: :: | 404 | an example:: |
405 | 405 | ||
406 | DATE = "${@time.strftime('%Y%m%d',time.gmtime())}" | 406 | DATE = "${@time.strftime('%Y%m%d',time.gmtime())}" |
407 | 407 | ||
@@ -410,7 +410,7 @@ This example results in the ``DATE`` variable being set to the current date. | |||
410 | Probably the most common use of this feature is to extract the value of | 410 | Probably the most common use of this feature is to extract the value of |
411 | variables from BitBake's internal data dictionary, ``d``. The following | 411 | variables from BitBake's internal data dictionary, ``d``. The following |
412 | lines select the values of a package name and its version number, | 412 | lines select the values of a package name and its version number, |
413 | respectively: :: | 413 | respectively:: |
414 | 414 | ||
415 | PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" | 415 | PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" |
416 | PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" | 416 | PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" |
@@ -419,12 +419,12 @@ respectively: :: | |||
419 | 419 | ||
420 | Inline Python expressions work just like variable expansions insofar as the | 420 | Inline Python expressions work just like variable expansions insofar as the |
421 | "=" and ":=" operators are concerned. Given the following assignment, foo() | 421 | "=" and ":=" operators are concerned. Given the following assignment, foo() |
422 | is called each time FOO is expanded: :: | 422 | is called each time FOO is expanded:: |
423 | 423 | ||
424 | FOO = "${@foo()}" | 424 | FOO = "${@foo()}" |
425 | 425 | ||
426 | Contrast this with the following immediate assignment, where foo() is only | 426 | Contrast this with the following immediate assignment, where foo() is only |
427 | called once, while the assignment is parsed: :: | 427 | called once, while the assignment is parsed:: |
428 | 428 | ||
429 | FOO := "${@foo()}" | 429 | FOO := "${@foo()}" |
430 | 430 | ||
@@ -437,7 +437,7 @@ Unsetting variables | |||
437 | 437 | ||
438 | It is possible to completely remove a variable or a variable flag from | 438 | It is possible to completely remove a variable or a variable flag from |
439 | BitBake's internal data dictionary by using the "unset" keyword. Here is | 439 | BitBake's internal data dictionary by using the "unset" keyword. Here is |
440 | an example: :: | 440 | an example:: |
441 | 441 | ||
442 | unset DATE | 442 | unset DATE |
443 | unset do_fetch[noexec] | 443 | unset do_fetch[noexec] |
@@ -452,7 +452,7 @@ When specifying pathnames for use with BitBake, do not use the tilde | |||
452 | cause BitBake to not recognize the path since BitBake does not expand | 452 | cause BitBake to not recognize the path since BitBake does not expand |
453 | this character in the same way a shell would. | 453 | this character in the same way a shell would. |
454 | 454 | ||
455 | Instead, provide a fuller path as the following example illustrates: :: | 455 | Instead, provide a fuller path as the following example illustrates:: |
456 | 456 | ||
457 | BBLAYERS ?= " \ | 457 | BBLAYERS ?= " \ |
458 | /home/scott-lenovo/LayerA \ | 458 | /home/scott-lenovo/LayerA \ |
@@ -463,7 +463,7 @@ Exporting Variables to the Environment | |||
463 | 463 | ||
464 | You can export variables to the environment of running tasks by using | 464 | You can export variables to the environment of running tasks by using |
465 | the ``export`` keyword. For example, in the following example, the | 465 | the ``export`` keyword. For example, in the following example, the |
466 | ``do_foo`` task prints "value from the environment" when run: :: | 466 | ``do_foo`` task prints "value from the environment" when run:: |
467 | 467 | ||
468 | export ENV_VARIABLE | 468 | export ENV_VARIABLE |
469 | ENV_VARIABLE = "value from the environment" | 469 | ENV_VARIABLE = "value from the environment" |
@@ -481,7 +481,7 @@ It does not matter whether ``export ENV_VARIABLE`` appears before or | |||
481 | after assignments to ``ENV_VARIABLE``. | 481 | after assignments to ``ENV_VARIABLE``. |
482 | 482 | ||
483 | It is also possible to combine ``export`` with setting a value for the | 483 | It is also possible to combine ``export`` with setting a value for the |
484 | variable. Here is an example: :: | 484 | variable. Here is an example:: |
485 | 485 | ||
486 | export ENV_VARIABLE = "variable-value" | 486 | export ENV_VARIABLE = "variable-value" |
487 | 487 | ||
@@ -518,7 +518,7 @@ variable. | |||
518 | to satisfy conditions. Thus, if you have a variable that is | 518 | to satisfy conditions. Thus, if you have a variable that is |
519 | conditional on "arm", and "arm" is in ``OVERRIDES``, then the | 519 | conditional on "arm", and "arm" is in ``OVERRIDES``, then the |
520 | "arm"-specific version of the variable is used rather than the | 520 | "arm"-specific version of the variable is used rather than the |
521 | non-conditional version. Here is an example: :: | 521 | non-conditional version. Here is an example:: |
522 | 522 | ||
523 | OVERRIDES = "architecture:os:machine" | 523 | OVERRIDES = "architecture:os:machine" |
524 | TEST = "default" | 524 | TEST = "default" |
@@ -535,7 +535,7 @@ variable. | |||
535 | an OpenEmbedded metadata-based Linux kernel recipe file. The | 535 | an OpenEmbedded metadata-based Linux kernel recipe file. The |
536 | following lines from the recipe file first set the kernel branch | 536 | following lines from the recipe file first set the kernel branch |
537 | variable ``KBRANCH`` to a default value, then conditionally override | 537 | variable ``KBRANCH`` to a default value, then conditionally override |
538 | that value based on the architecture of the build: :: | 538 | that value based on the architecture of the build:: |
539 | 539 | ||
540 | KBRANCH = "standard/base" | 540 | KBRANCH = "standard/base" |
541 | KBRANCH_qemuarm = "standard/arm-versatile-926ejs" | 541 | KBRANCH_qemuarm = "standard/arm-versatile-926ejs" |
@@ -547,7 +547,7 @@ variable. | |||
547 | 547 | ||
548 | - *Appending and Prepending:* BitBake also supports append and prepend | 548 | - *Appending and Prepending:* BitBake also supports append and prepend |
549 | operations to variable values based on whether a specific item is | 549 | operations to variable values based on whether a specific item is |
550 | listed in ``OVERRIDES``. Here is an example: :: | 550 | listed in ``OVERRIDES``. Here is an example:: |
551 | 551 | ||
552 | DEPENDS = "glibc ncurses" | 552 | DEPENDS = "glibc ncurses" |
553 | OVERRIDES = "machine:local" | 553 | OVERRIDES = "machine:local" |
@@ -557,14 +557,14 @@ variable. | |||
557 | 557 | ||
558 | Again, using an OpenEmbedded metadata-based kernel recipe file as an | 558 | Again, using an OpenEmbedded metadata-based kernel recipe file as an |
559 | example, the following lines will conditionally append to the | 559 | example, the following lines will conditionally append to the |
560 | ``KERNEL_FEATURES`` variable based on the architecture: :: | 560 | ``KERNEL_FEATURES`` variable based on the architecture:: |
561 | 561 | ||
562 | KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" | 562 | KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" |
563 | KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" | 563 | KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" |
564 | KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" | 564 | KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc" |
565 | 565 | ||
566 | - *Setting a Variable for a Single Task:* BitBake supports setting a | 566 | - *Setting a Variable for a Single Task:* BitBake supports setting a |
567 | variable just for the duration of a single task. Here is an example: :: | 567 | variable just for the duration of a single task. Here is an example:: |
568 | 568 | ||
569 | FOO_task-configure = "val 1" | 569 | FOO_task-configure = "val 1" |
570 | FOO_task-compile = "val 2" | 570 | FOO_task-compile = "val 2" |
@@ -580,7 +580,7 @@ variable. | |||
580 | ``do_compile`` task. | 580 | ``do_compile`` task. |
581 | 581 | ||
582 | You can also use this syntax with other combinations (e.g. | 582 | You can also use this syntax with other combinations (e.g. |
583 | "``_prepend``") as shown in the following example: :: | 583 | "``_prepend``") as shown in the following example:: |
584 | 584 | ||
585 | EXTRA_OEMAKE_prepend_task-compile = "${PARALLEL_MAKE} " | 585 | EXTRA_OEMAKE_prepend_task-compile = "${PARALLEL_MAKE} " |
586 | 586 | ||
@@ -588,7 +588,7 @@ Key Expansion | |||
588 | ------------- | 588 | ------------- |
589 | 589 | ||
590 | Key expansion happens when the BitBake datastore is finalized. To better | 590 | Key expansion happens when the BitBake datastore is finalized. To better |
591 | understand this, consider the following example: :: | 591 | understand this, consider the following example:: |
592 | 592 | ||
593 | A${B} = "X" | 593 | A${B} = "X" |
594 | B = "2" | 594 | B = "2" |
@@ -614,7 +614,7 @@ There is often confusion concerning the order in which overrides and | |||
614 | various "append" operators take effect. Recall that an append or prepend | 614 | various "append" operators take effect. Recall that an append or prepend |
615 | operation using "_append" and "_prepend" does not result in an immediate | 615 | operation using "_append" and "_prepend" does not result in an immediate |
616 | assignment as would "+=", ".=", "=+", or "=.". Consider the following | 616 | assignment as would "+=", ".=", "=+", or "=.". Consider the following |
617 | example: :: | 617 | example:: |
618 | 618 | ||
619 | OVERRIDES = "foo" | 619 | OVERRIDES = "foo" |
620 | A = "Z" | 620 | A = "Z" |
@@ -631,7 +631,7 @@ Applying overrides, however, changes things. Since "foo" is listed in | |||
631 | version, which is equal to "X". So effectively, ``A_foo`` replaces | 631 | version, which is equal to "X". So effectively, ``A_foo`` replaces |
632 | ``A``. | 632 | ``A``. |
633 | 633 | ||
634 | This next example changes the order of the override and the append: :: | 634 | This next example changes the order of the override and the append:: |
635 | 635 | ||
636 | OVERRIDES = "foo" | 636 | OVERRIDES = "foo" |
637 | A = "Z" | 637 | A = "Z" |
@@ -644,7 +644,7 @@ appended with "X". Consequently, ``A`` becomes "ZX". Notice that spaces | |||
644 | are not appended. | 644 | are not appended. |
645 | 645 | ||
646 | This next example has the order of the appends and overrides reversed | 646 | This next example has the order of the appends and overrides reversed |
647 | back as in the first example: :: | 647 | back as in the first example:: |
648 | 648 | ||
649 | OVERRIDES = "foo" | 649 | OVERRIDES = "foo" |
650 | A = "Y" | 650 | A = "Y" |
@@ -658,7 +658,7 @@ leaving the variable set to "ZX". Finally, applying the override for | |||
658 | "foo" results in the conditional variable ``A`` becoming "ZX" (i.e. | 658 | "foo" results in the conditional variable ``A`` becoming "ZX" (i.e. |
659 | ``A`` is replaced with ``A_foo``). | 659 | ``A`` is replaced with ``A_foo``). |
660 | 660 | ||
661 | This final example mixes in some varying operators: :: | 661 | This final example mixes in some varying operators:: |
662 | 662 | ||
663 | A = "1" | 663 | A = "1" |
664 | A_append = "2" | 664 | A_append = "2" |
@@ -720,7 +720,7 @@ file and then have your recipe inherit that class file. | |||
720 | 720 | ||
721 | As an example, your recipes could use the following directive to inherit | 721 | As an example, your recipes could use the following directive to inherit |
722 | an ``autotools.bbclass`` file. The class file would contain common | 722 | an ``autotools.bbclass`` file. The class file would contain common |
723 | functionality for using Autotools that could be shared across recipes: :: | 723 | functionality for using Autotools that could be shared across recipes:: |
724 | 724 | ||
725 | inherit autotools | 725 | inherit autotools |
726 | 726 | ||
@@ -734,7 +734,7 @@ In this case, BitBake would search for the directory | |||
734 | 734 | ||
735 | If you want to use the directive to inherit multiple classes, separate | 735 | If you want to use the directive to inherit multiple classes, separate |
736 | them with spaces. The following example shows how to inherit both the | 736 | them with spaces. The following example shows how to inherit both the |
737 | ``buildhistory`` and ``rm_work`` classes: :: | 737 | ``buildhistory`` and ``rm_work`` classes:: |
738 | 738 | ||
739 | inherit buildhistory rm_work | 739 | inherit buildhistory rm_work |
740 | 740 | ||
@@ -742,19 +742,19 @@ An advantage with the inherit directive as compared to both the | |||
742 | :ref:`include <bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>` and :ref:`require <bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>` | 742 | :ref:`include <bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>` and :ref:`require <bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>` |
743 | directives is that you can inherit class files conditionally. You can | 743 | directives is that you can inherit class files conditionally. You can |
744 | accomplish this by using a variable expression after the ``inherit`` | 744 | accomplish this by using a variable expression after the ``inherit`` |
745 | statement. Here is an example: :: | 745 | statement. Here is an example:: |
746 | 746 | ||
747 | inherit ${VARNAME} | 747 | inherit ${VARNAME} |
748 | 748 | ||
749 | If ``VARNAME`` is | 749 | If ``VARNAME`` is |
750 | going to be set, it needs to be set before the ``inherit`` statement is | 750 | going to be set, it needs to be set before the ``inherit`` statement is |
751 | parsed. One way to achieve a conditional inherit in this case is to use | 751 | parsed. One way to achieve a conditional inherit in this case is to use |
752 | overrides: :: | 752 | overrides:: |
753 | 753 | ||
754 | VARIABLE = "" | 754 | VARIABLE = "" |
755 | VARIABLE_someoverride = "myclass" | 755 | VARIABLE_someoverride = "myclass" |
756 | 756 | ||
757 | Another method is by using anonymous Python. Here is an example: :: | 757 | Another method is by using anonymous Python. Here is an example:: |
758 | 758 | ||
759 | python () { | 759 | python () { |
760 | if condition == value: | 760 | if condition == value: |
@@ -764,7 +764,7 @@ Another method is by using anonymous Python. Here is an example: :: | |||
764 | } | 764 | } |
765 | 765 | ||
766 | Alternatively, you could use an in-line Python expression in the | 766 | Alternatively, you could use an in-line Python expression in the |
767 | following form: :: | 767 | following form:: |
768 | 768 | ||
769 | inherit ${@'classname' if condition else ''} | 769 | inherit ${@'classname' if condition else ''} |
770 | inherit ${@functionname(params)} | 770 | inherit ${@functionname(params)} |
@@ -790,7 +790,7 @@ encapsulated functionality or configuration that does not suit a | |||
790 | ``.bbclass`` file. | 790 | ``.bbclass`` file. |
791 | 791 | ||
792 | As an example, suppose you needed a recipe to include some self-test | 792 | As an example, suppose you needed a recipe to include some self-test |
793 | definitions: :: | 793 | definitions:: |
794 | 794 | ||
795 | include test_defs.inc | 795 | include test_defs.inc |
796 | 796 | ||
@@ -831,7 +831,7 @@ include file named ``foo.inc`` that contains the common definitions | |||
831 | needed to build "foo". You need to be sure ``foo.inc`` is located in the | 831 | needed to build "foo". You need to be sure ``foo.inc`` is located in the |
832 | same directory as your two recipe files as well. Once these conditions | 832 | same directory as your two recipe files as well. Once these conditions |
833 | are set up, you can share the functionality using a ``require`` | 833 | are set up, you can share the functionality using a ``require`` |
834 | directive from within each recipe: :: | 834 | directive from within each recipe:: |
835 | 835 | ||
836 | require foo.inc | 836 | require foo.inc |
837 | 837 | ||
@@ -844,7 +844,7 @@ class. BitBake only supports this directive when used within a | |||
844 | configuration file. | 844 | configuration file. |
845 | 845 | ||
846 | As an example, suppose you needed to inherit a class file called | 846 | As an example, suppose you needed to inherit a class file called |
847 | ``abc.bbclass`` from a configuration file as follows: :: | 847 | ``abc.bbclass`` from a configuration file as follows:: |
848 | 848 | ||
849 | INHERIT += "abc" | 849 | INHERIT += "abc" |
850 | 850 | ||
@@ -862,7 +862,7 @@ subdirectory in one of the directories specified in ``BBPATH``. | |||
862 | If you want to use the directive to inherit multiple classes, you can | 862 | If you want to use the directive to inherit multiple classes, you can |
863 | provide them on the same line in the ``local.conf`` file. Use spaces to | 863 | provide them on the same line in the ``local.conf`` file. Use spaces to |
864 | separate the classes. The following example shows how to inherit both | 864 | separate the classes. The following example shows how to inherit both |
865 | the ``autotools`` and ``pkgconfig`` classes: :: | 865 | the ``autotools`` and ``pkgconfig`` classes:: |
866 | 866 | ||
867 | INHERIT += "autotools pkgconfig" | 867 | INHERIT += "autotools pkgconfig" |
868 | 868 | ||
@@ -895,7 +895,7 @@ Shell Functions | |||
895 | 895 | ||
896 | Functions written in shell script and executed either directly as | 896 | Functions written in shell script and executed either directly as |
897 | functions, tasks, or both. They can also be called by other shell | 897 | functions, tasks, or both. They can also be called by other shell |
898 | functions. Here is an example shell function definition: :: | 898 | functions. Here is an example shell function definition:: |
899 | 899 | ||
900 | some_function () { | 900 | some_function () { |
901 | echo "Hello World" | 901 | echo "Hello World" |
@@ -912,7 +912,7 @@ can also be applied to shell functions. Most commonly, this application | |||
912 | would be used in a ``.bbappend`` file to modify functions in the main | 912 | would be used in a ``.bbappend`` file to modify functions in the main |
913 | recipe. It can also be used to modify functions inherited from classes. | 913 | recipe. It can also be used to modify functions inherited from classes. |
914 | 914 | ||
915 | As an example, consider the following: :: | 915 | As an example, consider the following:: |
916 | 916 | ||
917 | do_foo() { | 917 | do_foo() { |
918 | bbplain first | 918 | bbplain first |
@@ -931,7 +931,7 @@ As an example, consider the following: :: | |||
931 | bbplain fourth | 931 | bbplain fourth |
932 | } | 932 | } |
933 | 933 | ||
934 | Running ``do_foo`` prints the following: :: | 934 | Running ``do_foo`` prints the following:: |
935 | 935 | ||
936 | recipename do_foo: first | 936 | recipename do_foo: first |
937 | recipename do_foo: second | 937 | recipename do_foo: second |
@@ -952,7 +952,7 @@ BitBake-Style Python Functions | |||
952 | These functions are written in Python and executed by BitBake or other | 952 | These functions are written in Python and executed by BitBake or other |
953 | Python functions using ``bb.build.exec_func()``. | 953 | Python functions using ``bb.build.exec_func()``. |
954 | 954 | ||
955 | An example BitBake function is: :: | 955 | An example BitBake function is:: |
956 | 956 | ||
957 | python some_python_function () { | 957 | python some_python_function () { |
958 | d.setVar("TEXT", "Hello World") | 958 | d.setVar("TEXT", "Hello World") |
@@ -975,7 +975,7 @@ import these modules. Also in these types of functions, the datastore | |||
975 | Similar to shell functions, you can also apply overrides and | 975 | Similar to shell functions, you can also apply overrides and |
976 | override-style operators to BitBake-style Python functions. | 976 | override-style operators to BitBake-style Python functions. |
977 | 977 | ||
978 | As an example, consider the following: :: | 978 | As an example, consider the following:: |
979 | 979 | ||
980 | python do_foo_prepend() { | 980 | python do_foo_prepend() { |
981 | bb.plain("first") | 981 | bb.plain("first") |
@@ -989,7 +989,7 @@ As an example, consider the following: :: | |||
989 | bb.plain("third") | 989 | bb.plain("third") |
990 | } | 990 | } |
991 | 991 | ||
992 | Running ``do_foo`` prints the following: :: | 992 | Running ``do_foo`` prints the following:: |
993 | 993 | ||
994 | recipename do_foo: first | 994 | recipename do_foo: first |
995 | recipename do_foo: second | 995 | recipename do_foo: second |
@@ -1004,7 +1004,7 @@ Python Functions | |||
1004 | These functions are written in Python and are executed by other Python | 1004 | These functions are written in Python and are executed by other Python |
1005 | code. Examples of Python functions are utility functions that you intend | 1005 | code. Examples of Python functions are utility functions that you intend |
1006 | to call from in-line Python or from within other Python functions. Here | 1006 | to call from in-line Python or from within other Python functions. Here |
1007 | is an example: :: | 1007 | is an example:: |
1008 | 1008 | ||
1009 | def get_depends(d): | 1009 | def get_depends(d): |
1010 | if d.getVar('SOMECONDITION'): | 1010 | if d.getVar('SOMECONDITION'): |
@@ -1056,7 +1056,7 @@ functions and regular Python functions defined with "def": | |||
1056 | - Regular Python functions are called with the usual Python syntax. | 1056 | - Regular Python functions are called with the usual Python syntax. |
1057 | BitBake-style Python functions are usually tasks and are called | 1057 | BitBake-style Python functions are usually tasks and are called |
1058 | directly by BitBake, but can also be called manually from Python code | 1058 | directly by BitBake, but can also be called manually from Python code |
1059 | by using the ``bb.build.exec_func()`` function. Here is an example: :: | 1059 | by using the ``bb.build.exec_func()`` function. Here is an example:: |
1060 | 1060 | ||
1061 | bb.build.exec_func("my_bitbake_style_function", d) | 1061 | bb.build.exec_func("my_bitbake_style_function", d) |
1062 | 1062 | ||
@@ -1094,7 +1094,7 @@ Sometimes it is useful to set variables or perform other operations | |||
1094 | programmatically during parsing. To do this, you can define special | 1094 | programmatically during parsing. To do this, you can define special |
1095 | Python functions, called anonymous Python functions, that run at the end | 1095 | Python functions, called anonymous Python functions, that run at the end |
1096 | of parsing. For example, the following conditionally sets a variable | 1096 | of parsing. For example, the following conditionally sets a variable |
1097 | based on the value of another variable: :: | 1097 | based on the value of another variable:: |
1098 | 1098 | ||
1099 | python () { | 1099 | python () { |
1100 | if d.getVar('SOMEVAR') == 'value': | 1100 | if d.getVar('SOMEVAR') == 'value': |
@@ -1107,7 +1107,7 @@ the name "__anonymous", rather than no name. | |||
1107 | Anonymous Python functions always run at the end of parsing, regardless | 1107 | Anonymous Python functions always run at the end of parsing, regardless |
1108 | of where they are defined. If a recipe contains many anonymous | 1108 | of where they are defined. If a recipe contains many anonymous |
1109 | functions, they run in the same order as they are defined within the | 1109 | functions, they run in the same order as they are defined within the |
1110 | recipe. As an example, consider the following snippet: :: | 1110 | recipe. As an example, consider the following snippet:: |
1111 | 1111 | ||
1112 | python () { | 1112 | python () { |
1113 | d.setVar('FOO', 'foo 2') | 1113 | d.setVar('FOO', 'foo 2') |
@@ -1122,7 +1122,7 @@ recipe. As an example, consider the following snippet: :: | |||
1122 | BAR = "bar 1" | 1122 | BAR = "bar 1" |
1123 | 1123 | ||
1124 | The previous example is conceptually | 1124 | The previous example is conceptually |
1125 | equivalent to the following snippet: :: | 1125 | equivalent to the following snippet:: |
1126 | 1126 | ||
1127 | FOO = "foo 1" | 1127 | FOO = "foo 1" |
1128 | BAR = "bar 1" | 1128 | BAR = "bar 1" |
@@ -1136,7 +1136,7 @@ available to tasks, which always run after parsing. | |||
1136 | 1136 | ||
1137 | Overrides and override-style operators such as "``_append``" are applied | 1137 | Overrides and override-style operators such as "``_append``" are applied |
1138 | before anonymous functions run. In the following example, ``FOO`` ends | 1138 | before anonymous functions run. In the following example, ``FOO`` ends |
1139 | up with the value "foo from anonymous": :: | 1139 | up with the value "foo from anonymous":: |
1140 | 1140 | ||
1141 | FOO = "foo" | 1141 | FOO = "foo" |
1142 | FOO_append = " from outside" | 1142 | FOO_append = " from outside" |
@@ -1173,24 +1173,24 @@ version of the function. | |||
1173 | 1173 | ||
1174 | To make use of this technique, you need the following things in place: | 1174 | To make use of this technique, you need the following things in place: |
1175 | 1175 | ||
1176 | - The class needs to define the function as follows: :: | 1176 | - The class needs to define the function as follows:: |
1177 | 1177 | ||
1178 | classname_functionname | 1178 | classname_functionname |
1179 | 1179 | ||
1180 | For example, if you have a class file | 1180 | For example, if you have a class file |
1181 | ``bar.bbclass`` and a function named ``do_foo``, the class must | 1181 | ``bar.bbclass`` and a function named ``do_foo``, the class must |
1182 | define the function as follows: :: | 1182 | define the function as follows:: |
1183 | 1183 | ||
1184 | bar_do_foo | 1184 | bar_do_foo |
1185 | 1185 | ||
1186 | - The class needs to contain the ``EXPORT_FUNCTIONS`` statement as | 1186 | - The class needs to contain the ``EXPORT_FUNCTIONS`` statement as |
1187 | follows: :: | 1187 | follows:: |
1188 | 1188 | ||
1189 | EXPORT_FUNCTIONS functionname | 1189 | EXPORT_FUNCTIONS functionname |
1190 | 1190 | ||
1191 | For example, continuing with | 1191 | For example, continuing with |
1192 | the same example, the statement in the ``bar.bbclass`` would be as | 1192 | the same example, the statement in the ``bar.bbclass`` would be as |
1193 | follows: :: | 1193 | follows:: |
1194 | 1194 | ||
1195 | EXPORT_FUNCTIONS do_foo | 1195 | EXPORT_FUNCTIONS do_foo |
1196 | 1196 | ||
@@ -1199,7 +1199,7 @@ To make use of this technique, you need the following things in place: | |||
1199 | class version of the function, it should call ``bar_do_foo``. | 1199 | class version of the function, it should call ``bar_do_foo``. |
1200 | Assuming ``do_foo`` was a shell function and ``EXPORT_FUNCTIONS`` was | 1200 | Assuming ``do_foo`` was a shell function and ``EXPORT_FUNCTIONS`` was |
1201 | used as above, the recipe's function could conditionally call the | 1201 | used as above, the recipe's function could conditionally call the |
1202 | class version of the function as follows: :: | 1202 | class version of the function as follows:: |
1203 | 1203 | ||
1204 | do_foo() { | 1204 | do_foo() { |
1205 | if [ somecondition ] ; then | 1205 | if [ somecondition ] ; then |
@@ -1233,7 +1233,7 @@ Tasks are either :ref:`shell functions <bitbake-user-manual/bitbake-user-manual- | |||
1233 | that have been promoted to tasks by using the ``addtask`` command. The | 1233 | that have been promoted to tasks by using the ``addtask`` command. The |
1234 | ``addtask`` command can also optionally describe dependencies between | 1234 | ``addtask`` command can also optionally describe dependencies between |
1235 | the task and other tasks. Here is an example that shows how to define a | 1235 | the task and other tasks. Here is an example that shows how to define a |
1236 | task and declare some dependencies: :: | 1236 | task and declare some dependencies:: |
1237 | 1237 | ||
1238 | python do_printdate () { | 1238 | python do_printdate () { |
1239 | import time | 1239 | import time |
@@ -1264,12 +1264,12 @@ Additionally, the ``do_printdate`` task becomes dependent upon the | |||
1264 | rerun for experimentation purposes, you can make BitBake always | 1264 | rerun for experimentation purposes, you can make BitBake always |
1265 | consider the task "out-of-date" by using the | 1265 | consider the task "out-of-date" by using the |
1266 | :ref:`[nostamp] <bitbake-user-manual/bitbake-user-manual-metadata:Variable Flags>` | 1266 | :ref:`[nostamp] <bitbake-user-manual/bitbake-user-manual-metadata:Variable Flags>` |
1267 | variable flag, as follows: :: | 1267 | variable flag, as follows:: |
1268 | 1268 | ||
1269 | do_printdate[nostamp] = "1" | 1269 | do_printdate[nostamp] = "1" |
1270 | 1270 | ||
1271 | You can also explicitly run the task and provide the | 1271 | You can also explicitly run the task and provide the |
1272 | -f option as follows: :: | 1272 | -f option as follows:: |
1273 | 1273 | ||
1274 | $ bitbake recipe -c printdate -f | 1274 | $ bitbake recipe -c printdate -f |
1275 | 1275 | ||
@@ -1278,7 +1278,7 @@ Additionally, the ``do_printdate`` task becomes dependent upon the | |||
1278 | name. | 1278 | name. |
1279 | 1279 | ||
1280 | You might wonder about the practical effects of using ``addtask`` | 1280 | You might wonder about the practical effects of using ``addtask`` |
1281 | without specifying any dependencies as is done in the following example: :: | 1281 | without specifying any dependencies as is done in the following example:: |
1282 | 1282 | ||
1283 | addtask printdate | 1283 | addtask printdate |
1284 | 1284 | ||
@@ -1286,7 +1286,7 @@ In this example, assuming dependencies have not been | |||
1286 | added through some other means, the only way to run the task is by | 1286 | added through some other means, the only way to run the task is by |
1287 | explicitly selecting it with ``bitbake`` recipe ``-c printdate``. You | 1287 | explicitly selecting it with ``bitbake`` recipe ``-c printdate``. You |
1288 | can use the ``do_listtasks`` task to list all tasks defined in a recipe | 1288 | can use the ``do_listtasks`` task to list all tasks defined in a recipe |
1289 | as shown in the following example: :: | 1289 | as shown in the following example:: |
1290 | 1290 | ||
1291 | $ bitbake recipe -c listtasks | 1291 | $ bitbake recipe -c listtasks |
1292 | 1292 | ||
@@ -1312,7 +1312,7 @@ Deleting a Task | |||
1312 | 1312 | ||
1313 | As well as being able to add tasks, you can delete them. Simply use the | 1313 | As well as being able to add tasks, you can delete them. Simply use the |
1314 | ``deltask`` command to delete a task. For example, to delete the example | 1314 | ``deltask`` command to delete a task. For example, to delete the example |
1315 | task used in the previous sections, you would use: :: | 1315 | task used in the previous sections, you would use:: |
1316 | 1316 | ||
1317 | deltask printdate | 1317 | deltask printdate |
1318 | 1318 | ||
@@ -1328,7 +1328,7 @@ to run before ``do_a``. | |||
1328 | 1328 | ||
1329 | If you want dependencies such as these to remain intact, use the | 1329 | If you want dependencies such as these to remain intact, use the |
1330 | ``[noexec]`` varflag to disable the task instead of using the | 1330 | ``[noexec]`` varflag to disable the task instead of using the |
1331 | ``deltask`` command to delete it: :: | 1331 | ``deltask`` command to delete it:: |
1332 | 1332 | ||
1333 | do_b[noexec] = "1" | 1333 | do_b[noexec] = "1" |
1334 | 1334 | ||
@@ -1356,7 +1356,7 @@ environment, you must take these two steps: | |||
1356 | example, assume you want to prevent the build system from accessing | 1356 | example, assume you want to prevent the build system from accessing |
1357 | your ``$HOME/.ccache`` directory. The following command "whitelists" | 1357 | your ``$HOME/.ccache`` directory. The following command "whitelists" |
1358 | the environment variable ``CCACHE_DIR`` causing BitBake to allow that | 1358 | the environment variable ``CCACHE_DIR`` causing BitBake to allow that |
1359 | variable into the datastore: :: | 1359 | variable into the datastore:: |
1360 | 1360 | ||
1361 | export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR" | 1361 | export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR" |
1362 | 1362 | ||
@@ -1366,7 +1366,7 @@ environment, you must take these two steps: | |||
1366 | available in the datastore. To export it to the task environment of | 1366 | available in the datastore. To export it to the task environment of |
1367 | every running task, use a command similar to the following in your | 1367 | every running task, use a command similar to the following in your |
1368 | local configuration file ``local.conf`` or your distribution | 1368 | local configuration file ``local.conf`` or your distribution |
1369 | configuration file: :: | 1369 | configuration file:: |
1370 | 1370 | ||
1371 | export CCACHE_DIR | 1371 | export CCACHE_DIR |
1372 | 1372 | ||
@@ -1385,7 +1385,7 @@ environment into a special variable named :term:`BB_ORIGENV`. | |||
1385 | The ``BB_ORIGENV`` variable returns a datastore object that can be | 1385 | The ``BB_ORIGENV`` variable returns a datastore object that can be |
1386 | queried using the standard datastore operators such as | 1386 | queried using the standard datastore operators such as |
1387 | ``getVar(, False)``. The datastore object is useful, for example, to | 1387 | ``getVar(, False)``. The datastore object is useful, for example, to |
1388 | find the original ``DISPLAY`` variable. Here is an example: :: | 1388 | find the original ``DISPLAY`` variable. Here is an example:: |
1389 | 1389 | ||
1390 | origenv = d.getVar("BB_ORIGENV", False) | 1390 | origenv = d.getVar("BB_ORIGENV", False) |
1391 | bar = origenv.getVar("BAR", False) | 1391 | bar = origenv.getVar("BAR", False) |
@@ -1398,7 +1398,7 @@ Variable Flags | |||
1398 | 1398 | ||
1399 | Variable flags (varflags) help control a task's functionality and | 1399 | Variable flags (varflags) help control a task's functionality and |
1400 | dependencies. BitBake reads and writes varflags to the datastore using | 1400 | dependencies. BitBake reads and writes varflags to the datastore using |
1401 | the following command forms: :: | 1401 | the following command forms:: |
1402 | 1402 | ||
1403 | variable = d.getVarFlags("variable") | 1403 | variable = d.getVarFlags("variable") |
1404 | self.d.setVarFlags("FOO", {"func": True}) | 1404 | self.d.setVarFlags("FOO", {"func": True}) |
@@ -1537,7 +1537,7 @@ intent is to make it easy to do things like email notification on build | |||
1537 | failures. | 1537 | failures. |
1538 | 1538 | ||
1539 | Following is an example event handler that prints the name of the event | 1539 | Following is an example event handler that prints the name of the event |
1540 | and the content of the ``FILE`` variable: :: | 1540 | and the content of the ``FILE`` variable:: |
1541 | 1541 | ||
1542 | addhandler myclass_eventhandler | 1542 | addhandler myclass_eventhandler |
1543 | python myclass_eventhandler() { | 1543 | python myclass_eventhandler() { |
@@ -1676,7 +1676,7 @@ incarnations are buildable. These features are enabled through the | |||
1676 | also specify conditional metadata (using the | 1676 | also specify conditional metadata (using the |
1677 | :term:`OVERRIDES` mechanism) for a single | 1677 | :term:`OVERRIDES` mechanism) for a single |
1678 | version, or an optionally named range of versions. Here is an | 1678 | version, or an optionally named range of versions. Here is an |
1679 | example: :: | 1679 | example:: |
1680 | 1680 | ||
1681 | BBVERSIONS = "1.0 2.0 git" | 1681 | BBVERSIONS = "1.0 2.0 git" |
1682 | SRC_URI_git = "git://someurl/somepath.git" | 1682 | SRC_URI_git = "git://someurl/somepath.git" |
@@ -1719,7 +1719,7 @@ Dependencies Internal to the ``.bb`` File | |||
1719 | BitBake uses the ``addtask`` directive to manage dependencies that are | 1719 | BitBake uses the ``addtask`` directive to manage dependencies that are |
1720 | internal to a given recipe file. You can use the ``addtask`` directive | 1720 | internal to a given recipe file. You can use the ``addtask`` directive |
1721 | to indicate when a task is dependent on other tasks or when other tasks | 1721 | to indicate when a task is dependent on other tasks or when other tasks |
1722 | depend on that recipe. Here is an example: :: | 1722 | depend on that recipe. Here is an example:: |
1723 | 1723 | ||
1724 | addtask printdate after do_fetch before do_build | 1724 | addtask printdate after do_fetch before do_build |
1725 | 1725 | ||
@@ -1743,7 +1743,7 @@ task depends on the completion of the ``do_printdate`` task. | |||
1743 | 1743 | ||
1744 | - The directive ``addtask mytask after do_configure`` by itself | 1744 | - The directive ``addtask mytask after do_configure`` by itself |
1745 | never causes ``do_mytask`` to run. ``do_mytask`` can still be run | 1745 | never causes ``do_mytask`` to run. ``do_mytask`` can still be run |
1746 | manually as follows: :: | 1746 | manually as follows:: |
1747 | 1747 | ||
1748 | $ bitbake recipe -c mytask | 1748 | $ bitbake recipe -c mytask |
1749 | 1749 | ||
@@ -1757,7 +1757,7 @@ Build Dependencies | |||
1757 | BitBake uses the :term:`DEPENDS` variable to manage | 1757 | BitBake uses the :term:`DEPENDS` variable to manage |
1758 | build time dependencies. The ``[deptask]`` varflag for tasks signifies | 1758 | build time dependencies. The ``[deptask]`` varflag for tasks signifies |
1759 | the task of each item listed in ``DEPENDS`` that must complete before | 1759 | the task of each item listed in ``DEPENDS`` that must complete before |
1760 | that task can be executed. Here is an example: :: | 1760 | that task can be executed. Here is an example:: |
1761 | 1761 | ||
1762 | do_configure[deptask] = "do_populate_sysroot" | 1762 | do_configure[deptask] = "do_populate_sysroot" |
1763 | 1763 | ||
@@ -1799,7 +1799,7 @@ dependencies are discovered and added. | |||
1799 | 1799 | ||
1800 | The ``[recrdeptask]`` flag is most commonly used in high-level recipes | 1800 | The ``[recrdeptask]`` flag is most commonly used in high-level recipes |
1801 | that need to wait for some task to finish "globally". For example, | 1801 | that need to wait for some task to finish "globally". For example, |
1802 | ``image.bbclass`` has the following: :: | 1802 | ``image.bbclass`` has the following:: |
1803 | 1803 | ||
1804 | do_rootfs[recrdeptask] += "do_packagedata" | 1804 | do_rootfs[recrdeptask] += "do_packagedata" |
1805 | 1805 | ||
@@ -1808,7 +1808,7 @@ the current recipe and all recipes reachable (by way of dependencies) | |||
1808 | from the image recipe must run before the ``do_rootfs`` task can run. | 1808 | from the image recipe must run before the ``do_rootfs`` task can run. |
1809 | 1809 | ||
1810 | BitBake allows a task to recursively depend on itself by | 1810 | BitBake allows a task to recursively depend on itself by |
1811 | referencing itself in the task list: :: | 1811 | referencing itself in the task list:: |
1812 | 1812 | ||
1813 | do_a[recrdeptask] = "do_a do_b" | 1813 | do_a[recrdeptask] = "do_a do_b" |
1814 | 1814 | ||
@@ -1825,7 +1825,7 @@ Inter-Task Dependencies | |||
1825 | BitBake uses the ``[depends]`` flag in a more generic form to manage | 1825 | BitBake uses the ``[depends]`` flag in a more generic form to manage |
1826 | inter-task dependencies. This more generic form allows for | 1826 | inter-task dependencies. This more generic form allows for |
1827 | inter-dependency checks for specific tasks rather than checks for the | 1827 | inter-dependency checks for specific tasks rather than checks for the |
1828 | data in ``DEPENDS``. Here is an example: :: | 1828 | data in ``DEPENDS``. Here is an example:: |
1829 | 1829 | ||
1830 | do_patch[depends] = "quilt-native:do_populate_sysroot" | 1830 | do_patch[depends] = "quilt-native:do_populate_sysroot" |
1831 | 1831 | ||
@@ -1920,7 +1920,7 @@ To help understand how BitBake does this, the section assumes an | |||
1920 | OpenEmbedded metadata-based example. | 1920 | OpenEmbedded metadata-based example. |
1921 | 1921 | ||
1922 | These checksums are stored in :term:`STAMP`. You can | 1922 | These checksums are stored in :term:`STAMP`. You can |
1923 | examine the checksums using the following BitBake command: :: | 1923 | examine the checksums using the following BitBake command:: |
1924 | 1924 | ||
1925 | $ bitbake-dumpsigs | 1925 | $ bitbake-dumpsigs |
1926 | 1926 | ||
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst index 489fa15fad..e1b640e2fd 100644 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst +++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst | |||
@@ -130,7 +130,7 @@ overview of their function and contents. | |||
130 | you to control the build based on these parameters. | 130 | you to control the build based on these parameters. |
131 | 131 | ||
132 | Disk space monitoring is disabled by default. When setting this | 132 | Disk space monitoring is disabled by default. When setting this |
133 | variable, use the following form: :: | 133 | variable, use the following form:: |
134 | 134 | ||
135 | BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]" | 135 | BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]" |
136 | 136 | ||
@@ -166,7 +166,7 @@ overview of their function and contents. | |||
166 | not specify G, M, or K, Kbytes is assumed by | 166 | not specify G, M, or K, Kbytes is assumed by |
167 | default. Do not use GB, MB, or KB. | 167 | default. Do not use GB, MB, or KB. |
168 | 168 | ||
169 | Here are some examples: :: | 169 | Here are some examples:: |
170 | 170 | ||
171 | BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" | 171 | BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" |
172 | BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G" | 172 | BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G" |
@@ -207,7 +207,7 @@ overview of their function and contents. | |||
207 | BB_DISKMON_WARNINTERVAL = "50M,5K" | 207 | BB_DISKMON_WARNINTERVAL = "50M,5K" |
208 | 208 | ||
209 | When specifying the variable in your configuration file, use the | 209 | When specifying the variable in your configuration file, use the |
210 | following form: :: | 210 | following form:: |
211 | 211 | ||
212 | BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>" | 212 | BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>" |
213 | 213 | ||
@@ -223,7 +223,7 @@ overview of their function and contents. | |||
223 | G, M, or K for Gbytes, Mbytes, or Kbytes, | 223 | G, M, or K for Gbytes, Mbytes, or Kbytes, |
224 | respectively. You cannot use GB, MB, or KB. | 224 | respectively. You cannot use GB, MB, or KB. |
225 | 225 | ||
226 | Here is an example: :: | 226 | Here is an example:: |
227 | 227 | ||
228 | BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K" | 228 | BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K" |
229 | BB_DISKMON_WARNINTERVAL = "50M,5K" | 229 | BB_DISKMON_WARNINTERVAL = "50M,5K" |
@@ -329,7 +329,7 @@ overview of their function and contents. | |||
329 | Specifies the name of the log files saved into | 329 | Specifies the name of the log files saved into |
330 | ``${``\ :term:`T`\ ``}``. By default, the ``BB_LOGFMT`` | 330 | ``${``\ :term:`T`\ ``}``. By default, the ``BB_LOGFMT`` |
331 | variable is undefined and the log file names get created using the | 331 | variable is undefined and the log file names get created using the |
332 | following form: :: | 332 | following form:: |
333 | 333 | ||
334 | log.{task}.{pid} | 334 | log.{task}.{pid} |
335 | 335 | ||
@@ -383,7 +383,7 @@ overview of their function and contents. | |||
383 | Specifies the name of the executable script files (i.e. run files) | 383 | Specifies the name of the executable script files (i.e. run files) |
384 | saved into ``${``\ :term:`T`\ ``}``. By default, the | 384 | saved into ``${``\ :term:`T`\ ``}``. By default, the |
385 | ``BB_RUNFMT`` variable is undefined and the run file names get | 385 | ``BB_RUNFMT`` variable is undefined and the run file names get |
386 | created using the following form: :: | 386 | created using the following form:: |
387 | 387 | ||
388 | run.{task}.{pid} | 388 | run.{task}.{pid} |
389 | 389 | ||
@@ -511,7 +511,7 @@ overview of their function and contents. | |||
511 | This variable works similarly to the :term:`BB_TASK_NICE_LEVEL` | 511 | This variable works similarly to the :term:`BB_TASK_NICE_LEVEL` |
512 | variable except with a task's I/O priorities. | 512 | variable except with a task's I/O priorities. |
513 | 513 | ||
514 | Set the variable as follows: :: | 514 | Set the variable as follows:: |
515 | 515 | ||
516 | BB_TASK_IONICE_LEVEL = "class.prio" | 516 | BB_TASK_IONICE_LEVEL = "class.prio" |
517 | 517 | ||
@@ -529,7 +529,7 @@ overview of their function and contents. | |||
529 | In order for your I/O priority settings to take effect, you need the | 529 | In order for your I/O priority settings to take effect, you need the |
530 | Completely Fair Queuing (CFQ) Scheduler selected for the backing block | 530 | Completely Fair Queuing (CFQ) Scheduler selected for the backing block |
531 | device. To select the scheduler, use the following command form where | 531 | device. To select the scheduler, use the following command form where |
532 | device is the device (e.g. sda, sdb, and so forth): :: | 532 | device is the device (e.g. sda, sdb, and so forth):: |
533 | 533 | ||
534 | $ sudo sh -c "echo cfq > /sys/block/device/queu/scheduler" | 534 | $ sudo sh -c "echo cfq > /sys/block/device/queu/scheduler" |
535 | 535 | ||
@@ -570,7 +570,7 @@ overview of their function and contents. | |||
570 | To build a different variant of the recipe with a minimal amount of | 570 | To build a different variant of the recipe with a minimal amount of |
571 | code, it usually is as simple as adding the variable to your recipe. | 571 | code, it usually is as simple as adding the variable to your recipe. |
572 | Here are two examples. The "native" variants are from the | 572 | Here are two examples. The "native" variants are from the |
573 | OpenEmbedded-Core metadata: :: | 573 | OpenEmbedded-Core metadata:: |
574 | 574 | ||
575 | BBCLASSEXTEND =+ "native nativesdk" | 575 | BBCLASSEXTEND =+ "native nativesdk" |
576 | BBCLASSEXTEND =+ "multilib:multilib_name" | 576 | BBCLASSEXTEND =+ "multilib:multilib_name" |
@@ -658,12 +658,12 @@ overview of their function and contents. | |||
658 | ``.bb`` files in case a layer is not present. Use this avoid hard | 658 | ``.bb`` files in case a layer is not present. Use this avoid hard |
659 | dependency on those other layers. | 659 | dependency on those other layers. |
660 | 660 | ||
661 | Use the following form for ``BBFILES_DYNAMIC``: :: | 661 | Use the following form for ``BBFILES_DYNAMIC``:: |
662 | 662 | ||
663 | collection_name:filename_pattern | 663 | collection_name:filename_pattern |
664 | 664 | ||
665 | The following example identifies two collection names and two filename | 665 | The following example identifies two collection names and two filename |
666 | patterns: :: | 666 | patterns:: |
667 | 667 | ||
668 | BBFILES_DYNAMIC += "\ | 668 | BBFILES_DYNAMIC += "\ |
669 | clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \ | 669 | clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \ |
@@ -671,14 +671,14 @@ overview of their function and contents. | |||
671 | " | 671 | " |
672 | 672 | ||
673 | When the collection name is prefixed with "!" it will add the file pattern in case | 673 | When the collection name is prefixed with "!" it will add the file pattern in case |
674 | the layer is absent: :: | 674 | the layer is absent:: |
675 | 675 | ||
676 | BBFILES_DYNAMIC += "\ | 676 | BBFILES_DYNAMIC += "\ |
677 | !clang-layer:${LAYERDIR}/backfill/meta-clang/*/*/*.bb \ | 677 | !clang-layer:${LAYERDIR}/backfill/meta-clang/*/*/*.bb \ |
678 | " | 678 | " |
679 | 679 | ||
680 | This next example shows an error message that occurs because invalid | 680 | This next example shows an error message that occurs because invalid |
681 | entries are found, which cause parsing to abort: :: | 681 | entries are found, which cause parsing to abort:: |
682 | 682 | ||
683 | ERROR: BBFILES_DYNAMIC entries must be of the form {!}<collection name>:<filename pattern>, not: | 683 | ERROR: BBFILES_DYNAMIC entries must be of the form {!}<collection name>:<filename pattern>, not: |
684 | /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend | 684 | /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend |
@@ -701,7 +701,7 @@ overview of their function and contents. | |||
701 | :term:`BBLAYERS` | 701 | :term:`BBLAYERS` |
702 | Lists the layers to enable during the build. This variable is defined | 702 | Lists the layers to enable during the build. This variable is defined |
703 | in the ``bblayers.conf`` configuration file in the build directory. | 703 | in the ``bblayers.conf`` configuration file in the build directory. |
704 | Here is an example: :: | 704 | Here is an example:: |
705 | 705 | ||
706 | BBLAYERS = " \ | 706 | BBLAYERS = " \ |
707 | /home/scottrif/poky/meta \ | 707 | /home/scottrif/poky/meta \ |
@@ -735,13 +735,13 @@ overview of their function and contents. | |||
735 | 735 | ||
736 | The following example uses a complete regular expression to tell | 736 | The following example uses a complete regular expression to tell |
737 | BitBake to ignore all recipe and recipe append files in the | 737 | BitBake to ignore all recipe and recipe append files in the |
738 | ``meta-ti/recipes-misc/`` directory: :: | 738 | ``meta-ti/recipes-misc/`` directory:: |
739 | 739 | ||
740 | BBMASK = "meta-ti/recipes-misc/" | 740 | BBMASK = "meta-ti/recipes-misc/" |
741 | 741 | ||
742 | If you want to mask out multiple directories or recipes, you can | 742 | If you want to mask out multiple directories or recipes, you can |
743 | specify multiple regular expression fragments. This next example | 743 | specify multiple regular expression fragments. This next example |
744 | masks out multiple directories and individual recipes: :: | 744 | masks out multiple directories and individual recipes:: |
745 | 745 | ||
746 | BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/" | 746 | BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/" |
747 | BBMASK += "/meta-oe/recipes-support/" | 747 | BBMASK += "/meta-oe/recipes-support/" |
@@ -762,7 +762,7 @@ overview of their function and contents. | |||
762 | ``conf/local.conf`` configuration file. | 762 | ``conf/local.conf`` configuration file. |
763 | 763 | ||
764 | As an example, the following line specifies three multiconfigs, each | 764 | As an example, the following line specifies three multiconfigs, each |
765 | having a separate configuration file: :: | 765 | having a separate configuration file:: |
766 | 766 | ||
767 | BBMULTIFONFIG = "configA configB configC" | 767 | BBMULTIFONFIG = "configA configB configC" |
768 | 768 | ||
@@ -783,7 +783,7 @@ overview of their function and contents. | |||
783 | If you run BitBake from a directory outside of the build directory, | 783 | If you run BitBake from a directory outside of the build directory, |
784 | you must be sure to set ``BBPATH`` to point to the build directory. | 784 | you must be sure to set ``BBPATH`` to point to the build directory. |
785 | Set the variable as you would any environment variable and then run | 785 | Set the variable as you would any environment variable and then run |
786 | BitBake: :: | 786 | BitBake:: |
787 | 787 | ||
788 | $ BBPATH="build_directory" | 788 | $ BBPATH="build_directory" |
789 | $ export BBPATH | 789 | $ export BBPATH |
@@ -852,7 +852,7 @@ overview of their function and contents. | |||
852 | 852 | ||
853 | Consider this simple example for two recipes named "a" and "b" that | 853 | Consider this simple example for two recipes named "a" and "b" that |
854 | produce similarly named packages. In this example, the ``DEPENDS`` | 854 | produce similarly named packages. In this example, the ``DEPENDS`` |
855 | statement appears in the "a" recipe: :: | 855 | statement appears in the "a" recipe:: |
856 | 856 | ||
857 | DEPENDS = "b" | 857 | DEPENDS = "b" |
858 | 858 | ||
@@ -1074,7 +1074,7 @@ overview of their function and contents. | |||
1074 | recipes provide the same item. You should always suffix the variable | 1074 | recipes provide the same item. You should always suffix the variable |
1075 | with the name of the provided item, and you should set it to the | 1075 | with the name of the provided item, and you should set it to the |
1076 | :term:`PN` of the recipe to which you want to give | 1076 | :term:`PN` of the recipe to which you want to give |
1077 | precedence. Some examples: :: | 1077 | precedence. Some examples:: |
1078 | 1078 | ||
1079 | PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" | 1079 | PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" |
1080 | PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" | 1080 | PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" |
@@ -1086,11 +1086,11 @@ overview of their function and contents. | |||
1086 | ``PREFERRED_PROVIDERS`` is identical to | 1086 | ``PREFERRED_PROVIDERS`` is identical to |
1087 | :term:`PREFERRED_PROVIDER`. However, the ``PREFERRED_PROVIDERS`` variable | 1087 | :term:`PREFERRED_PROVIDER`. However, the ``PREFERRED_PROVIDERS`` variable |
1088 | lets you define preferences for multiple situations using the following | 1088 | lets you define preferences for multiple situations using the following |
1089 | form: :: | 1089 | form:: |
1090 | 1090 | ||
1091 | PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..." | 1091 | PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..." |
1092 | 1092 | ||
1093 | This form is a convenient replacement for the following: :: | 1093 | This form is a convenient replacement for the following:: |
1094 | 1094 | ||
1095 | PREFERRED_PROVIDER_xxx = "yyy" | 1095 | PREFERRED_PROVIDER_xxx = "yyy" |
1096 | PREFERRED_PROVIDER_aaa = "bbb" | 1096 | PREFERRED_PROVIDER_aaa = "bbb" |
@@ -1106,7 +1106,7 @@ overview of their function and contents. | |||
1106 | through the "``%``" character. You can use the character to match any | 1106 | through the "``%``" character. You can use the character to match any |
1107 | number of characters, which can be useful when specifying versions | 1107 | number of characters, which can be useful when specifying versions |
1108 | that contain long revision numbers that potentially change. Here are | 1108 | that contain long revision numbers that potentially change. Here are |
1109 | two examples: :: | 1109 | two examples:: |
1110 | 1110 | ||
1111 | PREFERRED_VERSION_python = "2.7.3" | 1111 | PREFERRED_VERSION_python = "2.7.3" |
1112 | PREFERRED_VERSION_linux-yocto = "4.12%" | 1112 | PREFERRED_VERSION_linux-yocto = "4.12%" |
@@ -1130,7 +1130,7 @@ overview of their function and contents. | |||
1130 | 1130 | ||
1131 | Typically, you would add a specific server for the build system to | 1131 | Typically, you would add a specific server for the build system to |
1132 | attempt before any others by adding something like the following to | 1132 | attempt before any others by adding something like the following to |
1133 | your configuration: :: | 1133 | your configuration:: |
1134 | 1134 | ||
1135 | PREMIRRORS_prepend = "\ | 1135 | PREMIRRORS_prepend = "\ |
1136 | git://.*/.* http://www.yoctoproject.org/sources/ \n \ | 1136 | git://.*/.* http://www.yoctoproject.org/sources/ \n \ |
@@ -1152,7 +1152,7 @@ overview of their function and contents. | |||
1152 | ``DEPENDS``. | 1152 | ``DEPENDS``. |
1153 | 1153 | ||
1154 | Consider the following example ``PROVIDES`` statement from a recipe | 1154 | Consider the following example ``PROVIDES`` statement from a recipe |
1155 | file ``libav_0.8.11.bb``: :: | 1155 | file ``libav_0.8.11.bb``:: |
1156 | 1156 | ||
1157 | PROVIDES += "libpostproc" | 1157 | PROVIDES += "libpostproc" |
1158 | 1158 | ||
@@ -1175,7 +1175,7 @@ overview of their function and contents. | |||
1175 | :term:`PRSERV_HOST` | 1175 | :term:`PRSERV_HOST` |
1176 | The network based :term:`PR` service host and port. | 1176 | The network based :term:`PR` service host and port. |
1177 | 1177 | ||
1178 | Following is an example of how the ``PRSERV_HOST`` variable is set: :: | 1178 | Following is an example of how the ``PRSERV_HOST`` variable is set:: |
1179 | 1179 | ||
1180 | PRSERV_HOST = "localhost:0" | 1180 | PRSERV_HOST = "localhost:0" |
1181 | 1181 | ||
@@ -1196,7 +1196,7 @@ overview of their function and contents. | |||
1196 | you should always use the variable in a form with an attached package | 1196 | you should always use the variable in a form with an attached package |
1197 | name. For example, suppose you are building a development package | 1197 | name. For example, suppose you are building a development package |
1198 | that depends on the ``perl`` package. In this case, you would use the | 1198 | that depends on the ``perl`` package. In this case, you would use the |
1199 | following ``RDEPENDS`` statement: :: | 1199 | following ``RDEPENDS`` statement:: |
1200 | 1200 | ||
1201 | RDEPENDS_${PN}-dev += "perl" | 1201 | RDEPENDS_${PN}-dev += "perl" |
1202 | 1202 | ||
@@ -1207,11 +1207,11 @@ overview of their function and contents. | |||
1207 | BitBake supports specifying versioned dependencies. Although the | 1207 | BitBake supports specifying versioned dependencies. Although the |
1208 | syntax varies depending on the packaging format, BitBake hides these | 1208 | syntax varies depending on the packaging format, BitBake hides these |
1209 | differences from you. Here is the general syntax to specify versions | 1209 | differences from you. Here is the general syntax to specify versions |
1210 | with the ``RDEPENDS`` variable: :: | 1210 | with the ``RDEPENDS`` variable:: |
1211 | 1211 | ||
1212 | RDEPENDS_${PN} = "package (operator version)" | 1212 | RDEPENDS_${PN} = "package (operator version)" |
1213 | 1213 | ||
1214 | For ``operator``, you can specify the following: :: | 1214 | For ``operator``, you can specify the following:: |
1215 | 1215 | ||
1216 | = | 1216 | = |
1217 | < | 1217 | < |
@@ -1220,7 +1220,7 @@ overview of their function and contents. | |||
1220 | >= | 1220 | >= |
1221 | 1221 | ||
1222 | For example, the following sets up a dependency on version 1.2 or | 1222 | For example, the following sets up a dependency on version 1.2 or |
1223 | greater of the package ``foo``: :: | 1223 | greater of the package ``foo``:: |
1224 | 1224 | ||
1225 | RDEPENDS_${PN} = "foo (>= 1.2)" | 1225 | RDEPENDS_${PN} = "foo (>= 1.2)" |
1226 | 1226 | ||
@@ -1249,7 +1249,7 @@ overview of their function and contents. | |||
1249 | 1249 | ||
1250 | As with all package-controlling variables, you must always use the | 1250 | As with all package-controlling variables, you must always use the |
1251 | variable in conjunction with a package name override. Here is an | 1251 | variable in conjunction with a package name override. Here is an |
1252 | example: :: | 1252 | example:: |
1253 | 1253 | ||
1254 | RPROVIDES_${PN} = "widget-abi-2" | 1254 | RPROVIDES_${PN} = "widget-abi-2" |
1255 | 1255 | ||
@@ -1263,11 +1263,11 @@ overview of their function and contents. | |||
1263 | BitBake supports specifying versioned recommends. Although the syntax | 1263 | BitBake supports specifying versioned recommends. Although the syntax |
1264 | varies depending on the packaging format, BitBake hides these | 1264 | varies depending on the packaging format, BitBake hides these |
1265 | differences from you. Here is the general syntax to specify versions | 1265 | differences from you. Here is the general syntax to specify versions |
1266 | with the ``RRECOMMENDS`` variable: :: | 1266 | with the ``RRECOMMENDS`` variable:: |
1267 | 1267 | ||
1268 | RRECOMMENDS_${PN} = "package (operator version)" | 1268 | RRECOMMENDS_${PN} = "package (operator version)" |
1269 | 1269 | ||
1270 | For ``operator``, you can specify the following: :: | 1270 | For ``operator``, you can specify the following:: |
1271 | 1271 | ||
1272 | = | 1272 | = |
1273 | < | 1273 | < |
@@ -1276,7 +1276,7 @@ overview of their function and contents. | |||
1276 | >= | 1276 | >= |
1277 | 1277 | ||
1278 | For example, the following sets up a recommend on version | 1278 | For example, the following sets up a recommend on version |
1279 | 1.2 or greater of the package ``foo``: :: | 1279 | 1.2 or greater of the package ``foo``:: |
1280 | 1280 | ||
1281 | RRECOMMENDS_${PN} = "foo (>= 1.2)" | 1281 | RRECOMMENDS_${PN} = "foo (>= 1.2)" |
1282 | 1282 | ||