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/overall-architecture.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/overall-architecture.html')
-rw-r--r-- | documentation/getting-started/eclipse/html/getting-started/overall-architecture.html | 40 |
1 files changed, 40 insertions, 0 deletions
diff --git a/documentation/getting-started/eclipse/html/getting-started/overall-architecture.html b/documentation/getting-started/eclipse/html/getting-started/overall-architecture.html new file mode 100644 index 0000000000..974b05792a --- /dev/null +++ b/documentation/getting-started/eclipse/html/getting-started/overall-architecture.html | |||
@@ -0,0 +1,40 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.3.1. Overall Architecture</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="shared-state-cache.html" title="3.3. Shared State Cache"> | ||
9 | <link rel="prev" href="shared-state-cache.html" title="3.3. Shared State Cache"> | ||
10 | <link rel="next" href="overview-checksums.html" title="3.3.2. Checksums (Signatures)"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.1. Overall Architecture"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="overall-architecture"></a>3.3.1. Overall Architecture</h3></div></div></div> | ||
15 | <p> | ||
16 | When determining what parts of the system need to be built, | ||
17 | BitBake works on a per-task basis rather than a per-recipe | ||
18 | basis. | ||
19 | You might wonder why using a per-task basis is preferred over | ||
20 | a per-recipe basis. | ||
21 | To help explain, consider having the IPK packaging backend | ||
22 | enabled and then switching to DEB. | ||
23 | In this case, the | ||
24 | <a class="link" href="../ref-manual/ref-tasks-install.html" target="_self"><code class="filename">do_install</code></a> | ||
25 | and | ||
26 | <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a> | ||
27 | task outputs are still valid. | ||
28 | However, with a per-recipe approach, the build would not | ||
29 | include the <code class="filename">.deb</code> files. | ||
30 | Consequently, you would have to invalidate the whole build and | ||
31 | rerun it. | ||
32 | Rerunning everything is not the best solution. | ||
33 | Also, in this case, the core must be "taught" much about | ||
34 | specific tasks. | ||
35 | This methodology does not scale well and does not allow users | ||
36 | to easily add new tasks in layers or as external recipes | ||
37 | without touching the packaged-staging core. | ||
38 | </p> | ||
39 | </div></body> | ||
40 | </html> | ||