diff options
author | Scott Rifenbark <srifenbark@gmail.com> | 2018-01-29 15:18:03 -0800 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2018-02-14 15:25:29 +0000 |
commit | ae06e04cd225d2c2147ca355e2dd39b4f6cf6775 (patch) | |
tree | c920e85262a91e7626279e7dcbbd56a299919f49 /documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html | |
parent | ebc7de094881dd8f2450aa4fdf548f2e9c835df1 (diff) | |
download | poky-ae06e04cd225d2c2147ca355e2dd39b4f6cf6775.tar.gz |
documentation: Created new "Getting Started" manual.
Creation involved removing the overview-manual and replacing it
with the getting-started manual. All links to the string
"&YOCTO_DOCS_OVERVIEW_URL" had to be replaced with
"&YOCTO_DOCS_GS_URL" across the entire YP manual set. I renamed
files used to create the manual with prefixes suited for the
new manual name, which is "Getting Started With Yocto Project".
The style sheet for the new manual needed updating to display the
new .PNG image for the title page. The mega-manual file had to
be updated to include the files. The mega-manual.sed file had
to be updated to include the new manual and not use the overview
manual.
(From yocto-docs rev: 6c7abf9192390121000f577d6c98f259d290d15d)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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, 93 insertions, 0 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 new file mode 100644 index 0000000000..c5c6be04a3 --- /dev/null +++ b/documentation/getting-started/eclipse/html/getting-started/shared-state-cache.html | |||
@@ -0,0 +1,93 @@ | |||
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> | ||