diff options
Diffstat (limited to 'documentation/getting-started/eclipse/html/getting-started/setscene-tasks-and-shared-state.html')
-rw-r--r-- | documentation/getting-started/eclipse/html/getting-started/setscene-tasks-and-shared-state.html | 122 |
1 files changed, 122 insertions, 0 deletions
diff --git a/documentation/getting-started/eclipse/html/getting-started/setscene-tasks-and-shared-state.html b/documentation/getting-started/eclipse/html/getting-started/setscene-tasks-and-shared-state.html new file mode 100644 index 0000000000..644e404b66 --- /dev/null +++ b/documentation/getting-started/eclipse/html/getting-started/setscene-tasks-and-shared-state.html | |||
@@ -0,0 +1,122 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.5.8. Setscene Tasks and Shared State</title> | ||
5 | <link rel="stylesheet" type="text/css" href="../book.css"> | ||
6 | <meta name="generator" content="DocBook XSL Stylesheets V1.76.1"> | ||
7 | <link rel="home" href="index.html" title="Getting Started With Yocto Project"> | ||
8 | <link rel="up" href="bitbake-dev-environment.html" title="2.8.5. BitBake"> | ||
9 | <link rel="prev" href="stamp-files-and-the-rerunning-of-tasks.html" title="2.8.5.7. Stamp Files and the Rerunning of Tasks"> | ||
10 | <link rel="next" href="images-dev-environment.html" title="2.8.6. Images"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.8. Setscene Tasks and Shared State"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="setscene-tasks-and-shared-state"></a>2.8.5.8. Setscene Tasks and Shared State</h4></div></div></div> | ||
15 | <p> | ||
16 | The description of tasks so far assumes that BitBake needs to | ||
17 | build everything and there are no prebuilt objects available. | ||
18 | BitBake does support skipping tasks if prebuilt objects are | ||
19 | available. | ||
20 | These objects are usually made available in the form of a | ||
21 | shared state (sstate) cache. | ||
22 | </p> | ||
23 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
24 | <h3 class="title">Note</h3> | ||
25 | For information on variables affecting sstate, see the | ||
26 | <a class="link" href="../ref-manual/var-SSTATE_DIR.html" target="_self"><code class="filename">SSTATE_DIR</code></a> | ||
27 | and | ||
28 | <a class="link" href="../ref-manual/var-SSTATE_MIRRORS.html" target="_self"><code class="filename">SSTATE_MIRRORS</code></a> | ||
29 | variables. | ||
30 | </div> | ||
31 | <p> | ||
32 | </p> | ||
33 | <p> | ||
34 | The idea of a setscene task (i.e | ||
35 | <code class="filename">do_</code><em class="replaceable"><code>taskname</code></em><code class="filename">_setscene</code>) | ||
36 | is a version of the task where | ||
37 | instead of building something, BitBake can skip to the end | ||
38 | result and simply place a set of files into specific locations | ||
39 | as needed. | ||
40 | In some cases, it makes sense to have a setscene task variant | ||
41 | (e.g. generating package files in the | ||
42 | <code class="filename">do_package_write_*</code> task). | ||
43 | In other cases, it does not make sense, (e.g. a | ||
44 | <a class="link" href="../ref-manual/ref-tasks-patch.html" target="_self"><code class="filename">do_patch</code></a> | ||
45 | task or | ||
46 | <a class="link" href="../ref-manual/ref-tasks-unpack.html" target="_self"><code class="filename">do_unpack</code></a> | ||
47 | task) since the work involved would be equal to or greater than | ||
48 | the underlying task. | ||
49 | </p> | ||
50 | <p> | ||
51 | In the OpenEmbedded build system, the common tasks that have | ||
52 | setscene variants are | ||
53 | <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>, | ||
54 | <code class="filename">do_package_write_*</code>, | ||
55 | <a class="link" href="../ref-manual/ref-tasks-deploy.html" target="_self"><code class="filename">do_deploy</code></a>, | ||
56 | <a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a>, | ||
57 | and | ||
58 | <a class="link" href="../ref-manual/ref-tasks-populate_sysroot.html" target="_self"><code class="filename">do_populate_sysroot</code></a>. | ||
59 | Notice that these are most of the tasks whose output is an | ||
60 | end result. | ||
61 | </p> | ||
62 | <p> | ||
63 | The OpenEmbedded build system has knowledge of the relationship | ||
64 | between these tasks and other tasks that precede them. | ||
65 | For example, if BitBake runs | ||
66 | <code class="filename">do_populate_sysroot_setscene</code> for | ||
67 | something, there is little point in running any of the | ||
68 | <code class="filename">do_fetch</code>, <code class="filename">do_unpack</code>, | ||
69 | <code class="filename">do_patch</code>, | ||
70 | <code class="filename">do_configure</code>, | ||
71 | <code class="filename">do_compile</code>, and | ||
72 | <code class="filename">do_install</code> tasks. | ||
73 | However, if <code class="filename">do_package</code> needs to be run, | ||
74 | BitBake would need to run those other tasks. | ||
75 | </p> | ||
76 | <p> | ||
77 | It becomes more complicated if everything can come from an | ||
78 | sstate cache because some objects are simply not required at | ||
79 | all. | ||
80 | For example, you do not need a compiler or native tools, such | ||
81 | as quilt, if there is nothing to compile or patch. | ||
82 | If the <code class="filename">do_package_write_*</code> packages are | ||
83 | available from sstate, BitBake does not need the | ||
84 | <code class="filename">do_package</code> task data. | ||
85 | </p> | ||
86 | <p> | ||
87 | To handle all these complexities, BitBake runs in two phases. | ||
88 | The first is the "setscene" stage. | ||
89 | During this stage, BitBake first checks the sstate cache for | ||
90 | any targets it is planning to build. | ||
91 | BitBake does a fast check to see if the object exists rather | ||
92 | than a complete download. | ||
93 | If nothing exists, the second phase, which is the setscene | ||
94 | stage, completes and the main build proceeds. | ||
95 | </p> | ||
96 | <p> | ||
97 | If objects are found in the sstate cache, the OpenEmbedded | ||
98 | build system works backwards from the end targets specified | ||
99 | by the user. | ||
100 | For example, if an image is being built, the OpenEmbedded build | ||
101 | system first looks for the packages needed for that image and | ||
102 | the tools needed to construct an image. | ||
103 | If those are available, the compiler is not needed. | ||
104 | Thus, the compiler is not even downloaded. | ||
105 | If something was found to be unavailable, or the download or | ||
106 | setscene task fails, the OpenEmbedded build system then tries | ||
107 | to install dependencies, such as the compiler, from the cache. | ||
108 | </p> | ||
109 | <p> | ||
110 | The availability of objects in the sstate cache is handled by | ||
111 | the function specified by the | ||
112 | <a class="link" href="../bitbake-user-manual/var-BB_HASHCHECK_FUNCTION.html" target="_self"><code class="filename">BB_HASHCHECK_FUNCTION</code></a> | ||
113 | variable and returns a list of the objects that are available. | ||
114 | The function specified by the | ||
115 | <a class="link" href="../bitbake-user-manual/var-BB_SETSCENE_DEPVALID.html" target="_self"><code class="filename">BB_SETSCENE_DEPVALID</code></a> | ||
116 | variable is the function that determines whether a given | ||
117 | dependency needs to be followed, and whether for any given | ||
118 | relationship the function needs to be passed. | ||
119 | The function returns a True or False value. | ||
120 | </p> | ||
121 | </div></body> | ||
122 | </html> | ||