diff options
Diffstat (limited to 'documentation/poky-ref-manual/ref-bitbake.xml')
-rw-r--r-- | documentation/poky-ref-manual/ref-bitbake.xml | 272 |
1 files changed, 136 insertions, 136 deletions
diff --git a/documentation/poky-ref-manual/ref-bitbake.xml b/documentation/poky-ref-manual/ref-bitbake.xml index b81f12fb7a..b641d5cff9 100644 --- a/documentation/poky-ref-manual/ref-bitbake.xml +++ b/documentation/poky-ref-manual/ref-bitbake.xml | |||
@@ -14,15 +14,15 @@ | |||
14 | $ bitbake core-image-sato | 14 | $ bitbake core-image-sato |
15 | </literallayout> | 15 | </literallayout> |
16 | </para> | 16 | </para> |
17 | 17 | ||
18 | <para> | 18 | <para> |
19 | This chapter provides an overview of what happens behind the scenes from BitBake's perspective. | 19 | This chapter provides an overview of what happens behind the scenes from BitBake's perspective. |
20 | </para> | 20 | </para> |
21 | 21 | ||
22 | <note> | 22 | <note> |
23 | BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships. | 23 | BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships. |
24 | As such, it has no real knowledge of what the tasks being executed actually do. | 24 | As such, it has no real knowledge of what the tasks being executed actually do. |
25 | BitBake just considers a list of tasks with dependencies and handles metadata | 25 | BitBake just considers a list of tasks with dependencies and handles metadata |
26 | that consists of variables in a certain format that get passed to the tasks. | 26 | that consists of variables in a certain format that get passed to the tasks. |
27 | </note> | 27 | </note> |
28 | 28 | ||
@@ -30,85 +30,85 @@ | |||
30 | <title>Parsing</title> | 30 | <title>Parsing</title> |
31 | 31 | ||
32 | <para> | 32 | <para> |
33 | BitBake parses configuration files, classes, and <filename>.bb</filename> files. | 33 | BitBake parses configuration files, classes, and <filename>.bb</filename> files. |
34 | </para> | 34 | </para> |
35 | 35 | ||
36 | <para> | 36 | <para> |
37 | The first thing BitBake does is look for the <filename>bitbake.conf</filename> file. | 37 | The first thing BitBake does is look for the <filename>bitbake.conf</filename> file. |
38 | This file resides in the | 38 | This file resides in the |
39 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> | 39 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> |
40 | within the <filename>meta/conf/</filename> directory. | 40 | within the <filename>meta/conf/</filename> directory. |
41 | BitBake finds it by examining its | 41 | BitBake finds it by examining its |
42 | <link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment | 42 | <link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment |
43 | variable and looking for the <filename>meta/conf/</filename> | 43 | variable and looking for the <filename>meta/conf/</filename> |
44 | directory. | 44 | directory. |
45 | </para> | 45 | </para> |
46 | 46 | ||
47 | <para> | 47 | <para> |
48 | The <filename>bitbake.conf</filename> file lists other configuration | 48 | The <filename>bitbake.conf</filename> file lists other configuration |
49 | files to include from a <filename>conf/</filename> | 49 | files to include from a <filename>conf/</filename> |
50 | directory below the directories listed in <filename>BBPATH</filename>. | 50 | directory below the directories listed in <filename>BBPATH</filename>. |
51 | In general, the most important configuration file from a user's perspective | 51 | In general, the most important configuration file from a user's perspective |
52 | is <filename>local.conf</filename>, which contains a user's customized | 52 | is <filename>local.conf</filename>, which contains a user's customized |
53 | settings for the OpenEmbedded build environment. | 53 | settings for the OpenEmbedded build environment. |
54 | Other notable configuration files are the distribution | 54 | Other notable configuration files are the distribution |
55 | configuration file (set by the | 55 | configuration file (set by the |
56 | <filename><link linkend='var-DISTRO'>DISTRO</link></filename> variable) | 56 | <filename><link linkend='var-DISTRO'>DISTRO</link></filename> variable) |
57 | and the machine configuration file | 57 | and the machine configuration file |
58 | (set by the | 58 | (set by the |
59 | <filename><link linkend='var-MACHINE'>MACHINE</link></filename> variable). | 59 | <filename><link linkend='var-MACHINE'>MACHINE</link></filename> variable). |
60 | The <filename>DISTRO</filename> and <filename>MACHINE</filename> BitBake environment | 60 | The <filename>DISTRO</filename> and <filename>MACHINE</filename> BitBake environment |
61 | variables are both usually set in | 61 | variables are both usually set in |
62 | the <filename>local.conf</filename> file. | 62 | the <filename>local.conf</filename> file. |
63 | Valid distribution | 63 | Valid distribution |
64 | configuration files are available in the <filename>meta/conf/distro/</filename> directory | 64 | configuration files are available in the <filename>meta/conf/distro/</filename> directory |
65 | and valid machine configuration | 65 | and valid machine configuration |
66 | files in the <filename>meta/conf/machine/</filename> directory. | 66 | files in the <filename>meta/conf/machine/</filename> directory. |
67 | Within the <filename>meta/conf/machine/include/</filename> | 67 | Within the <filename>meta/conf/machine/include/</filename> |
68 | directory are various <filename>tune-*.inc</filename> configuration files that provide common | 68 | directory are various <filename>tune-*.inc</filename> configuration files that provide common |
69 | "tuning" settings specific to and shared between particular architectures and machines. | 69 | "tuning" settings specific to and shared between particular architectures and machines. |
70 | </para> | 70 | </para> |
71 | 71 | ||
72 | <para> | 72 | <para> |
73 | After the parsing of the configuration files, some standard classes are included. | 73 | After the parsing of the configuration files, some standard classes are included. |
74 | The <filename>base.bbclass</filename> file is always included. | 74 | The <filename>base.bbclass</filename> file is always included. |
75 | Other classes that are specified in the configuration using the | 75 | Other classes that are specified in the configuration using the |
76 | <filename><link linkend='var-INHERIT'>INHERIT</link></filename> | 76 | <filename><link linkend='var-INHERIT'>INHERIT</link></filename> |
77 | variable are also included. | 77 | variable are also included. |
78 | Class files are searched for in a <filename>classes</filename> subdirectory | 78 | Class files are searched for in a <filename>classes</filename> subdirectory |
79 | under the paths in <filename>BBPATH</filename> in the same way as | 79 | under the paths in <filename>BBPATH</filename> in the same way as |
80 | configuration files. | 80 | configuration files. |
81 | </para> | 81 | </para> |
82 | 82 | ||
83 | <para> | 83 | <para> |
84 | After classes are included, the variable | 84 | After classes are included, the variable |
85 | <filename><link linkend='var-BBFILES'>BBFILES</link></filename> | 85 | <filename><link linkend='var-BBFILES'>BBFILES</link></filename> |
86 | is set, usually in | 86 | is set, usually in |
87 | <filename>local.conf</filename>, and defines the list of places to search for | 87 | <filename>local.conf</filename>, and defines the list of places to search for |
88 | <filename>.bb</filename> files. | 88 | <filename>.bb</filename> files. |
89 | By default, the <filename>BBFILES</filename> variable specifies the | 89 | By default, the <filename>BBFILES</filename> variable specifies the |
90 | <filename>meta/recipes-*/</filename> directory within Poky. | 90 | <filename>meta/recipes-*/</filename> directory within Poky. |
91 | Adding extra content to <filename>BBFILES</filename> is best achieved through the use of | 91 | Adding extra content to <filename>BBFILES</filename> is best achieved through the use of |
92 | BitBake layers as described in the | 92 | BitBake layers as described in the |
93 | "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and | 93 | "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and |
94 | Creating Layers</ulink>" section of the Yocto Project Development Manual. | 94 | Creating Layers</ulink>" section of the Yocto Project Development Manual. |
95 | </para> | 95 | </para> |
96 | 96 | ||
97 | <para> | 97 | <para> |
98 | BitBake parses each <filename>.bb</filename> file in <filename>BBFILES</filename> and | 98 | BitBake parses each <filename>.bb</filename> file in <filename>BBFILES</filename> and |
99 | stores the values of various variables. | 99 | stores the values of various variables. |
100 | In summary, for each <filename>.bb</filename> | 100 | In summary, for each <filename>.bb</filename> |
101 | file the configuration plus the base class of variables are set, followed | 101 | file the configuration plus the base class of variables are set, followed |
102 | by the data in the <filename>.bb</filename> file | 102 | by the data in the <filename>.bb</filename> file |
103 | itself, followed by any inherit commands that | 103 | itself, followed by any inherit commands that |
104 | <filename>.bb</filename> file might contain. | 104 | <filename>.bb</filename> file might contain. |
105 | </para> | 105 | </para> |
106 | 106 | ||
107 | <para> | 107 | <para> |
108 | Because parsing <filename>.bb</filename> files is a time | 108 | Because parsing <filename>.bb</filename> files is a time |
109 | consuming process, a cache is kept to speed up subsequent parsing. | 109 | consuming process, a cache is kept to speed up subsequent parsing. |
110 | This cache is invalid if the timestamp of the <filename>.bb</filename> | 110 | This cache is invalid if the timestamp of the <filename>.bb</filename> |
111 | file itself changes, or if the timestamps of any of the include, | 111 | file itself changes, or if the timestamps of any of the include, |
112 | configuration or class files the <filename>.bb</filename> | 112 | configuration or class files the <filename>.bb</filename> |
113 | file depends on changes. | 113 | file depends on changes. |
114 | </para> | 114 | </para> |
@@ -118,22 +118,22 @@ | |||
118 | <title>Preferences and Providers</title> | 118 | <title>Preferences and Providers</title> |
119 | 119 | ||
120 | <para> | 120 | <para> |
121 | Once all the <filename>.bb</filename> files have been | 121 | Once all the <filename>.bb</filename> files have been |
122 | parsed, BitBake starts to build the target (<filename>core-image-sato</filename> | 122 | parsed, BitBake starts to build the target (<filename>core-image-sato</filename> |
123 | in the previous section's example) and looks for providers of that target. | 123 | in the previous section's example) and looks for providers of that target. |
124 | Once a provider is selected, BitBake resolves all the dependencies for | 124 | Once a provider is selected, BitBake resolves all the dependencies for |
125 | the target. | 125 | the target. |
126 | In the case of <filename>core-image-sato</filename>, it would lead to | 126 | In the case of <filename>core-image-sato</filename>, it would lead to |
127 | <filename>packagegroup-core-x11-sato</filename>, | 127 | <filename>packagegroup-core-x11-sato</filename>, |
128 | which in turn leads to recipes like <filename>matchbox-terminal</filename>, | 128 | which in turn leads to recipes like <filename>matchbox-terminal</filename>, |
129 | <filename>pcmanfm</filename> and <filename>gthumb</filename>. | 129 | <filename>pcmanfm</filename> and <filename>gthumb</filename>. |
130 | These recipes in turn depend on <filename>eglibc</filename> and the toolchain. | 130 | These recipes in turn depend on <filename>eglibc</filename> and the toolchain. |
131 | </para> | 131 | </para> |
132 | 132 | ||
133 | <para> | 133 | <para> |
134 | Sometimes a target might have multiple providers. | 134 | Sometimes a target might have multiple providers. |
135 | A common example is "virtual/kernel", which is provided by each kernel package. | 135 | A common example is "virtual/kernel", which is provided by each kernel package. |
136 | Each machine often selects the best kernel provider by using a line similar to the | 136 | Each machine often selects the best kernel provider by using a line similar to the |
137 | following in the machine configuration file: | 137 | following in the machine configuration file: |
138 | </para> | 138 | </para> |
139 | 139 | ||
@@ -142,25 +142,25 @@ | |||
142 | </literallayout> | 142 | </literallayout> |
143 | 143 | ||
144 | <para> | 144 | <para> |
145 | The default <filename><link linkend='var-PREFERRED_PROVIDER'>PREFERRED_PROVIDER</link></filename> | 145 | The default <filename><link linkend='var-PREFERRED_PROVIDER'>PREFERRED_PROVIDER</link></filename> |
146 | is the provider with the same name as the target. | 146 | is the provider with the same name as the target. |
147 | </para> | 147 | </para> |
148 | 148 | ||
149 | <para> | 149 | <para> |
150 | Understanding how providers are chosen is made complicated by the fact | 150 | Understanding how providers are chosen is made complicated by the fact |
151 | that multiple versions might exist. | 151 | that multiple versions might exist. |
152 | BitBake defaults to the highest version of a provider. | 152 | BitBake defaults to the highest version of a provider. |
153 | Version comparisons are made using the same method as Debian. | 153 | Version comparisons are made using the same method as Debian. |
154 | You can use the | 154 | You can use the |
155 | <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename> | 155 | <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename> |
156 | variable to specify a particular version (usually in the distro configuration). | 156 | variable to specify a particular version (usually in the distro configuration). |
157 | You can influence the order by using the | 157 | You can influence the order by using the |
158 | <filename><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></filename> | 158 | <filename><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></filename> |
159 | variable. | 159 | variable. |
160 | By default, files have a preference of "0". | 160 | By default, files have a preference of "0". |
161 | Setting the <filename>DEFAULT_PREFERENCE</filename> to "-1" makes the | 161 | Setting the <filename>DEFAULT_PREFERENCE</filename> to "-1" makes the |
162 | package unlikely to be used unless it is explicitly referenced. | 162 | package unlikely to be used unless it is explicitly referenced. |
163 | Setting the <filename>DEFAULT_PREFERENCE</filename> to "1" makes it likely the package is used. | 163 | Setting the <filename>DEFAULT_PREFERENCE</filename> to "1" makes it likely the package is used. |
164 | <filename>PREFERRED_VERSION</filename> overrides any <filename>DEFAULT_PREFERENCE</filename> setting. | 164 | <filename>PREFERRED_VERSION</filename> overrides any <filename>DEFAULT_PREFERENCE</filename> setting. |
165 | <filename>DEFAULT_PREFERENCE</filename> is often used to mark newer and more experimental package | 165 | <filename>DEFAULT_PREFERENCE</filename> is often used to mark newer and more experimental package |
166 | versions until they have undergone sufficient testing to be considered stable. | 166 | versions until they have undergone sufficient testing to be considered stable. |
@@ -175,23 +175,23 @@ | |||
175 | <title>Dependencies</title> | 175 | <title>Dependencies</title> |
176 | 176 | ||
177 | <para> | 177 | <para> |
178 | Each target BitBake builds consists of multiple tasks such as | 178 | Each target BitBake builds consists of multiple tasks such as |
179 | <filename>fetch</filename>, <filename>unpack</filename>, | 179 | <filename>fetch</filename>, <filename>unpack</filename>, |
180 | <filename>patch</filename>, <filename>configure</filename>, | 180 | <filename>patch</filename>, <filename>configure</filename>, |
181 | and <filename>compile</filename>. | 181 | and <filename>compile</filename>. |
182 | For best performance on multi-core systems, BitBake considers each task as an independent | 182 | For best performance on multi-core systems, BitBake considers each task as an independent |
183 | entity with its own set of dependencies. | 183 | entity with its own set of dependencies. |
184 | </para> | 184 | </para> |
185 | 185 | ||
186 | <para> | 186 | <para> |
187 | Dependencies are defined through several variables. | 187 | Dependencies are defined through several variables. |
188 | You can find information about variables BitBake uses in the BitBake documentation, | 188 | You can find information about variables BitBake uses in the BitBake documentation, |
189 | which is found in the <filename>bitbake/doc/manual</filename> directory within the | 189 | which is found in the <filename>bitbake/doc/manual</filename> directory within the |
190 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. | 190 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. |
191 | At a basic level, it is sufficient to know that BitBake uses the | 191 | At a basic level, it is sufficient to know that BitBake uses the |
192 | <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename> and | 192 | <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename> and |
193 | <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variables when | 193 | <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variables when |
194 | calculating dependencies. | 194 | calculating dependencies. |
195 | </para> | 195 | </para> |
196 | </section> | 196 | </section> |
197 | 197 | ||
@@ -199,40 +199,40 @@ | |||
199 | <title>The Task List</title> | 199 | <title>The Task List</title> |
200 | 200 | ||
201 | <para> | 201 | <para> |
202 | Based on the generated list of providers and the dependency information, | 202 | Based on the generated list of providers and the dependency information, |
203 | BitBake can now calculate exactly what tasks it needs to run and in what | 203 | BitBake can now calculate exactly what tasks it needs to run and in what |
204 | order it needs to run them. | 204 | order it needs to run them. |
205 | The build now starts with BitBake forking off threads up to the limit set in the | 205 | The build now starts with BitBake forking off threads up to the limit set in the |
206 | <filename><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></filename> variable. | 206 | <filename><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></filename> variable. |
207 | BitBake continues to fork threads as long as there are tasks ready to run, | 207 | BitBake continues to fork threads as long as there are tasks ready to run, |
208 | those tasks have all their dependencies met, and the thread threshold has not been | 208 | those tasks have all their dependencies met, and the thread threshold has not been |
209 | exceeded. | 209 | exceeded. |
210 | </para> | 210 | </para> |
211 | 211 | ||
212 | <para> | 212 | <para> |
213 | It is worth noting that you can greatly speed up the build time by properly setting | 213 | It is worth noting that you can greatly speed up the build time by properly setting |
214 | the <filename>BB_NUMBER_THREADS</filename> variable. | 214 | the <filename>BB_NUMBER_THREADS</filename> variable. |
215 | See the | 215 | See the |
216 | "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" | 216 | "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" |
217 | section in the Yocto Project Quick Start for more information. | 217 | section in the Yocto Project Quick Start for more information. |
218 | </para> | 218 | </para> |
219 | 219 | ||
220 | <para> | 220 | <para> |
221 | As each task completes, a timestamp is written to the directory specified by the | 221 | As each task completes, a timestamp is written to the directory specified by the |
222 | <filename><link linkend='var-STAMP'>STAMP</link></filename> variable (usually | 222 | <filename><link linkend='var-STAMP'>STAMP</link></filename> variable (usually |
223 | <filename>build/tmp/stamps/*/</filename>). | 223 | <filename>build/tmp/stamps/*/</filename>). |
224 | On subsequent runs, BitBake looks at the <filename>/build/tmp/stamps</filename> | 224 | On subsequent runs, BitBake looks at the <filename>/build/tmp/stamps</filename> |
225 | directory and does not rerun | 225 | directory and does not rerun |
226 | tasks that are already completed unless a timestamp is found to be invalid. | 226 | tasks that are already completed unless a timestamp is found to be invalid. |
227 | Currently, invalid timestamps are only considered on a per | 227 | Currently, invalid timestamps are only considered on a per |
228 | <filename>.bb</filename> file basis. | 228 | <filename>.bb</filename> file basis. |
229 | So, for example, if the configure stamp has a timestamp greater than the | 229 | So, for example, if the configure stamp has a timestamp greater than the |
230 | compile timestamp for a given target, then the compile task would rerun. | 230 | compile timestamp for a given target, then the compile task would rerun. |
231 | Running the compile task again, however, has no effect on other providers | 231 | Running the compile task again, however, has no effect on other providers |
232 | that depend on that target. | 232 | that depend on that target. |
233 | This behavior could change or become configurable in future versions of BitBake. | 233 | This behavior could change or become configurable in future versions of BitBake. |
234 | </para> | 234 | </para> |
235 | 235 | ||
236 | <note> | 236 | <note> |
237 | Some tasks are marked as "nostamp" tasks. | 237 | Some tasks are marked as "nostamp" tasks. |
238 | No timestamp file is created when these tasks are run. | 238 | No timestamp file is created when these tasks are run. |
@@ -245,52 +245,52 @@ | |||
245 | 245 | ||
246 | <para> | 246 | <para> |
247 | Tasks can either be a shell task or a Python task. | 247 | Tasks can either be a shell task or a Python task. |
248 | For shell tasks, BitBake writes a shell script to | 248 | For shell tasks, BitBake writes a shell script to |
249 | <filename>${WORKDIR}/temp/run.do_taskname.pid</filename> and then executes the script. | 249 | <filename>${WORKDIR}/temp/run.do_taskname.pid</filename> and then executes the script. |
250 | The generated shell script contains all the exported variables, and the shell functions | 250 | The generated shell script contains all the exported variables, and the shell functions |
251 | with all variables expanded. | 251 | with all variables expanded. |
252 | Output from the shell script goes to the file <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>. | 252 | Output from the shell script goes to the file <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>. |
253 | Looking at the expanded shell functions in the run file and the output in the log files | 253 | Looking at the expanded shell functions in the run file and the output in the log files |
254 | is a useful debugging technique. | 254 | is a useful debugging technique. |
255 | </para> | 255 | </para> |
256 | 256 | ||
257 | <para> | 257 | <para> |
258 | For Python tasks, BitBake executes the task internally and logs information to the | 258 | For Python tasks, BitBake executes the task internally and logs information to the |
259 | controlling terminal. | 259 | controlling terminal. |
260 | Future versions of BitBake will write the functions to files similar to the way | 260 | Future versions of BitBake will write the functions to files similar to the way |
261 | shell tasks are handled. | 261 | shell tasks are handled. |
262 | Logging will be handled in way similar to shell tasks as well. | 262 | Logging will be handled in way similar to shell tasks as well. |
263 | </para> | 263 | </para> |
264 | 264 | ||
265 | <para> | 265 | <para> |
266 | Once all the tasks have been completed BitBake exits. | 266 | Once all the tasks have been completed BitBake exits. |
267 | </para> | 267 | </para> |
268 | 268 | ||
269 | <para> | 269 | <para> |
270 | When running a task, BitBake tightly controls the execution environment | 270 | When running a task, BitBake tightly controls the execution environment |
271 | of the build tasks to make sure unwanted contamination from the build machine | 271 | of the build tasks to make sure unwanted contamination from the build machine |
272 | cannot influence the build. | 272 | cannot influence the build. |
273 | Consequently, if you do want something to get passed into the build | 273 | Consequently, if you do want something to get passed into the build |
274 | task's environment, you must take a few steps: | 274 | task's environment, you must take a few steps: |
275 | <orderedlist> | 275 | <orderedlist> |
276 | <listitem><para>Tell BitBake to load what you want from the environment | 276 | <listitem><para>Tell BitBake to load what you want from the environment |
277 | into the data store. | 277 | into the data store. |
278 | You can do so through the <filename>BB_ENV_EXTRAWHITE</filename> | 278 | You can do so through the <filename>BB_ENV_EXTRAWHITE</filename> |
279 | variable. | 279 | variable. |
280 | For example, assume you want to prevent the build system from | 280 | For example, assume you want to prevent the build system from |
281 | accessing your <filename>$HOME/.ccache</filename> directory. | 281 | accessing your <filename>$HOME/.ccache</filename> directory. |
282 | The following command tells BitBake to load | 282 | The following command tells BitBake to load |
283 | <filename>CCACHE_DIR</filename> from the environment into the data | 283 | <filename>CCACHE_DIR</filename> from the environment into the data |
284 | store: | 284 | store: |
285 | <literallayout class='monospaced'> | 285 | <literallayout class='monospaced'> |
286 | export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR" | 286 | export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR" |
287 | </literallayout></para></listitem> | 287 | </literallayout></para></listitem> |
288 | <listitem><para>Tell BitBake to export what you have loaded into the | 288 | <listitem><para>Tell BitBake to export what you have loaded into the |
289 | environment store to the task environment of every running task. | 289 | environment store to the task environment of every running task. |
290 | Loading something from the environment into the data store | 290 | Loading something from the environment into the data store |
291 | (previous step) only makes it available in the datastore. | 291 | (previous step) only makes it available in the datastore. |
292 | To export it to the task environment of every running task, | 292 | To export it to the task environment of every running task, |
293 | use a command similar to the following in your | 293 | use a command similar to the following in your |
294 | <filename>local.conf</filename> or distro configuration file: | 294 | <filename>local.conf</filename> or distro configuration file: |
295 | <literallayout class='monospaced'> | 295 | <literallayout class='monospaced'> |
296 | export CCACHE_DIR | 296 | export CCACHE_DIR |
@@ -301,8 +301,8 @@ | |||
301 | <note> | 301 | <note> |
302 | A side effect of the previous steps is that BitBake records the variable | 302 | A side effect of the previous steps is that BitBake records the variable |
303 | as a dependency of the build process in things like the shared state | 303 | as a dependency of the build process in things like the shared state |
304 | checksums. | 304 | checksums. |
305 | If doing so results in unnecessary rebuilds of tasks, you can whitelist the | 305 | If doing so results in unnecessary rebuilds of tasks, you can whitelist the |
306 | variable so that the shared state code ignores the dependency when it creates | 306 | variable so that the shared state code ignores the dependency when it creates |
307 | checksums. | 307 | checksums. |
308 | For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename> | 308 | For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename> |
@@ -383,38 +383,38 @@ Options: | |||
383 | <title>Fetchers</title> | 383 | <title>Fetchers</title> |
384 | 384 | ||
385 | <para> | 385 | <para> |
386 | BitBake also contains a set of "fetcher" modules that allow | 386 | BitBake also contains a set of "fetcher" modules that allow |
387 | retrieval of source code from various types of sources. | 387 | retrieval of source code from various types of sources. |
388 | For example, BitBake can get source code from a disk with the metadata, from websites, | 388 | For example, BitBake can get source code from a disk with the metadata, from websites, |
389 | from remote shell accounts or from Source Code Management (SCM) systems | 389 | from remote shell accounts or from Source Code Management (SCM) systems |
390 | like <filename>cvs/subversion/git</filename>. | 390 | like <filename>cvs/subversion/git</filename>. |
391 | </para> | 391 | </para> |
392 | 392 | ||
393 | <para> | 393 | <para> |
394 | Fetchers are usually triggered by entries in | 394 | Fetchers are usually triggered by entries in |
395 | <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>. | 395 | <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>. |
396 | You can find information about the options and formats of entries for specific | 396 | You can find information about the options and formats of entries for specific |
397 | fetchers in the BitBake manual located in the | 397 | fetchers in the BitBake manual located in the |
398 | <filename>bitbake/doc/manual</filename> directory of the | 398 | <filename>bitbake/doc/manual</filename> directory of the |
399 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. | 399 | <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. |
400 | </para> | 400 | </para> |
401 | 401 | ||
402 | <para> | 402 | <para> |
403 | One useful feature for certain Source Code Manager (SCM) fetchers is the ability to | 403 | One useful feature for certain Source Code Manager (SCM) fetchers is the ability to |
404 | "auto-update" when the upstream SCM changes version. | 404 | "auto-update" when the upstream SCM changes version. |
405 | Since this ability requires certain functionality from the SCM, not all | 405 | Since this ability requires certain functionality from the SCM, not all |
406 | systems support it. | 406 | systems support it. |
407 | Currently Subversion, Bazaar and to a limited extent, Git support the ability to "auto-update". | 407 | Currently Subversion, Bazaar and to a limited extent, Git support the ability to "auto-update". |
408 | This feature works using the <filename><link linkend='var-SRCREV'>SRCREV</link></filename> | 408 | This feature works using the <filename><link linkend='var-SRCREV'>SRCREV</link></filename> |
409 | variable. | 409 | variable. |
410 | See the | 410 | See the |
411 | "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-srcrev'>Using an External SCM</ulink>" section | 411 | "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-srcrev'>Using an External SCM</ulink>" section |
412 | in the Yocto Project Development Manual for more information. | 412 | in the Yocto Project Development Manual for more information. |
413 | </para> | 413 | </para> |
414 | 414 | ||
415 | </section> | 415 | </section> |
416 | 416 | ||
417 | </chapter> | 417 | </chapter> |
418 | <!-- | 418 | <!-- |
419 | vim: expandtab tw=80 ts=4 spell spelllang=en_gb | 419 | vim: expandtab tw=80 ts=4 spell spelllang=en_gb |
420 | --> | 420 | --> |