diff options
author | Scott Rifenbark <scott.m.rifenbark@intel.com> | 2011-12-14 15:36:47 -0800 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2011-12-16 16:58:41 +0000 |
commit | c7d27875880bd5b33efbec55947ac9e1c66b3d0e (patch) | |
tree | 7d9e5f38ef24410d20fe368fcfdecd5becfa94f0 /documentation | |
parent | 64d51768657c5d85e325338c38183398bb8bb64e (diff) | |
download | poky-c7d27875880bd5b33efbec55947ac9e1c66b3d0e.tar.gz |
documentation/poky-ref-manual/ref-bitbake.xml: Updated BitBake Running a Task
I added more information about how BitBake actually runs a task.
The information has to do with how tightly BB controls the execution
environment of the build tasks to prevent contamination from the
build machine from leaking into the task execution environment.
This tight control actually causes some unexpected behavior during
builds. For example, when a user exports and BB_ENV_EXTRAWHITE
an environment item such as CCACHE_DIR, the effects of the environment
item never make it to the BB task execution environment. They only
make it to the data store. The user actually has to take some extra
steps to export that environment item into the task execution environment.
The added information I put into the "Running a Task" section describes
these extra steps.
Fixes [YOCTO #689]
Reported-by: Wolfgang Denk <wd@denx.de>
(From yocto-docs rev: 182aa61693c2c7de8331569c30cbb8f41dad2315)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r-- | documentation/poky-ref-manual/ref-bitbake.xml | 44 |
1 files changed, 43 insertions, 1 deletions
diff --git a/documentation/poky-ref-manual/ref-bitbake.xml b/documentation/poky-ref-manual/ref-bitbake.xml index 16c5137a50..6b058008fc 100644 --- a/documentation/poky-ref-manual/ref-bitbake.xml +++ b/documentation/poky-ref-manual/ref-bitbake.xml | |||
@@ -260,8 +260,50 @@ | |||
260 | <para> | 260 | <para> |
261 | Once all the tasks have been completed BitBake exits. | 261 | Once all the tasks have been completed BitBake exits. |
262 | </para> | 262 | </para> |
263 | </section> | ||
264 | 263 | ||
264 | <para> | ||
265 | When running a task, BitBake tightly controls the execution environment | ||
266 | of the build tasks to make sure unwanted contamination from the build machine | ||
267 | cannot influence the build. | ||
268 | Consequently, if you do want something to get passed into the build | ||
269 | task's environment, you must take a few steps: | ||
270 | <orderedlist> | ||
271 | <listitem><para>Tell BitBake to load what you want from the environment | ||
272 | into the data store. | ||
273 | You can do so through the <filename>BB_ENV_WHITELIST</filename> | ||
274 | variable. | ||
275 | For example, assume you want to prevent the build system from | ||
276 | accessing your <filename>$HOME/.ccache</filename> directory. | ||
277 | The following command tells BitBake to load | ||
278 | <filename>CCACHE_DIR</filename> from the environment into the data | ||
279 | store: | ||
280 | <literallayout class='monospaced'> | ||
281 | export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR" | ||
282 | </literallayout></para></listitem> | ||
283 | <listitem><para>Tell BitBake to export what you have loaded into the | ||
284 | environment store to the task environment of every running task. | ||
285 | Loading something from the environment into the data store | ||
286 | (previous step) only makes it available in the datastore. | ||
287 | To export it to the task environment of every running task, | ||
288 | use a command similar to the following in your | ||
289 | <filename>local.conf</filename> or distro configuration file: | ||
290 | <literallayout class='monospaced'> | ||
291 | export CCACHE_DIR | ||
292 | </literallayout></para></listitem> | ||
293 | </orderedlist> | ||
294 | </para> | ||
295 | |||
296 | <note> | ||
297 | A side effect of the previous steps is that BitBake records the variable | ||
298 | as a dependency of the build process in things like the shared state | ||
299 | checksums. | ||
300 | If doing so results in unnecessary rebuilds of tasks, you can whitelist the | ||
301 | variable so that the shared state code ignores the dependency when it creates | ||
302 | checksums. | ||
303 | For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename> | ||
304 | example in <xref linkend='checksums'>Checksums (Signatures)</xref>. | ||
305 | </note> | ||
306 | </section> | ||
265 | 307 | ||
266 | <section id='ref-bitbake-commandline'> | 308 | <section id='ref-bitbake-commandline'> |
267 | <title>BitBake Command Line</title> | 309 | <title>BitBake Command Line</title> |