diff options
Diffstat (limited to 'documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html')
-rw-r--r-- | documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html | 93 |
1 files changed, 0 insertions, 93 deletions
diff --git a/documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html b/documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html deleted file mode 100644 index c5c6be04a3..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html +++ /dev/null | |||
@@ -1,93 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.3. Shared State Cache</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="overview-concepts.html" title="Chapter 3. Yocto Project Concepts"> | ||
9 | <link rel="prev" href="cross-development-toolchain-generation.html" title="3.2. Cross-Development Toolchain Generation"> | ||
10 | <link rel="next" href="overall-architecture.html" title="3.3.1. Overall Architecture"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3. Shared State Cache"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="shared-state-cache"></a>3.3. Shared State Cache</h2></div></div></div> | ||
15 | <p> | ||
16 | By design, the OpenEmbedded build system builds everything from | ||
17 | scratch unless BitBake can determine that parts do not need to be | ||
18 | rebuilt. | ||
19 | Fundamentally, building from scratch is attractive as it means all | ||
20 | parts are built fresh and there is no possibility of stale data | ||
21 | causing problems. | ||
22 | When developers hit problems, they typically default back to | ||
23 | building from scratch so they know the state of things from the | ||
24 | start. | ||
25 | </p> | ||
26 | <p> | ||
27 | Building an image from scratch is both an advantage and a | ||
28 | disadvantage to the process. | ||
29 | As mentioned in the previous paragraph, building from scratch | ||
30 | ensures that everything is current and starts from a known state. | ||
31 | However, building from scratch also takes much longer as it | ||
32 | generally means rebuilding things that do not necessarily need | ||
33 | to be rebuilt. | ||
34 | </p> | ||
35 | <p> | ||
36 | The Yocto Project implements shared state code that supports | ||
37 | incremental builds. | ||
38 | The implementation of the shared state code answers the following | ||
39 | questions that were fundamental roadblocks within the OpenEmbedded | ||
40 | incremental build support system: | ||
41 | </p> | ||
42 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
43 | <li class="listitem"><p> | ||
44 | What pieces of the system have changed and what pieces have | ||
45 | not changed? | ||
46 | </p></li> | ||
47 | <li class="listitem"><p> | ||
48 | How are changed pieces of software removed and replaced? | ||
49 | </p></li> | ||
50 | <li class="listitem"><p> | ||
51 | How are pre-built components that do not need to be rebuilt | ||
52 | from scratch used when they are available? | ||
53 | </p></li> | ||
54 | </ul></div> | ||
55 | <p> | ||
56 | </p> | ||
57 | <p> | ||
58 | For the first question, the build system detects changes in the | ||
59 | "inputs" to a given task by creating a checksum (or signature) of | ||
60 | the task's inputs. | ||
61 | If the checksum changes, the system assumes the inputs have changed | ||
62 | and the task needs to be rerun. | ||
63 | For the second question, the shared state (sstate) code tracks | ||
64 | which tasks add which output to the build process. | ||
65 | This means the output from a given task can be removed, upgraded | ||
66 | or otherwise manipulated. | ||
67 | The third question is partly addressed by the solution for the | ||
68 | second question assuming the build system can fetch the sstate | ||
69 | objects from remote locations and install them if they are deemed | ||
70 | to be valid. | ||
71 | </p> | ||
72 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
73 | <h3 class="title">Note</h3> | ||
74 | The OpenEmbedded build system does not maintain | ||
75 | <a class="link" href="../ref-manual/var-PR.html" target="_self"><code class="filename">PR</code></a> | ||
76 | information as part of the shared state packages. | ||
77 | Consequently, considerations exist that affect maintaining | ||
78 | shared state feeds. | ||
79 | For information on how the OpenEmbedded build system | ||
80 | works with packages and can track incrementing | ||
81 | <code class="filename">PR</code> information, see the | ||
82 | "<a class="link" href="../dev-manual/automatically-incrementing-a-binary-package-revision-number.html" target="_self">Automatically Incrementing a Binary Package Revision Number</a>" | ||
83 | section in the Yocto Project Development Tasks Manual. | ||
84 | </div> | ||
85 | <p> | ||
86 | </p> | ||
87 | <p> | ||
88 | The rest of this section goes into detail about the overall | ||
89 | incremental build architecture, the checksums (signatures), shared | ||
90 | state, and some tips and tricks. | ||
91 | </p> | ||
92 | </div></body> | ||
93 | </html> | ||