diff options
| author | Timo Mueller <timo.mueller@bmw-carit.de> | 2013-02-08 09:16:33 -0600 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2013-02-14 17:25:35 +0000 |
| commit | a41a805500cab281fba15bd8e5d3e60b88d0d4be (patch) | |
| tree | 9973678912b57cfdef5b1f9676794a556b4d8966 /documentation/ref-manual/eclipse/html/poky-ref-manual/shared-state-cache.html | |
| parent | 768152340898cbb9faed6e8865a4e35c69833230 (diff) | |
| download | poky-a41a805500cab281fba15bd8e5d3e60b88d0d4be.tar.gz | |
documentation: Part 1 of 2 updates to integrating docs to Eclipse help.
Hi,
the generation of eclipse help files has been merged from the timo
branch to the master. Since the creation of the timo branch there have
been some changes to the master branch (e.g. new documentation,
renamed documentation).
This patch set does some cleanup for the renamed documentation and
adds eclipse help generation support to the new documentation.
01: Removes the 'the' from the document titles
02..04: Cleanup obsolete artifacts resulting from the merge
05..08: Add eclipse help generation for ref-manual
09..13: Add eclipse help generation for kernel-dev
14..18: Add eclipse help generation for profile-manual
Best regards,
Timo
This patch set originally contained 18 patches. I (Scott Rifenbark)
had to push these changes as two parts. This is the first part.
It does not include creation of the three cusomization files.
(From yocto-docs rev: 9b1889f6e31ee70dae704fa08763fb9196616dad)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/ref-manual/eclipse/html/poky-ref-manual/shared-state-cache.html')
| -rw-r--r-- | documentation/ref-manual/eclipse/html/poky-ref-manual/shared-state-cache.html | 60 |
1 files changed, 0 insertions, 60 deletions
diff --git a/documentation/ref-manual/eclipse/html/poky-ref-manual/shared-state-cache.html b/documentation/ref-manual/eclipse/html/poky-ref-manual/shared-state-cache.html deleted file mode 100644 index 8f2f5a5ed6..0000000000 --- a/documentation/ref-manual/eclipse/html/poky-ref-manual/shared-state-cache.html +++ /dev/null | |||
| @@ -1,60 +0,0 @@ | |||
| 1 | <html> | ||
| 2 | <head> | ||
| 3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
| 4 | <title>3.2. 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="The Yocto Project Reference Manual"> | ||
| 8 | <link rel="up" href="technical-details.html" title="Chapter 3. Technical Details"> | ||
| 9 | <link rel="prev" href="usingpoky-components-configuration.html" title="3.1.4. Configuration"> | ||
| 10 | <link rel="next" href="overall-architecture.html" title="3.2.1. Overall Architecture"> | ||
| 11 | </head> | ||
| 12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.2. Shared State Cache"> | ||
| 13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
| 14 | <a name="shared-state-cache"></a>3.2. Shared State Cache</h2></div></div></div> | ||
| 15 | <p> | ||
| 16 | By design, the OpenEmbedded build system builds everything from scratch unless | ||
| 17 | BitBake can determine that parts don't need to be rebuilt. | ||
| 18 | Fundamentally, building from scratch is attractive as it means all parts are | ||
| 19 | built fresh and there is no possibility of stale data causing problems. | ||
| 20 | When developers hit problems, they typically default back to building from scratch | ||
| 21 | so they know the state of things from the start. | ||
| 22 | </p> | ||
| 23 | <p> | ||
| 24 | Building an image from scratch is both an advantage and a disadvantage to the process. | ||
| 25 | As mentioned in the previous paragraph, building from scratch ensures that | ||
| 26 | everything is current and starts from a known state. | ||
| 27 | However, building from scratch also takes much longer as it generally means | ||
| 28 | rebuilding things that don't necessarily need rebuilt. | ||
| 29 | </p> | ||
| 30 | <p> | ||
| 31 | The Yocto Project implements shared state code that supports incremental builds. | ||
| 32 | The implementation of the shared state code answers the following questions that | ||
| 33 | were fundamental roadblocks within the OpenEmbedded incremental build support system: | ||
| 34 | </p> | ||
| 35 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
| 36 | <li class="listitem">What pieces of the system have changed and what pieces have not changed?</li> | ||
| 37 | <li class="listitem">How are changed pieces of software removed and replaced?</li> | ||
| 38 | <li class="listitem">How are pre-built components that don't need to be rebuilt from scratch | ||
| 39 | used when they are available?</li> | ||
| 40 | </ul></div> | ||
| 41 | <p> | ||
| 42 | </p> | ||
| 43 | <p> | ||
| 44 | For the first question, the build system detects changes in the "inputs" to a given task by | ||
| 45 | creating a checksum (or signature) of the task's inputs. | ||
| 46 | If the checksum changes, the system assumes the inputs have changed and the task needs to be | ||
| 47 | rerun. | ||
| 48 | For the second question, the shared state (sstate) code tracks which tasks add which output | ||
| 49 | to the build process. | ||
| 50 | This means the output from a given task can be removed, upgraded or otherwise manipulated. | ||
| 51 | The third question is partly addressed by the solution for the second question | ||
| 52 | assuming the build system can fetch the sstate objects from remote locations and | ||
| 53 | install them if they are deemed to be valid. | ||
| 54 | </p> | ||
| 55 | <p> | ||
| 56 | The rest of this section goes into detail about the overall incremental build | ||
| 57 | architecture, the checksums (signatures), shared state, and some tips and tricks. | ||
| 58 | </p> | ||
| 59 | </div></body> | ||
| 60 | </html> | ||