diff options
Diffstat (limited to 'documentation/getting-started/eclipse/html')
89 files changed, 0 insertions, 6035 deletions
diff --git a/documentation/getting-started/eclipse/html/getting-started/automatically-added-runtime-dependencies.html b/documentation/getting-started/eclipse/html/getting-started/automatically-added-runtime-dependencies.html deleted file mode 100644 index 885ee089e1..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/automatically-added-runtime-dependencies.html +++ /dev/null | |||
@@ -1,164 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.4. Automatically Added Runtime Dependencies</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="invalidating-shared-state.html" title="3.3.4.2. Invalidating Shared State"> | ||
10 | <link rel="next" href="fakeroot-and-pseudo.html" title="3.5. Fakeroot and Pseudo"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.4. Automatically Added Runtime Dependencies"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="automatically-added-runtime-dependencies"></a>3.4. Automatically Added Runtime Dependencies</h2></div></div></div> | ||
15 | <p> | ||
16 | The OpenEmbedded build system automatically adds common types of | ||
17 | runtime dependencies between packages, which means that you do not | ||
18 | need to explicitly declare the packages using | ||
19 | <a class="link" href="../ref-manual/var-RDEPENDS.html" target="_self"><code class="filename">RDEPENDS</code></a>. | ||
20 | Three automatic mechanisms exist (<code class="filename">shlibdeps</code>, | ||
21 | <code class="filename">pcdeps</code>, and <code class="filename">depchains</code>) | ||
22 | that handle shared libraries, package configuration (pkg-config) | ||
23 | modules, and <code class="filename">-dev</code> and | ||
24 | <code class="filename">-dbg</code> packages, respectively. | ||
25 | For other types of runtime dependencies, you must manually declare | ||
26 | the dependencies. | ||
27 | </p> | ||
28 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
29 | <li class="listitem"> | ||
30 | <p> | ||
31 | <code class="filename">shlibdeps</code>: | ||
32 | During the | ||
33 | <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a> | ||
34 | task of each recipe, all shared libraries installed by the | ||
35 | recipe are located. | ||
36 | For each shared library, the package that contains the | ||
37 | shared library is registered as providing the shared | ||
38 | library. | ||
39 | More specifically, the package is registered as providing | ||
40 | the | ||
41 | <a class="ulink" href="https://en.wikipedia.org/wiki/Soname" target="_self">soname</a> | ||
42 | of the library. | ||
43 | The resulting shared-library-to-package mapping | ||
44 | is saved globally in | ||
45 | <a class="link" href="../ref-manual/var-PKGDATA_DIR.html" target="_self"><code class="filename">PKGDATA_DIR</code></a> | ||
46 | by the | ||
47 | <a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a> | ||
48 | task.</p> | ||
49 | <p>Simultaneously, all executables and shared libraries | ||
50 | installed by the recipe are inspected to see what shared | ||
51 | libraries they link against. | ||
52 | For each shared library dependency that is found, | ||
53 | <code class="filename">PKGDATA_DIR</code> is queried to | ||
54 | see if some package (likely from a different recipe) | ||
55 | contains the shared library. | ||
56 | If such a package is found, a runtime dependency is added | ||
57 | from the package that depends on the shared library to the | ||
58 | package that contains the library.</p> | ||
59 | <p>The automatically added runtime dependency also | ||
60 | includes a version restriction. | ||
61 | This version restriction specifies that at least the | ||
62 | current version of the package that provides the shared | ||
63 | library must be used, as if | ||
64 | "<em class="replaceable"><code>package</code></em> (>= <em class="replaceable"><code>version</code></em>)" | ||
65 | had been added to | ||
66 | <a class="link" href="../ref-manual/var-RDEPENDS.html" target="_self"><code class="filename">RDEPENDS</code></a>. | ||
67 | This forces an upgrade of the package containing the shared | ||
68 | library when installing the package that depends on the | ||
69 | library, if needed.</p> | ||
70 | <p>If you want to avoid a package being registered as | ||
71 | providing a particular shared library (e.g. because the library | ||
72 | is for internal use only), then add the library to | ||
73 | <a class="link" href="../ref-manual/var-PRIVATE_LIBS.html" target="_self"><code class="filename">PRIVATE_LIBS</code></a> | ||
74 | inside the package's recipe. | ||
75 | </p> | ||
76 | </li> | ||
77 | <li class="listitem"> | ||
78 | <p> | ||
79 | <code class="filename">pcdeps</code>: | ||
80 | During the | ||
81 | <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a> | ||
82 | task of each recipe, all pkg-config modules | ||
83 | (<code class="filename">*.pc</code> files) installed by the recipe | ||
84 | are located. | ||
85 | For each module, the package that contains the module is | ||
86 | registered as providing the module. | ||
87 | The resulting module-to-package mapping is saved globally in | ||
88 | <a class="link" href="../ref-manual/var-PKGDATA_DIR.html" target="_self"><code class="filename">PKGDATA_DIR</code></a> | ||
89 | by the | ||
90 | <a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a> | ||
91 | task.</p> | ||
92 | <p>Simultaneously, all pkg-config modules installed by | ||
93 | the recipe are inspected to see what other pkg-config | ||
94 | modules they depend on. | ||
95 | A module is seen as depending on another module if it | ||
96 | contains a "Requires:" line that specifies the other module. | ||
97 | For each module dependency, | ||
98 | <code class="filename">PKGDATA_DIR</code> is queried to see if some | ||
99 | package contains the module. | ||
100 | If such a package is found, a runtime dependency is added | ||
101 | from the package that depends on the module to the package | ||
102 | that contains the module. | ||
103 | </p> | ||
104 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
105 | <h3 class="title">Note</h3> | ||
106 | The <code class="filename">pcdeps</code> mechanism most often | ||
107 | infers dependencies between <code class="filename">-dev</code> | ||
108 | packages. | ||
109 | </div> | ||
110 | <p> | ||
111 | </p> | ||
112 | </li> | ||
113 | <li class="listitem"> | ||
114 | <p> | ||
115 | <code class="filename">depchains</code>: | ||
116 | If a package <code class="filename">foo</code> depends on a package | ||
117 | <code class="filename">bar</code>, then <code class="filename">foo-dev</code> | ||
118 | and <code class="filename">foo-dbg</code> are also made to depend on | ||
119 | <code class="filename">bar-dev</code> and | ||
120 | <code class="filename">bar-dbg</code>, respectively. | ||
121 | Taking the <code class="filename">-dev</code> packages as an | ||
122 | example, the <code class="filename">bar-dev</code> package might | ||
123 | provide headers and shared library symlinks needed by | ||
124 | <code class="filename">foo-dev</code>, which shows the need | ||
125 | for a dependency between the packages.</p> | ||
126 | <p>The dependencies added by | ||
127 | <code class="filename">depchains</code> are in the form of | ||
128 | <a class="link" href="../ref-manual/var-RRECOMMENDS.html" target="_self"><code class="filename">RRECOMMENDS</code></a>. | ||
129 | </p> | ||
130 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
131 | <h3 class="title">Note</h3> | ||
132 | By default, <code class="filename">foo-dev</code> also has an | ||
133 | <code class="filename">RDEPENDS</code>-style dependency on | ||
134 | <code class="filename">foo</code>, because the default value of | ||
135 | <code class="filename">RDEPENDS_${PN}-dev</code> (set in | ||
136 | <code class="filename">bitbake.conf</code>) includes | ||
137 | "${PN}". | ||
138 | </div> | ||
139 | <p>To ensure that the dependency chain is never broken, | ||
140 | <code class="filename">-dev</code> and <code class="filename">-dbg</code> | ||
141 | packages are always generated by default, even if the | ||
142 | packages turn out to be empty. | ||
143 | See the | ||
144 | <a class="link" href="../ref-manual/var-ALLOW_EMPTY.html" target="_self"><code class="filename">ALLOW_EMPTY</code></a> | ||
145 | variable for more information. | ||
146 | </p> | ||
147 | </li> | ||
148 | </ul></div> | ||
149 | <p> | ||
150 | </p> | ||
151 | <p> | ||
152 | The <code class="filename">do_package</code> task depends on the | ||
153 | <a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a> | ||
154 | task of each recipe in | ||
155 | <a class="link" href="../ref-manual/var-DEPENDS.html" target="_self"><code class="filename">DEPENDS</code></a> | ||
156 | through use of a | ||
157 | <code class="filename">[</code><a class="link" href="../bitbake-user-manual/variable-flags.html" target="_self"><code class="filename">deptask</code></a><code class="filename">]</code> | ||
158 | declaration, which guarantees that the required | ||
159 | shared-library/module-to-package mapping information will be available | ||
160 | when needed as long as <code class="filename">DEPENDS</code> has been | ||
161 | correctly set. | ||
162 | </p> | ||
163 | </div></body> | ||
164 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/basic-commands.html b/documentation/getting-started/eclipse/html/getting-started/basic-commands.html deleted file mode 100644 index b145086974..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/basic-commands.html +++ /dev/null | |||
@@ -1,176 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.4.2. Basic Commands</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="git.html" title="2.4. Git"> | ||
9 | <link rel="prev" href="repositories-tags-and-branches.html" title="2.4.1. Repositories, Tags, and Branches"> | ||
10 | <link rel="next" href="yocto-project-repositories.html" title="2.5. Yocto Project Source Repositories"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4.2. Basic Commands"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="basic-commands"></a>2.4.2. Basic Commands</h3></div></div></div> | ||
15 | <p> | ||
16 | Git has an extensive set of commands that lets you manage changes | ||
17 | and perform collaboration over the life of a project. | ||
18 | Conveniently though, you can manage with a small set of basic | ||
19 | operations and workflows once you understand the basic | ||
20 | philosophy behind Git. | ||
21 | You do not have to be an expert in Git to be functional. | ||
22 | A good place to look for instruction on a minimal set of Git | ||
23 | commands is | ||
24 | <a class="ulink" href="http://git-scm.com/documentation" target="_self">here</a>. | ||
25 | </p> | ||
26 | <p> | ||
27 | If you do not know much about Git, you should educate | ||
28 | yourself by visiting the links previously mentioned. | ||
29 | </p> | ||
30 | <p> | ||
31 | The following list of Git commands briefly describes some basic | ||
32 | Git operations as a way to get started. | ||
33 | As with any set of commands, this list (in most cases) simply shows | ||
34 | the base command and omits the many arguments they support. | ||
35 | See the Git documentation for complete descriptions and strategies | ||
36 | on how to use these commands: | ||
37 | </p> | ||
38 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
39 | <li class="listitem"><p> | ||
40 | <span class="emphasis"><em><code class="filename">git init</code>:</em></span> | ||
41 | Initializes an empty Git repository. | ||
42 | You cannot use Git commands unless you have a | ||
43 | <code class="filename">.git</code> repository. | ||
44 | </p></li> | ||
45 | <li class="listitem"><p><a name="git-commands-clone"></a> | ||
46 | <span class="emphasis"><em><code class="filename">git clone</code>:</em></span> | ||
47 | Creates a local clone of a Git repository that is on | ||
48 | equal footing with a fellow developer’s Git repository | ||
49 | or an upstream repository. | ||
50 | </p></li> | ||
51 | <li class="listitem"><p> | ||
52 | <span class="emphasis"><em><code class="filename">git add</code>:</em></span> | ||
53 | Locally stages updated file contents to the index that | ||
54 | Git uses to track changes. | ||
55 | You must stage all files that have changed before you | ||
56 | can commit them. | ||
57 | </p></li> | ||
58 | <li class="listitem"><p> | ||
59 | <span class="emphasis"><em><code class="filename">git commit</code>:</em></span> | ||
60 | Creates a local "commit" that documents the changes you | ||
61 | made. | ||
62 | Only changes that have been staged can be committed. | ||
63 | Commits are used for historical purposes, for determining | ||
64 | if a maintainer of a project will allow the change, | ||
65 | and for ultimately pushing the change from your local | ||
66 | Git repository into the project’s upstream repository. | ||
67 | </p></li> | ||
68 | <li class="listitem"><p> | ||
69 | <span class="emphasis"><em><code class="filename">git status</code>:</em></span> | ||
70 | Reports any modified files that possibly need to be | ||
71 | staged and gives you a status of where you stand regarding | ||
72 | local commits as compared to the upstream repository. | ||
73 | </p></li> | ||
74 | <li class="listitem"><p> | ||
75 | <span class="emphasis"><em><code class="filename">git checkout</code> <em class="replaceable"><code>branch-name</code></em>:</em></span> | ||
76 | Changes your working branch. | ||
77 | This command is analogous to "cd". | ||
78 | </p></li> | ||
79 | <li class="listitem"><p><span class="emphasis"><em><code class="filename">git checkout –b</code> <em class="replaceable"><code>working-branch</code></em>:</em></span> | ||
80 | Creates and checks out a working branch on your local | ||
81 | machine that you can use to isolate your work. | ||
82 | It is a good idea to use local branches when adding | ||
83 | specific features or changes. | ||
84 | Using isolated branches facilitates easy removal of | ||
85 | changes if they do not work out. | ||
86 | </p></li> | ||
87 | <li class="listitem"><p><span class="emphasis"><em><code class="filename">git branch</code>:</em></span> | ||
88 | Displays the existing local branches associated with your | ||
89 | local repository. | ||
90 | The branch that you have currently checked out is noted | ||
91 | with an asterisk character. | ||
92 | </p></li> | ||
93 | <li class="listitem"><p> | ||
94 | <span class="emphasis"><em><code class="filename">git branch -D</code> <em class="replaceable"><code>branch-name</code></em>:</em></span> | ||
95 | Deletes an existing local branch. | ||
96 | You need to be in a local branch other than the one you | ||
97 | are deleting in order to delete | ||
98 | <em class="replaceable"><code>branch-name</code></em>. | ||
99 | </p></li> | ||
100 | <li class="listitem"><p> | ||
101 | <span class="emphasis"><em><code class="filename">git pull</code>:</em></span> | ||
102 | Retrieves information from an upstream Git repository | ||
103 | and places it in your local Git repository. | ||
104 | You use this command to make sure you are synchronized with | ||
105 | the repository from which you are basing changes | ||
106 | (.e.g. the "master" branch). | ||
107 | </p></li> | ||
108 | <li class="listitem"><p> | ||
109 | <span class="emphasis"><em><code class="filename">git push</code>:</em></span> | ||
110 | Sends all your committed local changes to the upstream Git | ||
111 | repository that your local repository is tracking | ||
112 | (e.g. a contribution repository). | ||
113 | The maintainer of the project draws from these repositories | ||
114 | to merge changes (commits) into the appropriate branch | ||
115 | of project's upstream repository. | ||
116 | </p></li> | ||
117 | <li class="listitem"><p> | ||
118 | <span class="emphasis"><em><code class="filename">git merge</code>:</em></span> | ||
119 | Combines or adds changes from one | ||
120 | local branch of your repository with another branch. | ||
121 | When you create a local Git repository, the default branch | ||
122 | is named "master". | ||
123 | A typical workflow is to create a temporary branch that is | ||
124 | based off "master" that you would use for isolated work. | ||
125 | You would make your changes in that isolated branch, | ||
126 | stage and commit them locally, switch to the "master" | ||
127 | branch, and then use the <code class="filename">git merge</code> | ||
128 | command to apply the changes from your isolated branch | ||
129 | into the currently checked out branch (e.g. "master"). | ||
130 | After the merge is complete and if you are done with | ||
131 | working in that isolated branch, you can safely delete | ||
132 | the isolated branch. | ||
133 | </p></li> | ||
134 | <li class="listitem"><p> | ||
135 | <span class="emphasis"><em><code class="filename">git cherry-pick</code>:</em></span> | ||
136 | Choose and apply specific commits from one branch | ||
137 | into another branch. | ||
138 | There are times when you might not be able to merge | ||
139 | all the changes in one branch with | ||
140 | another but need to pick out certain ones. | ||
141 | </p></li> | ||
142 | <li class="listitem"> | ||
143 | <p> | ||
144 | <span class="emphasis"><em><code class="filename">gitk</code>:</em></span> | ||
145 | Provides a GUI view of the branches and changes in your | ||
146 | local Git repository. | ||
147 | This command is a good way to graphically see where things | ||
148 | have diverged in your local repository. | ||
149 | </p> | ||
150 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
151 | <h3 class="title">Note</h3> | ||
152 | You need to install the <code class="filename">gitk</code> | ||
153 | package on your development system to use this | ||
154 | command. | ||
155 | </div> | ||
156 | <p> | ||
157 | </p> | ||
158 | </li> | ||
159 | <li class="listitem"><p> | ||
160 | <span class="emphasis"><em><code class="filename">git log</code>:</em></span> | ||
161 | Reports a history of your commits to the repository. | ||
162 | This report lists all commits regardless of whether you | ||
163 | have pushed them upstream or not. | ||
164 | </p></li> | ||
165 | <li class="listitem"><p> | ||
166 | <span class="emphasis"><em><code class="filename">git diff</code>:</em></span> | ||
167 | Displays line-by-line differences between a local | ||
168 | working file and the same file as understood by Git. | ||
169 | This command is useful to see what you have changed | ||
170 | in any given file. | ||
171 | </p></li> | ||
172 | </ul></div> | ||
173 | <p> | ||
174 | </p> | ||
175 | </div></body> | ||
176 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/bitbake-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/bitbake-dev-environment.html deleted file mode 100644 index eda2c3370f..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/bitbake-dev-environment.html +++ /dev/null | |||
@@ -1,31 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.5. BitBake</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="development-concepts.html" title="2.8. Development Concepts"> | ||
9 | <link rel="prev" href="package-feeds-dev-environment.html" title="2.8.4. Package Feeds"> | ||
10 | <link rel="next" href="source-fetching-dev-environment.html" title="2.8.5.1. Source Fetching"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5. BitBake"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="bitbake-dev-environment"></a>2.8.5. BitBake</h3></div></div></div> | ||
15 | <p> | ||
16 | The OpenEmbedded build system uses | ||
17 | <a class="link" href="../ref-manual/bitbake-term.html" target="_self">BitBake</a> | ||
18 | to produce images. | ||
19 | You can see from the | ||
20 | <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>, | ||
21 | the BitBake area consists of several functional areas. | ||
22 | This section takes a closer look at each of those areas. | ||
23 | </p> | ||
24 | <p> | ||
25 | Separate documentation exists for the BitBake tool. | ||
26 | See the | ||
27 | <a class="link" href="../bitbake-user-manual/bitbake-user-manual.html" target="_self">BitBake User Manual</a> | ||
28 | for reference material on BitBake. | ||
29 | </p> | ||
30 | </div></body> | ||
31 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/bsp-layer.html b/documentation/getting-started/eclipse/html/getting-started/bsp-layer.html deleted file mode 100644 index 2d009d5720..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/bsp-layer.html +++ /dev/null | |||
@@ -1,54 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.2.2. BSP Layer</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="metadata-machine-configuration-and-policy-configuration.html" title="2.8.2. Metadata, Machine Configuration, and Policy Configuration"> | ||
9 | <link rel="prev" href="distro-layer.html" title="2.8.2.1. Distro Layer"> | ||
10 | <link rel="next" href="software-layer.html" title="2.8.2.3. Software Layer"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.2.2. BSP Layer"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="bsp-layer"></a>2.8.2.2. BSP Layer</h4></div></div></div> | ||
15 | <p> | ||
16 | The BSP Layer provides machine configurations. | ||
17 | Everything in this layer is specific to the machine for which | ||
18 | you are building the image or the SDK. | ||
19 | A common structure or form is defined for BSP layers. | ||
20 | You can learn more about this structure in the | ||
21 | <a class="link" href="../bsp-guide/index.html" target="_self">Yocto Project Board Support Package (BSP) Developer's Guide</a>. | ||
22 | </p> | ||
23 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
24 | <h3 class="title">Note</h3> | ||
25 | In order for a BSP layer to be considered compliant with the | ||
26 | Yocto Project, it must meet some structural requirements. | ||
27 | </div> | ||
28 | <p> | ||
29 | </p> | ||
30 | <p> | ||
31 | The BSP Layer's configuration directory contains | ||
32 | configuration files for the machine | ||
33 | (<code class="filename">conf/machine/<em class="replaceable"><code>machine</code></em>.conf</code>) and, | ||
34 | of course, the layer (<code class="filename">conf/layer.conf</code>). | ||
35 | </p> | ||
36 | <p> | ||
37 | The remainder of the layer is dedicated to specific recipes | ||
38 | by function: <code class="filename">recipes-bsp</code>, | ||
39 | <code class="filename">recipes-core</code>, | ||
40 | <code class="filename">recipes-graphics</code>, and | ||
41 | <code class="filename">recipes-kernel</code>. | ||
42 | Metadata can exist for multiple formfactors, graphics | ||
43 | support systems, and so forth. | ||
44 | </p> | ||
45 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
46 | <h3 class="title">Note</h3> | ||
47 | While the figure shows several <code class="filename">recipes-*</code> | ||
48 | directories, not all these directories appear in all | ||
49 | BSP layers. | ||
50 | </div> | ||
51 | <p> | ||
52 | </p> | ||
53 | </div></body> | ||
54 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/configuration-and-compilation-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/configuration-and-compilation-dev-environment.html deleted file mode 100644 index 9a94cc47da..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/configuration-and-compilation-dev-environment.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>2.8.5.3. Configuration and Compilation</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="patching-dev-environment.html" title="2.8.5.2. Patching"> | ||
10 | <link rel="next" href="package-splitting-dev-environment.html" title="2.8.5.4. Package Splitting"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.3. Configuration and Compilation"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="configuration-and-compilation-dev-environment"></a>2.8.5.3. Configuration and Compilation</h4></div></div></div> | ||
15 | <p> | ||
16 | After source code is patched, BitBake executes tasks that | ||
17 | configure and compile the source code: | ||
18 | </p> | ||
19 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 450px"><td align="center"><img src="figures/configuration-compile-autoreconf.png" align="middle" width="630"></td></tr></table> | ||
20 | <p> | ||
21 | </p> | ||
22 | <p> | ||
23 | This step in the build process consists of three tasks: | ||
24 | </p> | ||
25 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
26 | <li class="listitem"><p> | ||
27 | <span class="emphasis"><em><a class="link" href="../ref-manual/ref-tasks-prepare_recipe_sysroot.html" target="_self"><code class="filename">do_prepare_recipe_sysroot</code></a>:</em></span> | ||
28 | This task sets up the two sysroots in | ||
29 | <code class="filename">${</code><a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a><code class="filename">}</code> | ||
30 | (i.e. <code class="filename">recipe-sysroot</code> and | ||
31 | <code class="filename">recipe-sysroot-native</code>) so that | ||
32 | the sysroots contain the contents of the | ||
33 | <a class="link" href="../ref-manual/ref-tasks-populate_sysroot.html" target="_self"><code class="filename">do_populate_sysroot</code></a> | ||
34 | tasks of the recipes on which the recipe | ||
35 | containing the tasks depends. | ||
36 | A sysroot exists for both the target and for the native | ||
37 | binaries, which run on the host system. | ||
38 | </p></li> | ||
39 | <li class="listitem"> | ||
40 | <p><span class="emphasis"><em><code class="filename">do_configure</code>:</em></span> | ||
41 | This task configures the source by enabling and | ||
42 | disabling any build-time and configuration options for | ||
43 | the software being built. | ||
44 | Configurations can come from the recipe itself as well | ||
45 | as from an inherited class. | ||
46 | Additionally, the software itself might configure itself | ||
47 | depending on the target for which it is being built. | ||
48 | </p> | ||
49 | <p>The configurations handled by the | ||
50 | <a class="link" href="../ref-manual/ref-tasks-configure.html" target="_self"><code class="filename">do_configure</code></a> | ||
51 | task are specific | ||
52 | to source code configuration for the source code | ||
53 | being built by the recipe.</p> | ||
54 | <p>If you are using the | ||
55 | <a class="link" href="../ref-manual/ref-classes-autotools.html" target="_self"><code class="filename">autotools</code></a> | ||
56 | class, | ||
57 | you can add additional configuration options by using | ||
58 | the | ||
59 | <a class="link" href="../ref-manual/var-EXTRA_OECONF.html" target="_self"><code class="filename">EXTRA_OECONF</code></a> | ||
60 | or | ||
61 | <a class="link" href="../ref-manual/var-PACKAGECONFIG_CONFARGS.html" target="_self"><code class="filename">PACKAGECONFIG_CONFARGS</code></a> | ||
62 | variables. | ||
63 | For information on how this variable works within | ||
64 | that class, see the | ||
65 | <code class="filename">meta/classes/autotools.bbclass</code> file. | ||
66 | </p> | ||
67 | </li> | ||
68 | <li class="listitem"><p><span class="emphasis"><em><code class="filename">do_compile</code>:</em></span> | ||
69 | Once a configuration task has been satisfied, BitBake | ||
70 | compiles the source using the | ||
71 | <a class="link" href="../ref-manual/ref-tasks-compile.html" target="_self"><code class="filename">do_compile</code></a> | ||
72 | task. | ||
73 | Compilation occurs in the directory pointed to by the | ||
74 | <a class="link" href="../ref-manual/var-B.html" target="_self"><code class="filename">B</code></a> | ||
75 | variable. | ||
76 | Realize that the <code class="filename">B</code> directory is, by | ||
77 | default, the same as the | ||
78 | <a class="link" href="../ref-manual/var-S.html" target="_self"><code class="filename">S</code></a> | ||
79 | directory.</p></li> | ||
80 | <li class="listitem"><p><span class="emphasis"><em><code class="filename">do_install</code>:</em></span> | ||
81 | Once compilation is done, BitBake executes the | ||
82 | <a class="link" href="../ref-manual/ref-tasks-install.html" target="_self"><code class="filename">do_install</code></a> | ||
83 | task. | ||
84 | This task copies files from the <code class="filename">B</code> | ||
85 | directory and places them in a holding area pointed to | ||
86 | by the | ||
87 | <a class="link" href="../ref-manual/var-D.html" target="_self"><code class="filename">D</code></a> | ||
88 | variable.</p></li> | ||
89 | </ul></div> | ||
90 | <p> | ||
91 | </p> | ||
92 | </div></body> | ||
93 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/cross-development-toolchain-generation.html b/documentation/getting-started/eclipse/html/getting-started/cross-development-toolchain-generation.html deleted file mode 100644 index a1aef9119d..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/cross-development-toolchain-generation.html +++ /dev/null | |||
@@ -1,241 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.2. Cross-Development Toolchain Generation</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="usingpoky-components-configuration.html" title="3.1.5. Configuration"> | ||
10 | <link rel="next" href="shared-state-cache.html" title="3.3. Shared State Cache"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.2. Cross-Development Toolchain Generation"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="cross-development-toolchain-generation"></a>3.2. Cross-Development Toolchain Generation</h2></div></div></div> | ||
15 | <p> | ||
16 | The Yocto Project does most of the work for you when it comes to | ||
17 | creating | ||
18 | <a class="link" href="../ref-manual/cross-development-toolchain.html" target="_self">cross-development toolchains</a>. | ||
19 | This section provides some technical background on how | ||
20 | cross-development toolchains are created and used. | ||
21 | For more information on toolchains, you can also see the | ||
22 | <a class="link" href="../sdk-manual/index.html" target="_self">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a> | ||
23 | manual. | ||
24 | </p> | ||
25 | <p> | ||
26 | In the Yocto Project development environment, cross-development | ||
27 | toolchains are used to build the image and applications that run | ||
28 | on the target hardware. | ||
29 | With just a few commands, the OpenEmbedded build system creates | ||
30 | these necessary toolchains for you. | ||
31 | </p> | ||
32 | <p> | ||
33 | The following figure shows a high-level build environment regarding | ||
34 | toolchain construction and use. | ||
35 | </p> | ||
36 | <p> | ||
37 | </p> | ||
38 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 540px"><td align="center"><img src="figures/cross-development-toolchains.png" align="middle" width="720"></td></tr></table> | ||
39 | <p> | ||
40 | </p> | ||
41 | <p> | ||
42 | Most of the work occurs on the Build Host. | ||
43 | This is the machine used to build images and generally work within the | ||
44 | the Yocto Project environment. | ||
45 | When you run BitBake to create an image, the OpenEmbedded build system | ||
46 | uses the host <code class="filename">gcc</code> compiler to bootstrap a | ||
47 | cross-compiler named <code class="filename">gcc-cross</code>. | ||
48 | The <code class="filename">gcc-cross</code> compiler is what BitBake uses to | ||
49 | compile source files when creating the target image. | ||
50 | You can think of <code class="filename">gcc-cross</code> simply as an | ||
51 | automatically generated cross-compiler that is used internally within | ||
52 | BitBake only. | ||
53 | </p> | ||
54 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
55 | <h3 class="title">Note</h3> | ||
56 | The extensible SDK does not use | ||
57 | <code class="filename">gcc-cross-canadian</code> since this SDK | ||
58 | ships a copy of the OpenEmbedded build system and the sysroot | ||
59 | within it contains <code class="filename">gcc-cross</code>. | ||
60 | </div> | ||
61 | <p> | ||
62 | </p> | ||
63 | <p> | ||
64 | The chain of events that occurs when <code class="filename">gcc-cross</code> is | ||
65 | bootstrapped is as follows: | ||
66 | </p> | ||
67 | <pre class="literallayout"> | ||
68 | gcc -> binutils-cross -> gcc-cross-initial -> linux-libc-headers -> glibc-initial -> glibc -> gcc-cross -> gcc-runtime | ||
69 | </pre> | ||
70 | <p> | ||
71 | </p> | ||
72 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
73 | <li class="listitem"><p> | ||
74 | <code class="filename">gcc</code>: | ||
75 | The build host's GNU Compiler Collection (GCC). | ||
76 | </p></li> | ||
77 | <li class="listitem"><p> | ||
78 | <code class="filename">binutils-cross</code>: | ||
79 | The bare minimum binary utilities needed in order to run | ||
80 | the <code class="filename">gcc-cross-initial</code> phase of the | ||
81 | bootstrap operation. | ||
82 | </p></li> | ||
83 | <li class="listitem"><p> | ||
84 | <code class="filename">gcc-cross-initial</code>: | ||
85 | An early stage of the bootstrap process for creating | ||
86 | the cross-compiler. | ||
87 | This stage builds enough of the <code class="filename">gcc-cross</code>, | ||
88 | the C library, and other pieces needed to finish building the | ||
89 | final cross-compiler in later stages. | ||
90 | This tool is a "native" package (i.e. it is designed to run on | ||
91 | the build host). | ||
92 | </p></li> | ||
93 | <li class="listitem"><p> | ||
94 | <code class="filename">linux-libc-headers</code>: | ||
95 | Headers needed for the cross-compiler. | ||
96 | </p></li> | ||
97 | <li class="listitem"><p> | ||
98 | <code class="filename">glibc-initial</code>: | ||
99 | An initial version of the Embedded GLIBC needed to bootstrap | ||
100 | <code class="filename">glibc</code>. | ||
101 | </p></li> | ||
102 | <li class="listitem"> | ||
103 | <p> | ||
104 | <code class="filename">gcc-cross</code>: | ||
105 | The final stage of the bootstrap process for the | ||
106 | cross-compiler. | ||
107 | This stage results in the actual cross-compiler that | ||
108 | BitBake uses when it builds an image for a targeted | ||
109 | device. | ||
110 | </p> | ||
111 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
112 | <h3 class="title">Note</h3> | ||
113 | If you are replacing this cross compiler toolchain | ||
114 | with a custom version, you must replace | ||
115 | <code class="filename">gcc-cross</code>. | ||
116 | </div> | ||
117 | <p> | ||
118 | This tool is also a "native" package (i.e. it is | ||
119 | designed to run on the build host). | ||
120 | </p> | ||
121 | </li> | ||
122 | <li class="listitem"><p> | ||
123 | <code class="filename">gcc-runtime</code>: | ||
124 | Runtime libraries resulting from the toolchain bootstrapping | ||
125 | process. | ||
126 | This tool produces a binary that consists of the | ||
127 | runtime libraries need for the targeted device. | ||
128 | </p></li> | ||
129 | </ul></div> | ||
130 | <p> | ||
131 | </p> | ||
132 | <p> | ||
133 | You can use the OpenEmbedded build system to build an installer for | ||
134 | the relocatable SDK used to develop applications. | ||
135 | When you run the installer, it installs the toolchain, which contains | ||
136 | the development tools (e.g., the | ||
137 | <code class="filename">gcc-cross-canadian</code>), | ||
138 | <code class="filename">binutils-cross-canadian</code>, and other | ||
139 | <code class="filename">nativesdk-*</code> tools, | ||
140 | which are tools native to the SDK (i.e. native to | ||
141 | <a class="link" href="../ref-manual/var-SDK_ARCH.html" target="_self"><code class="filename">SDK_ARCH</code></a>), | ||
142 | you need to cross-compile and test your software. | ||
143 | The figure shows the commands you use to easily build out this | ||
144 | toolchain. | ||
145 | This cross-development toolchain is built to execute on the | ||
146 | <a class="link" href="../ref-manual/var-SDKMACHINE.html" target="_self"><code class="filename">SDKMACHINE</code></a>, | ||
147 | which might or might not be the same | ||
148 | machine as the Build Host. | ||
149 | </p> | ||
150 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
151 | <h3 class="title">Note</h3> | ||
152 | If your target architecture is supported by the Yocto Project, | ||
153 | you can take advantage of pre-built images that ship with the | ||
154 | Yocto Project and already contain cross-development toolchain | ||
155 | installers. | ||
156 | </div> | ||
157 | <p> | ||
158 | </p> | ||
159 | <p> | ||
160 | Here is the bootstrap process for the relocatable toolchain: | ||
161 | </p> | ||
162 | <pre class="literallayout"> | ||
163 | gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> | ||
164 | glibc-initial -> nativesdk-glibc -> gcc-crosssdk -> gcc-cross-canadian | ||
165 | </pre> | ||
166 | <p> | ||
167 | </p> | ||
168 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
169 | <li class="listitem"><p> | ||
170 | <code class="filename">gcc</code>: | ||
171 | The build host's GNU Compiler Collection (GCC). | ||
172 | </p></li> | ||
173 | <li class="listitem"><p> | ||
174 | <code class="filename">binutils-crosssdk</code>: | ||
175 | The bare minimum binary utilities needed in order to run | ||
176 | the <code class="filename">gcc-crosssdk-initial</code> phase of the | ||
177 | bootstrap operation. | ||
178 | </p></li> | ||
179 | <li class="listitem"><p> | ||
180 | <code class="filename">gcc-crosssdk-initial</code>: | ||
181 | An early stage of the bootstrap process for creating | ||
182 | the cross-compiler. | ||
183 | This stage builds enough of the | ||
184 | <code class="filename">gcc-crosssdk</code> and supporting pieces so that | ||
185 | the final stage of the bootstrap process can produce the | ||
186 | finished cross-compiler. | ||
187 | This tool is a "native" binary that runs on the build host. | ||
188 | </p></li> | ||
189 | <li class="listitem"><p> | ||
190 | <code class="filename">linux-libc-headers</code>: | ||
191 | Headers needed for the cross-compiler. | ||
192 | </p></li> | ||
193 | <li class="listitem"><p> | ||
194 | <code class="filename">glibc-initial</code>: | ||
195 | An initial version of the Embedded GLIBC needed to bootstrap | ||
196 | <code class="filename">nativesdk-glibc</code>. | ||
197 | </p></li> | ||
198 | <li class="listitem"><p> | ||
199 | <code class="filename">nativesdk-glibc</code>: | ||
200 | The Embedded GLIBC needed to bootstrap the | ||
201 | <code class="filename">gcc-crosssdk</code>. | ||
202 | </p></li> | ||
203 | <li class="listitem"><p> | ||
204 | <code class="filename">gcc-crosssdk</code>: | ||
205 | The final stage of the bootstrap process for the | ||
206 | relocatable cross-compiler. | ||
207 | The <code class="filename">gcc-crosssdk</code> is a transitory compiler | ||
208 | and never leaves the build host. | ||
209 | Its purpose is to help in the bootstrap process to create the | ||
210 | eventual relocatable <code class="filename">gcc-cross-canadian</code> | ||
211 | compiler, which is relocatable. | ||
212 | This tool is also a "native" package (i.e. it is | ||
213 | designed to run on the build host). | ||
214 | </p></li> | ||
215 | <li class="listitem"><p> | ||
216 | <code class="filename">gcc-cross-canadian</code>: | ||
217 | The final relocatable cross-compiler. | ||
218 | When run on the | ||
219 | <a class="link" href="../ref-manual/var-SDKMACHINE.html" target="_self"><code class="filename">SDKMACHINE</code></a>, | ||
220 | this tool | ||
221 | produces executable code that runs on the target device. | ||
222 | Only one cross-canadian compiler is produced per architecture | ||
223 | since they can be targeted at different processor optimizations | ||
224 | using configurations passed to the compiler through the | ||
225 | compile commands. | ||
226 | This circumvents the need for multiple compilers and thus | ||
227 | reduces the size of the toolchains. | ||
228 | </p></li> | ||
229 | </ul></div> | ||
230 | <p> | ||
231 | </p> | ||
232 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
233 | <h3 class="title">Note</h3> | ||
234 | For information on advantages gained when building a | ||
235 | cross-development toolchain installer, see the | ||
236 | "<a class="link" href="../sdk-manual/sdk-building-an-sdk-installer.html" target="_self">Building an SDK Installer</a>" | ||
237 | section in the Yocto Project Application Development and the | ||
238 | Extensible Software Development Kit (eSDK) manual. | ||
239 | </div> | ||
240 | </div></body> | ||
241 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/development-concepts.html b/documentation/getting-started/eclipse/html/getting-started/development-concepts.html deleted file mode 100644 index ccfb73189a..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/development-concepts.html +++ /dev/null | |||
@@ -1,66 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8. Development Concepts</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-development-environment.html" title="Chapter 2. The Yocto Project Development Environment"> | ||
9 | <link rel="prev" href="recipe-syntax.html" title="2.7. Recipe Syntax"> | ||
10 | <link rel="next" href="user-configuration.html" title="2.8.1. User Configuration"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8. Development Concepts"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="development-concepts"></a>2.8. Development Concepts</h2></div></div></div> | ||
15 | <p> | ||
16 | This section takes a more detailed look inside the development | ||
17 | process. | ||
18 | The following diagram represents development at a high level. | ||
19 | The remainder of this chapter expands on the fundamental input, output, | ||
20 | process, and | ||
21 | <a class="link" href="../ref-manual/metadata.html" target="_self">Metadata</a>) blocks | ||
22 | that make up development in the Yocto Project environment. | ||
23 | </p> | ||
24 | <p><a name="general-yocto-environment-figure"></a> | ||
25 | </p> | ||
26 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 383px"><td align="center"><img src="figures/yocto-environment-ref.png" align="middle" height="383"></td></tr></table> | ||
27 | <p> | ||
28 | </p> | ||
29 | <p> | ||
30 | In general, development consists of several functional areas: | ||
31 | </p> | ||
32 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
33 | <li class="listitem"><p><span class="emphasis"><em>User Configuration:</em></span> | ||
34 | Metadata you can use to control the build process. | ||
35 | </p></li> | ||
36 | <li class="listitem"><p><span class="emphasis"><em>Metadata Layers:</em></span> | ||
37 | Various layers that provide software, machine, and | ||
38 | distro Metadata.</p></li> | ||
39 | <li class="listitem"><p><span class="emphasis"><em>Source Files:</em></span> | ||
40 | Upstream releases, local projects, and SCMs.</p></li> | ||
41 | <li class="listitem"><p><span class="emphasis"><em>Build System:</em></span> | ||
42 | Processes under the control of | ||
43 | <a class="link" href="../ref-manual/bitbake-term.html" target="_self">BitBake</a>. | ||
44 | This block expands on how BitBake fetches source, applies | ||
45 | patches, completes compilation, analyzes output for package | ||
46 | generation, creates and tests packages, generates images, and | ||
47 | generates cross-development tools.</p></li> | ||
48 | <li class="listitem"><p><span class="emphasis"><em>Package Feeds:</em></span> | ||
49 | Directories containing output packages (RPM, DEB or IPK), | ||
50 | which are subsequently used in the construction of an image or | ||
51 | SDK, produced by the build system. | ||
52 | These feeds can also be copied and shared using a web server or | ||
53 | other means to facilitate extending or updating existing | ||
54 | images on devices at runtime if runtime package management is | ||
55 | enabled.</p></li> | ||
56 | <li class="listitem"><p><span class="emphasis"><em>Images:</em></span> | ||
57 | Images produced by the development process. | ||
58 | </p></li> | ||
59 | <li class="listitem"><p><span class="emphasis"><em>Application Development SDK:</em></span> | ||
60 | Cross-development tools that are produced along with an image | ||
61 | or separately with BitBake.</p></li> | ||
62 | </ul></div> | ||
63 | <p> | ||
64 | </p> | ||
65 | </div></body> | ||
66 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/distro-layer.html b/documentation/getting-started/eclipse/html/getting-started/distro-layer.html deleted file mode 100644 index da6da55986..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/distro-layer.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>2.8.2.1. Distro Layer</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="metadata-machine-configuration-and-policy-configuration.html" title="2.8.2. Metadata, Machine Configuration, and Policy Configuration"> | ||
9 | <link rel="prev" href="metadata-machine-configuration-and-policy-configuration.html" title="2.8.2. Metadata, Machine Configuration, and Policy Configuration"> | ||
10 | <link rel="next" href="bsp-layer.html" title="2.8.2.2. BSP Layer"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.2.1. Distro Layer"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="distro-layer"></a>2.8.2.1. Distro Layer</h4></div></div></div> | ||
15 | <p> | ||
16 | The distribution layer provides policy configurations for your | ||
17 | distribution. | ||
18 | Best practices dictate that you isolate these types of | ||
19 | configurations into their own layer. | ||
20 | Settings you provide in | ||
21 | <code class="filename">conf/distro/<em class="replaceable"><code>distro</code></em>.conf</code> override | ||
22 | similar | ||
23 | settings that BitBake finds in your | ||
24 | <code class="filename">conf/local.conf</code> file in the Build | ||
25 | Directory. | ||
26 | </p> | ||
27 | <p> | ||
28 | The following list provides some explanation and references | ||
29 | for what you typically find in the distribution layer: | ||
30 | </p> | ||
31 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
32 | <li class="listitem"><p><span class="emphasis"><em>classes:</em></span> | ||
33 | Class files (<code class="filename">.bbclass</code>) hold | ||
34 | common functionality that can be shared among | ||
35 | recipes in the distribution. | ||
36 | When your recipes inherit a class, they take on the | ||
37 | settings and functions for that class. | ||
38 | You can read more about class files in the | ||
39 | "<a class="link" href="../ref-manual/ref-classes.html" target="_self">Classes</a>" | ||
40 | section of the Yocto Reference Manual. | ||
41 | </p></li> | ||
42 | <li class="listitem"><p><span class="emphasis"><em>conf:</em></span> | ||
43 | This area holds configuration files for the | ||
44 | layer (<code class="filename">conf/layer.conf</code>), | ||
45 | the distribution | ||
46 | (<code class="filename">conf/distro/<em class="replaceable"><code>distro</code></em>.conf</code>), | ||
47 | and any distribution-wide include files. | ||
48 | </p></li> | ||
49 | <li class="listitem"><p><span class="emphasis"><em>recipes-*:</em></span> | ||
50 | Recipes and append files that affect common | ||
51 | functionality across the distribution. | ||
52 | This area could include recipes and append files | ||
53 | to add distribution-specific configuration, | ||
54 | initialization scripts, custom image recipes, | ||
55 | and so forth.</p></li> | ||
56 | </ul></div> | ||
57 | <p> | ||
58 | </p> | ||
59 | </div></body> | ||
60 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/enable-building.html b/documentation/getting-started/eclipse/html/getting-started/enable-building.html deleted file mode 100644 index af70491f97..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/enable-building.html +++ /dev/null | |||
@@ -1,37 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.6.2.1. Building</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="enabling-wayland-in-an-image.html" title="3.6.2. Enabling Wayland in an Image"> | ||
9 | <link rel="prev" href="enabling-wayland-in-an-image.html" title="3.6.2. Enabling Wayland in an Image"> | ||
10 | <link rel="next" href="enable-installation-in-an-image.html" title="3.6.2.2. Installing"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.2.1. Building"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="enable-building"></a>3.6.2.1. Building</h4></div></div></div> | ||
15 | <p> | ||
16 | To cause Mesa to build the <code class="filename">wayland-egl</code> | ||
17 | platform and Weston to build Wayland with Kernel Mode | ||
18 | Setting | ||
19 | (<a class="ulink" href="https://wiki.archlinux.org/index.php/Kernel_Mode_Setting" target="_self">KMS</a>) | ||
20 | support, include the "wayland" flag in the | ||
21 | <a class="link" href="../ref-manual/var-DISTRO_FEATURES.html" target="_self"><code class="filename">DISTRO_FEATURES</code></a> | ||
22 | statement in your <code class="filename">local.conf</code> file: | ||
23 | </p> | ||
24 | <pre class="literallayout"> | ||
25 | DISTRO_FEATURES_append = " wayland" | ||
26 | </pre> | ||
27 | <p> | ||
28 | </p> | ||
29 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
30 | <h3 class="title">Note</h3> | ||
31 | If X11 has been enabled elsewhere, Weston will build | ||
32 | Wayland with X11 support | ||
33 | </div> | ||
34 | <p> | ||
35 | </p> | ||
36 | </div></body> | ||
37 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/enable-installation-in-an-image.html b/documentation/getting-started/eclipse/html/getting-started/enable-installation-in-an-image.html deleted file mode 100644 index 490f1d1036..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/enable-installation-in-an-image.html +++ /dev/null | |||
@@ -1,27 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.6.2.2. Installing</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="enabling-wayland-in-an-image.html" title="3.6.2. Enabling Wayland in an Image"> | ||
9 | <link rel="prev" href="enable-building.html" title="3.6.2.1. Building"> | ||
10 | <link rel="next" href="running-weston.html" title="3.6.3. Running Weston"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.2.2. Installing"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="enable-installation-in-an-image"></a>3.6.2.2. Installing</h4></div></div></div> | ||
15 | <p> | ||
16 | To install the Wayland feature into an image, you must | ||
17 | include the following | ||
18 | <a class="link" href="../ref-manual/var-CORE_IMAGE_EXTRA_INSTALL.html" target="_self"><code class="filename">CORE_IMAGE_EXTRA_INSTALL</code></a> | ||
19 | statement in your <code class="filename">local.conf</code> file: | ||
20 | </p> | ||
21 | <pre class="literallayout"> | ||
22 | CORE_IMAGE_EXTRA_INSTALL += "wayland weston" | ||
23 | </pre> | ||
24 | <p> | ||
25 | </p> | ||
26 | </div></body> | ||
27 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/enabling-commercially-licensed-recipes.html b/documentation/getting-started/eclipse/html/getting-started/enabling-commercially-licensed-recipes.html deleted file mode 100644 index 1a31d0e6b1..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/enabling-commercially-licensed-recipes.html +++ /dev/null | |||
@@ -1,91 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.7.2. Enabling Commercially Licensed Recipes</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-licenses.html" title="3.7. Licenses"> | ||
9 | <link rel="prev" href="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html" title="3.7.1.2. Explanation of Syntax"> | ||
10 | <link rel="next" href="license-flag-matching.html" title="3.7.2.1. License Flag Matching"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.2. Enabling Commercially Licensed Recipes"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="enabling-commercially-licensed-recipes"></a>3.7.2. Enabling Commercially Licensed Recipes</h3></div></div></div> | ||
15 | <p> | ||
16 | By default, the OpenEmbedded build system disables | ||
17 | components that have commercial or other special licensing | ||
18 | requirements. | ||
19 | Such requirements are defined on a | ||
20 | recipe-by-recipe basis through the | ||
21 | <a class="link" href="../ref-manual/var-LICENSE_FLAGS.html" target="_self"><code class="filename">LICENSE_FLAGS</code></a> | ||
22 | variable definition in the affected recipe. | ||
23 | For instance, the | ||
24 | <code class="filename">poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</code> | ||
25 | recipe contains the following statement: | ||
26 | </p> | ||
27 | <pre class="literallayout"> | ||
28 | LICENSE_FLAGS = "commercial" | ||
29 | </pre> | ||
30 | <p> | ||
31 | Here is a slightly more complicated example that contains both | ||
32 | an explicit recipe name and version (after variable expansion): | ||
33 | </p> | ||
34 | <pre class="literallayout"> | ||
35 | LICENSE_FLAGS = "license_${PN}_${PV}" | ||
36 | </pre> | ||
37 | <p> | ||
38 | In order for a component restricted by a | ||
39 | <code class="filename">LICENSE_FLAGS</code> definition to be enabled and | ||
40 | included in an image, it needs to have a matching entry in the | ||
41 | global | ||
42 | <a class="link" href="../ref-manual/var-LICENSE_FLAGS_WHITELIST.html" target="_self"><code class="filename">LICENSE_FLAGS_WHITELIST</code></a> | ||
43 | variable, which is a variable typically defined in your | ||
44 | <code class="filename">local.conf</code> file. | ||
45 | For example, to enable the | ||
46 | <code class="filename">poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</code> | ||
47 | package, you could add either the string | ||
48 | "commercial_gst-plugins-ugly" or the more general string | ||
49 | "commercial" to <code class="filename">LICENSE_FLAGS_WHITELIST</code>. | ||
50 | See the | ||
51 | "<a class="link" href="license-flag-matching.html" title="3.7.2.1. License Flag Matching">License Flag Matching</a>" | ||
52 | section for a full | ||
53 | explanation of how <code class="filename">LICENSE_FLAGS</code> matching | ||
54 | works. | ||
55 | Here is the example: | ||
56 | </p> | ||
57 | <pre class="literallayout"> | ||
58 | LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly" | ||
59 | </pre> | ||
60 | <p> | ||
61 | Likewise, to additionally enable the package built from the | ||
62 | recipe containing | ||
63 | <code class="filename">LICENSE_FLAGS = "license_${PN}_${PV}"</code>, | ||
64 | and assuming that the actual recipe name was | ||
65 | <code class="filename">emgd_1.10.bb</code>, the following string would | ||
66 | enable that package as well as the original | ||
67 | <code class="filename">gst-plugins-ugly</code> package: | ||
68 | </p> | ||
69 | <pre class="literallayout"> | ||
70 | LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10" | ||
71 | </pre> | ||
72 | <p> | ||
73 | As a convenience, you do not need to specify the complete | ||
74 | license string in the whitelist for every package. | ||
75 | You can use an abbreviated form, which consists | ||
76 | of just the first portion or portions of the license | ||
77 | string before the initial underscore character or characters. | ||
78 | A partial string will match any license that contains the | ||
79 | given string as the first portion of its license. | ||
80 | For example, the following whitelist string will also match | ||
81 | both of the packages previously mentioned as well as any other | ||
82 | packages that have licenses starting with "commercial" or | ||
83 | "license". | ||
84 | </p> | ||
85 | <pre class="literallayout"> | ||
86 | LICENSE_FLAGS_WHITELIST = "commercial license" | ||
87 | </pre> | ||
88 | <p> | ||
89 | </p> | ||
90 | </div></body> | ||
91 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/enabling-wayland-in-an-image.html b/documentation/getting-started/eclipse/html/getting-started/enabling-wayland-in-an-image.html deleted file mode 100644 index 6a325dbfd2..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/enabling-wayland-in-an-image.html +++ /dev/null | |||
@@ -1,20 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.6.2. Enabling Wayland in an Image</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="wayland.html" title="3.6. Wayland"> | ||
9 | <link rel="prev" href="wayland-support.html" title="3.6.1. Support"> | ||
10 | <link rel="next" href="enable-building.html" title="3.6.2.1. Building"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.2. Enabling Wayland in an Image"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="enabling-wayland-in-an-image"></a>3.6.2. Enabling Wayland in an Image</h3></div></div></div> | ||
15 | <p> | ||
16 | To enable Wayland, you need to enable it to be built and enable | ||
17 | it to be included in the image. | ||
18 | </p> | ||
19 | </div></body> | ||
20 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/fakeroot-and-pseudo.html b/documentation/getting-started/eclipse/html/getting-started/fakeroot-and-pseudo.html deleted file mode 100644 index 8354ad6730..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/fakeroot-and-pseudo.html +++ /dev/null | |||
@@ -1,91 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.5. Fakeroot and Pseudo</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="automatically-added-runtime-dependencies.html" title="3.4. Automatically Added Runtime Dependencies"> | ||
10 | <link rel="next" href="wayland.html" title="3.6. Wayland"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.5. Fakeroot and Pseudo"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="fakeroot-and-pseudo"></a>3.5. Fakeroot and Pseudo</h2></div></div></div> | ||
15 | <p> | ||
16 | Some tasks are easier to implement when allowed to perform certain | ||
17 | operations that are normally reserved for the root user (e.g. | ||
18 | <a class="link" href="../ref-manual/ref-tasks-install.html" target="_self"><code class="filename">do_install</code></a>, | ||
19 | <a class="link" href="../ref-manual/ref-tasks-package_write_deb.html" target="_self"><code class="filename">do_package_write*</code></a>, | ||
20 | <a class="link" href="../ref-manual/ref-tasks-rootfs.html" target="_self"><code class="filename">do_rootfs</code></a>, | ||
21 | and | ||
22 | <a class="link" href="../ref-manual/ref-tasks-image.html" target="_self"><code class="filename">do_image*</code></a>). | ||
23 | For example, the <code class="filename">do_install</code> task benefits | ||
24 | from being able to set the UID and GID of installed files to | ||
25 | arbitrary values. | ||
26 | </p> | ||
27 | <p> | ||
28 | One approach to allowing tasks to perform root-only operations | ||
29 | would be to require BitBake to run as root. | ||
30 | However, this method is cumbersome and has security issues. | ||
31 | The approach that is actually used is to run tasks that benefit | ||
32 | from root privileges in a "fake" root environment. | ||
33 | Within this environment, the task and its child processes believe | ||
34 | that they are running as the root user, and see an internally | ||
35 | consistent view of the filesystem. | ||
36 | As long as generating the final output (e.g. a package or an image) | ||
37 | does not require root privileges, the fact that some earlier | ||
38 | steps ran in a fake root environment does not cause problems. | ||
39 | </p> | ||
40 | <p> | ||
41 | The capability to run tasks in a fake root environment is known as | ||
42 | "<a class="ulink" href="http://man.he.net/man1/fakeroot" target="_self">fakeroot</a>", | ||
43 | which is derived from the BitBake keyword/variable | ||
44 | flag that requests a fake root environment for a task. | ||
45 | </p> | ||
46 | <p> | ||
47 | In the OpenEmbedded build system, the program that implements | ||
48 | fakeroot is known as Pseudo. | ||
49 | Pseudo overrides system calls by using the environment variable | ||
50 | <code class="filename">LD_PRELOAD</code>, which results in the illusion | ||
51 | of running as root. | ||
52 | To keep track of "fake" file ownership and permissions resulting | ||
53 | from operations that require root permissions, Pseudo uses | ||
54 | an SQLite 3 database. | ||
55 | This database is stored in | ||
56 | <code class="filename">${</code><a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a><code class="filename">}/pseudo/files.db</code> | ||
57 | for individual recipes. | ||
58 | Storing the database in a file as opposed to in memory | ||
59 | gives persistence between tasks and builds, which is not | ||
60 | accomplished using fakeroot. | ||
61 | </p> | ||
62 | <div class="note" title="Caution" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
63 | <h3 class="title">Caution</h3> | ||
64 | If you add your own task that manipulates the same files or | ||
65 | directories as a fakeroot task, then that task also needs to | ||
66 | run under fakeroot. | ||
67 | Otherwise, the task cannot run root-only operations, and | ||
68 | cannot see the fake file ownership and permissions set by the | ||
69 | other task. | ||
70 | You need to also add a dependency on | ||
71 | <code class="filename">virtual/fakeroot-native:do_populate_sysroot</code>, | ||
72 | giving the following: | ||
73 | <pre class="literallayout"> | ||
74 | fakeroot do_mytask () { | ||
75 | ... | ||
76 | } | ||
77 | do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot" | ||
78 | </pre> | ||
79 | </div> | ||
80 | <p> | ||
81 | For more information, see the | ||
82 | <a class="link" href="../bitbake-user-manual/var-FAKEROOT.html" target="_self"><code class="filename">FAKEROOT*</code></a> | ||
83 | variables in the BitBake User Manual. | ||
84 | You can also reference the | ||
85 | "<a class="ulink" href="http://www.ibm.com/developerworks/opensource/library/os-aapseudo1/index.html" target="_self">Pseudo</a>" | ||
86 | and | ||
87 | "<a class="ulink" href="https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot" target="_self">Why Not Fakeroot?</a>" | ||
88 | articles for background information on Pseudo. | ||
89 | </p> | ||
90 | </div></body> | ||
91 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/YP-flow-diagram.png b/documentation/getting-started/eclipse/html/getting-started/figures/YP-flow-diagram.png deleted file mode 100644 index 8264410504..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/YP-flow-diagram.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/analysis-for-package-splitting.png b/documentation/getting-started/eclipse/html/getting-started/figures/analysis-for-package-splitting.png deleted file mode 100644 index 04f2794ea9..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/analysis-for-package-splitting.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/configuration-compile-autoreconf.png b/documentation/getting-started/eclipse/html/getting-started/figures/configuration-compile-autoreconf.png deleted file mode 100644 index a07464f04c..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/configuration-compile-autoreconf.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/cross-development-toolchains.png b/documentation/getting-started/eclipse/html/getting-started/figures/cross-development-toolchains.png deleted file mode 100644 index d36670a198..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/cross-development-toolchains.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/getting-started-title.png b/documentation/getting-started/eclipse/html/getting-started/figures/getting-started-title.png deleted file mode 100644 index f38b078ab7..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/getting-started-title.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/git-workflow.png b/documentation/getting-started/eclipse/html/getting-started/figures/git-workflow.png deleted file mode 100644 index e401330a12..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/git-workflow.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/image-generation.png b/documentation/getting-started/eclipse/html/getting-started/figures/image-generation.png deleted file mode 100644 index 71a48dc6f4..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/image-generation.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/images.png b/documentation/getting-started/eclipse/html/getting-started/figures/images.png deleted file mode 100644 index d99eac1fbf..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/images.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/index-downloads.png b/documentation/getting-started/eclipse/html/getting-started/figures/index-downloads.png deleted file mode 100644 index 96303b8781..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/index-downloads.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/layer-input.png b/documentation/getting-started/eclipse/html/getting-started/figures/layer-input.png deleted file mode 100644 index 0a4f2e74f3..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/layer-input.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/package-feeds.png b/documentation/getting-started/eclipse/html/getting-started/figures/package-feeds.png deleted file mode 100644 index 37c9c32506..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/package-feeds.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/patching.png b/documentation/getting-started/eclipse/html/getting-started/figures/patching.png deleted file mode 100644 index 8ecd018502..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/patching.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/sdk-generation.png b/documentation/getting-started/eclipse/html/getting-started/figures/sdk-generation.png deleted file mode 100755 index adbe1f4acf..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/sdk-generation.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/sdk.png b/documentation/getting-started/eclipse/html/getting-started/figures/sdk.png deleted file mode 100644 index 5c36b7548b..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/sdk.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/source-fetching.png b/documentation/getting-started/eclipse/html/getting-started/figures/source-fetching.png deleted file mode 100644 index 26aefb50c2..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/source-fetching.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/source-input.png b/documentation/getting-started/eclipse/html/getting-started/figures/source-input.png deleted file mode 100644 index f7515058ef..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/source-input.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/source-repos.png b/documentation/getting-started/eclipse/html/getting-started/figures/source-repos.png deleted file mode 100644 index 603300b6d2..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/source-repos.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/user-configuration.png b/documentation/getting-started/eclipse/html/getting-started/figures/user-configuration.png deleted file mode 100644 index c298401fc3..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/user-configuration.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/yocto-environment-ref.png b/documentation/getting-started/eclipse/html/getting-started/figures/yocto-environment-ref.png deleted file mode 100644 index 650c6c8030..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/yocto-environment-ref.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/figures/yp-download.png b/documentation/getting-started/eclipse/html/getting-started/figures/yp-download.png deleted file mode 100644 index 5770be6883..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/figures/yp-download.png +++ /dev/null | |||
Binary files differ | |||
diff --git a/documentation/getting-started/eclipse/html/getting-started/git.html b/documentation/getting-started/eclipse/html/getting-started/git.html deleted file mode 100644 index 7e652a4efa..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/git.html +++ /dev/null | |||
@@ -1,51 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.4. Git</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-development-environment.html" title="Chapter 2. The Yocto Project Development Environment"> | ||
9 | <link rel="prev" href="workflows.html" title="2.3. Workflows"> | ||
10 | <link rel="next" href="repositories-tags-and-branches.html" title="2.4.1. Repositories, Tags, and Branches"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4. Git"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="git"></a>2.4. Git</h2></div></div></div> | ||
15 | <p> | ||
16 | The Yocto Project makes extensive use of Git, which is a | ||
17 | free, open source distributed version control system. | ||
18 | Git supports distributed development, non-linear development, | ||
19 | and can handle large projects. | ||
20 | It is best that you have some fundamental understanding | ||
21 | of how Git tracks projects and how to work with Git if | ||
22 | you are going to use the Yocto Project for development. | ||
23 | This section provides a quick overview of how Git works and | ||
24 | provides you with a summary of some essential Git commands. | ||
25 | </p> | ||
26 | <div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
27 | <h3 class="title">Notes</h3> | ||
28 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
29 | <li class="listitem"><p> | ||
30 | For more information on Git, see | ||
31 | <a class="ulink" href="http://git-scm.com/documentation" target="_self">http://git-scm.com/documentation</a>. | ||
32 | </p></li> | ||
33 | <li class="listitem"><p> | ||
34 | If you need to download Git, it is recommended that you add | ||
35 | Git to your system through your distribution's "software | ||
36 | store" (e.g. for Ubuntu, use the Ubuntu Software feature). | ||
37 | For the Git download page, see | ||
38 | <a class="ulink" href="http://git-scm.com/download" target="_self">http://git-scm.com/download</a>. | ||
39 | </p></li> | ||
40 | <li class="listitem"><p> | ||
41 | For examples beyond the limited few in this section on how | ||
42 | to use Git with the Yocto Project, see the | ||
43 | "<a class="link" href="../dev-manual/working-with-yocto-project-source-files.html" target="_self">Working With Yocto Project Source Files</a>" | ||
44 | section in the Yocto Project Development Tasks Manual. | ||
45 | </p></li> | ||
46 | </ul></div> | ||
47 | </div> | ||
48 | <p> | ||
49 | </p> | ||
50 | </div></body> | ||
51 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/image-generation-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/image-generation-dev-environment.html deleted file mode 100644 index 9f682d082c..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/image-generation-dev-environment.html +++ /dev/null | |||
@@ -1,178 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.5.5. Image Generation</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="package-splitting-dev-environment.html" title="2.8.5.4. Package Splitting"> | ||
10 | <link rel="next" href="sdk-generation-dev-environment.html" title="2.8.5.6. SDK Generation"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.5. Image Generation"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="image-generation-dev-environment"></a>2.8.5.5. Image Generation</h4></div></div></div> | ||
15 | <p> | ||
16 | Once packages are split and stored in the Package Feeds area, | ||
17 | the OpenEmbedded build system uses BitBake to generate the | ||
18 | root filesystem image: | ||
19 | </p> | ||
20 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 630px"><td align="center"><img src="figures/image-generation.png" align="middle" width="540"></td></tr></table> | ||
21 | <p> | ||
22 | </p> | ||
23 | <p> | ||
24 | The image generation process consists of several stages and | ||
25 | depends on several tasks and variables. | ||
26 | The | ||
27 | <a class="link" href="../ref-manual/ref-tasks-rootfs.html" target="_self"><code class="filename">do_rootfs</code></a> | ||
28 | task creates the root filesystem (file and directory structure) | ||
29 | for an image. | ||
30 | This task uses several key variables to help create the list | ||
31 | of packages to actually install: | ||
32 | </p> | ||
33 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
34 | <li class="listitem"><p><a class="link" href="../ref-manual/var-IMAGE_INSTALL.html" target="_self"><code class="filename">IMAGE_INSTALL</code></a>: | ||
35 | Lists out the base set of packages to install from | ||
36 | the Package Feeds area.</p></li> | ||
37 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PACKAGE_EXCLUDE.html" target="_self"><code class="filename">PACKAGE_EXCLUDE</code></a>: | ||
38 | Specifies packages that should not be installed. | ||
39 | </p></li> | ||
40 | <li class="listitem"><p><a class="link" href="../ref-manual/var-IMAGE_FEATURES.html" target="_self"><code class="filename">IMAGE_FEATURES</code></a>: | ||
41 | Specifies features to include in the image. | ||
42 | Most of these features map to additional packages for | ||
43 | installation.</p></li> | ||
44 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PACKAGE_CLASSES.html" target="_self"><code class="filename">PACKAGE_CLASSES</code></a>: | ||
45 | Specifies the package backend to use and consequently | ||
46 | helps determine where to locate packages within the | ||
47 | Package Feeds area.</p></li> | ||
48 | <li class="listitem"><p><a class="link" href="../ref-manual/var-IMAGE_LINGUAS.html" target="_self"><code class="filename">IMAGE_LINGUAS</code></a>: | ||
49 | Determines the language(s) for which additional | ||
50 | language support packages are installed. | ||
51 | </p></li> | ||
52 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PACKAGE_INSTALL.html" target="_self"><code class="filename">PACKAGE_INSTALL</code></a>: | ||
53 | The final list of packages passed to the package manager | ||
54 | for installation into the image. | ||
55 | </p></li> | ||
56 | </ul></div> | ||
57 | <p> | ||
58 | </p> | ||
59 | <p> | ||
60 | With | ||
61 | <a class="link" href="../ref-manual/var-IMAGE_ROOTFS.html" target="_self"><code class="filename">IMAGE_ROOTFS</code></a> | ||
62 | pointing to the location of the filesystem under construction and | ||
63 | the <code class="filename">PACKAGE_INSTALL</code> variable providing the | ||
64 | final list of packages to install, the root file system is | ||
65 | created. | ||
66 | </p> | ||
67 | <p> | ||
68 | Package installation is under control of the package manager | ||
69 | (e.g. dnf/rpm, opkg, or apt/dpkg) regardless of whether or | ||
70 | not package management is enabled for the target. | ||
71 | At the end of the process, if package management is not | ||
72 | enabled for the target, the package manager's data files | ||
73 | are deleted from the root filesystem. | ||
74 | As part of the final stage of package installation, postinstall | ||
75 | scripts that are part of the packages are run. | ||
76 | Any scripts that fail to run | ||
77 | on the build host are run on the target when the target system | ||
78 | is first booted. | ||
79 | If you are using a | ||
80 | <a class="link" href="../dev-manual/creating-a-read-only-root-filesystem.html" target="_self">read-only root filesystem</a>, | ||
81 | all the post installation scripts must succeed during the | ||
82 | package installation phase since the root filesystem is | ||
83 | read-only. | ||
84 | </p> | ||
85 | <p> | ||
86 | The final stages of the <code class="filename">do_rootfs</code> task | ||
87 | handle post processing. | ||
88 | Post processing includes creation of a manifest file and | ||
89 | optimizations. | ||
90 | </p> | ||
91 | <p> | ||
92 | The manifest file (<code class="filename">.manifest</code>) resides | ||
93 | in the same directory as the root filesystem image. | ||
94 | This file lists out, line-by-line, the installed packages. | ||
95 | The manifest file is useful for the | ||
96 | <a class="link" href="../ref-manual/ref-classes-testimage*.html" target="_self"><code class="filename">testimage</code></a> | ||
97 | class, for example, to determine whether or not to run | ||
98 | specific tests. | ||
99 | See the | ||
100 | <a class="link" href="../ref-manual/var-IMAGE_MANIFEST.html" target="_self"><code class="filename">IMAGE_MANIFEST</code></a> | ||
101 | variable for additional information. | ||
102 | </p> | ||
103 | <p> | ||
104 | Optimizing processes run across the image include | ||
105 | <code class="filename">mklibs</code>, <code class="filename">prelink</code>, | ||
106 | and any other post-processing commands as defined by the | ||
107 | <a class="link" href="../ref-manual/var-ROOTFS_POSTPROCESS_COMMAND.html" target="_self"><code class="filename">ROOTFS_POSTPROCESS_COMMAND</code></a> | ||
108 | variable. | ||
109 | The <code class="filename">mklibs</code> process optimizes the size | ||
110 | of the libraries, while the | ||
111 | <code class="filename">prelink</code> process optimizes the dynamic | ||
112 | linking of shared libraries to reduce start up time of | ||
113 | executables. | ||
114 | </p> | ||
115 | <p> | ||
116 | After the root filesystem is built, processing begins on | ||
117 | the image through the | ||
118 | <a class="link" href="../ref-manual/ref-tasks-image.html" target="_self"><code class="filename">do_image</code></a> | ||
119 | task. | ||
120 | The build system runs any pre-processing commands as defined | ||
121 | by the | ||
122 | <a class="link" href="../ref-manual/var-IMAGE_PREPROCESS_COMMAND.html" target="_self"><code class="filename">IMAGE_PREPROCESS_COMMAND</code></a> | ||
123 | variable. | ||
124 | This variable specifies a list of functions to call before | ||
125 | the OpenEmbedded build system creates the final image output | ||
126 | files. | ||
127 | </p> | ||
128 | <p> | ||
129 | The OpenEmbedded build system dynamically creates | ||
130 | <code class="filename">do_image_*</code> tasks as needed, based | ||
131 | on the image types specified in the | ||
132 | <a class="link" href="../ref-manual/var-IMAGE_FSTYPES.html" target="_self"><code class="filename">IMAGE_FSTYPES</code></a> | ||
133 | variable. | ||
134 | The process turns everything into an image file or a set of | ||
135 | image files and compresses the root filesystem image to reduce | ||
136 | the overall size of the image. | ||
137 | The formats used for the root filesystem depend on the | ||
138 | <code class="filename">IMAGE_FSTYPES</code> variable. | ||
139 | </p> | ||
140 | <p> | ||
141 | As an example, a dynamically created task when creating a | ||
142 | particular image <em class="replaceable"><code>type</code></em> would take the | ||
143 | following form: | ||
144 | </p> | ||
145 | <pre class="literallayout"> | ||
146 | do_image_<em class="replaceable"><code>type</code></em>[depends] | ||
147 | </pre> | ||
148 | <p> | ||
149 | So, if the <em class="replaceable"><code>type</code></em> as specified by the | ||
150 | <code class="filename">IMAGE_FSTYPES</code> were | ||
151 | <code class="filename">ext4</code>, the dynamically generated task | ||
152 | would be as follows: | ||
153 | </p> | ||
154 | <pre class="literallayout"> | ||
155 | do_image_ext4[depends] | ||
156 | </pre> | ||
157 | <p> | ||
158 | </p> | ||
159 | <p> | ||
160 | The final task involved in image creation is the | ||
161 | <a class="link" href="../ref-manual/ref-tasks-image-complete.html" target="_self"><code class="filename">do_image_complete</code></a> | ||
162 | task. | ||
163 | This task completes the image by applying any image | ||
164 | post processing as defined through the | ||
165 | <a class="link" href="../ref-manual/var-IMAGE_POSTPROCESS_COMMAND.html" target="_self"><code class="filename">IMAGE_POSTPROCESS_COMMAND</code></a> | ||
166 | variable. | ||
167 | The variable specifies a list of functions to call once the | ||
168 | OpenEmbedded build system has created the final image output | ||
169 | files. | ||
170 | </p> | ||
171 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
172 | <h3 class="title">Note</h3> | ||
173 | The entire image generation process is run under Pseudo. | ||
174 | Running under Pseudo ensures that the files in the root | ||
175 | filesystem have correct ownership. | ||
176 | </div> | ||
177 | </div></body> | ||
178 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/images-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/images-dev-environment.html deleted file mode 100644 index 2561f1f4a6..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/images-dev-environment.html +++ /dev/null | |||
@@ -1,99 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.6. Images</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="development-concepts.html" title="2.8. Development Concepts"> | ||
9 | <link rel="prev" href="setscene-tasks-and-shared-state.html" title="2.8.5.8. Setscene Tasks and Shared State"> | ||
10 | <link rel="next" href="sdk-dev-environment.html" title="2.8.7. Application Development SDK"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.6. Images"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="images-dev-environment"></a>2.8.6. Images</h3></div></div></div> | ||
15 | <p> | ||
16 | The images produced by the OpenEmbedded build system | ||
17 | are compressed forms of the | ||
18 | root filesystem that are ready to boot on a target device. | ||
19 | You can see from the | ||
20 | <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a> | ||
21 | that BitBake output, in part, consists of images. | ||
22 | This section is going to look more closely at this output: | ||
23 | </p> | ||
24 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="495"><tr style="height: 495px"><td align="center"><img src="figures/images.png" align="middle" width="495"></td></tr></table> | ||
25 | <p> | ||
26 | </p> | ||
27 | <p> | ||
28 | For a list of example images that the Yocto Project provides, | ||
29 | see the | ||
30 | "<a class="link" href="../ref-manual/ref-images.html" target="_self">Images</a>" | ||
31 | chapter in the Yocto Project Reference Manual. | ||
32 | </p> | ||
33 | <p> | ||
34 | Images are written out to the | ||
35 | <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a> | ||
36 | inside the | ||
37 | <code class="filename">tmp/deploy/images/<em class="replaceable"><code>machine</code></em>/</code> | ||
38 | folder as shown in the figure. | ||
39 | This folder contains any files expected to be loaded on the | ||
40 | target device. | ||
41 | The | ||
42 | <a class="link" href="../ref-manual/var-DEPLOY_DIR.html" target="_self"><code class="filename">DEPLOY_DIR</code></a> | ||
43 | variable points to the <code class="filename">deploy</code> directory, | ||
44 | while the | ||
45 | <a class="link" href="../ref-manual/var-DEPLOY_DIR_IMAGE.html" target="_self"><code class="filename">DEPLOY_DIR_IMAGE</code></a> | ||
46 | variable points to the appropriate directory containing images for | ||
47 | the current configuration. | ||
48 | </p> | ||
49 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
50 | <li class="listitem"><p><code class="filename"><em class="replaceable"><code>kernel-image</code></em></code>: | ||
51 | A kernel binary file. | ||
52 | The | ||
53 | <a class="link" href="../ref-manual/var-KERNEL_IMAGETYPE.html" target="_self"><code class="filename">KERNEL_IMAGETYPE</code></a> | ||
54 | variable setting determines the naming scheme for the | ||
55 | kernel image file. | ||
56 | Depending on that variable, the file could begin with | ||
57 | a variety of naming strings. | ||
58 | The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code> | ||
59 | directory can contain multiple image files for the | ||
60 | machine.</p></li> | ||
61 | <li class="listitem"><p><code class="filename"><em class="replaceable"><code>root-filesystem-image</code></em></code>: | ||
62 | Root filesystems for the target device (e.g. | ||
63 | <code class="filename">*.ext3</code> or <code class="filename">*.bz2</code> | ||
64 | files). | ||
65 | The | ||
66 | <a class="link" href="../ref-manual/var-IMAGE_FSTYPES.html" target="_self"><code class="filename">IMAGE_FSTYPES</code></a> | ||
67 | variable setting determines the root filesystem image | ||
68 | type. | ||
69 | The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code> | ||
70 | directory can contain multiple root filesystems for the | ||
71 | machine.</p></li> | ||
72 | <li class="listitem"><p><code class="filename"><em class="replaceable"><code>kernel-modules</code></em></code>: | ||
73 | Tarballs that contain all the modules built for the kernel. | ||
74 | Kernel module tarballs exist for legacy purposes and | ||
75 | can be suppressed by setting the | ||
76 | <a class="link" href="../ref-manual/var-MODULE_TARBALL_DEPLOY.html" target="_self"><code class="filename">MODULE_TARBALL_DEPLOY</code></a> | ||
77 | variable to "0". | ||
78 | The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code> | ||
79 | directory can contain multiple kernel module tarballs | ||
80 | for the machine.</p></li> | ||
81 | <li class="listitem"><p><code class="filename"><em class="replaceable"><code>bootloaders</code></em></code>: | ||
82 | Bootloaders supporting the image, if applicable to the | ||
83 | target machine. | ||
84 | The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code> | ||
85 | directory can contain multiple bootloaders for the | ||
86 | machine.</p></li> | ||
87 | <li class="listitem"><p><code class="filename"><em class="replaceable"><code>symlinks</code></em></code>: | ||
88 | The <code class="filename">deploy/images/<em class="replaceable"><code>machine</code></em></code> | ||
89 | folder contains | ||
90 | a symbolic link that points to the most recently built file | ||
91 | for each machine. | ||
92 | These links might be useful for external scripts that | ||
93 | need to obtain the latest version of each file. | ||
94 | </p></li> | ||
95 | </ul></div> | ||
96 | <p> | ||
97 | </p> | ||
98 | </div></body> | ||
99 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/index.html b/documentation/getting-started/eclipse/html/getting-started/index.html deleted file mode 100644 index 94826ce0c6..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/index.html +++ /dev/null | |||
@@ -1,154 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>Getting Started With Yocto Project</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="next" href="overview-manual-intro.html" title="Chapter 1. The Yocto Project Overview Manual"> | ||
9 | </head> | ||
10 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div lang="en" class="book" title="Getting Started With Yocto Project"> | ||
11 | <div class="titlepage"> | ||
12 | <div> | ||
13 | <div><h1 class="title"> | ||
14 | <a name="getting-started-manual"></a> | ||
15 | Getting Started With Yocto Project | ||
16 | </h1></div> | ||
17 | <div><div class="authorgroup"> | ||
18 | <div class="author"> | ||
19 | <h3 class="author"> | ||
20 | <span class="firstname">Scott</span> <span class="surname">Rifenbark</span> | ||
21 | </h3> | ||
22 | <div class="affiliation"> | ||
23 | <span class="orgname">Scotty's Documentation Services, INC<br></span> | ||
24 | </div> | ||
25 | <code class="email"><<a class="email" href="mailto:srifenbark@gmail.com">srifenbark@gmail.com</a>></code> | ||
26 | </div> | ||
27 | </div></div> | ||
28 | <div><p class="copyright">Copyright © 2010-2018 Linux Foundation</p></div> | ||
29 | <div><div class="legalnotice" title="Legal Notice"> | ||
30 | <a name="idm45823191546992"></a> | ||
31 | <p> | ||
32 | Permission is granted to copy, distribute and/or modify this document under | ||
33 | the terms of the <a class="ulink" href="http://creativecommons.org/licenses/by-sa/2.0/uk/" target="_self"> | ||
34 | Creative Commons Attribution-Share Alike 2.0 UK: England & Wales</a> as published by | ||
35 | Creative Commons. | ||
36 | </p> | ||
37 | <div class="note" title="Manual Notes" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
38 | <h3 class="title">Manual Notes</h3> | ||
39 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
40 | <li class="listitem"><p> | ||
41 | This version of the | ||
42 | <span class="emphasis"><em>Yocto Project Overview Manual</em></span> | ||
43 | is for the 2.5 release of the | ||
44 | Yocto Project. | ||
45 | To be sure you have the latest version of the manual | ||
46 | for this release, use the manual from the | ||
47 | <a class="ulink" href="http://www.yoctoproject.org/documentation" target="_self">Yocto Project documentation page</a>. | ||
48 | </p></li> | ||
49 | <li class="listitem"><p> | ||
50 | For manuals associated with other releases of the Yocto | ||
51 | Project, go to the | ||
52 | <a class="ulink" href="http://www.yoctoproject.org/documentation" target="_self">Yocto Project documentation page</a> | ||
53 | and use the drop-down "Active Releases" button | ||
54 | and choose the manual associated with the desired | ||
55 | Yocto Project. | ||
56 | </p></li> | ||
57 | <li class="listitem"><p> | ||
58 | To report any inaccuracies or problems with this | ||
59 | manual, send an email to the Yocto Project | ||
60 | discussion group at | ||
61 | <code class="filename">yocto@yoctoproject.com</code> or log into | ||
62 | the freenode <code class="filename">#yocto</code> channel. | ||
63 | </p></li> | ||
64 | </ul></div> | ||
65 | </div> | ||
66 | </div></div> | ||
67 | <div><div class="revhistory"><table border="1" width="100%" summary="Revision history"> | ||
68 | <tr><th align="left" valign="top" colspan="2"><b>Revision History</b></th></tr> | ||
69 | <tr> | ||
70 | <td align="left">Revision 2.5</td> | ||
71 | <td align="left">April 2018</td> | ||
72 | </tr> | ||
73 | <tr><td align="left" colspan="2">The initial document released with the Yocto Project 2.5 Release.</td></tr> | ||
74 | </table></div></div> | ||
75 | </div> | ||
76 | <hr> | ||
77 | </div> | ||
78 | <div class="toc"> | ||
79 | <p><b>Table of Contents</b></p> | ||
80 | <dl> | ||
81 | <dt><span class="chapter"><a href="overview-manual-intro.html">1. The Yocto Project Overview Manual</a></span></dt> | ||
82 | <dd><dl> | ||
83 | <dt><span class="section"><a href="overview-welcome.html">1.1. Welcome</a></span></dt> | ||
84 | <dt><span class="section"><a href="overview-other-information.html">1.2. Other Information</a></span></dt> | ||
85 | </dl></dd> | ||
86 | <dt><span class="chapter"><a href="overview-development-environment.html">2. The Yocto Project Development Environment</a></span></dt> | ||
87 | <dd><dl> | ||
88 | <dt><span class="section"><a href="yp-intro.html">2.1. Introduction</a></span></dt> | ||
89 | <dt><span class="section"><a href="open-source-philosophy.html">2.2. Open Source Philosophy</a></span></dt> | ||
90 | <dt><span class="section"><a href="workflows.html">2.3. Workflows</a></span></dt> | ||
91 | <dt><span class="section"><a href="git.html">2.4. Git</a></span></dt> | ||
92 | <dd><dl> | ||
93 | <dt><span class="section"><a href="repositories-tags-and-branches.html">2.4.1. Repositories, Tags, and Branches</a></span></dt> | ||
94 | <dt><span class="section"><a href="basic-commands.html">2.4.2. Basic Commands</a></span></dt> | ||
95 | </dl></dd> | ||
96 | <dt><span class="section"><a href="yocto-project-repositories.html">2.5. Yocto Project Source Repositories</a></span></dt> | ||
97 | <dt><span class="section"><a href="licensing.html">2.6. Licensing</a></span></dt> | ||
98 | <dt><span class="section"><a href="recipe-syntax.html">2.7. Recipe Syntax</a></span></dt> | ||
99 | <dt><span class="section"><a href="development-concepts.html">2.8. Development Concepts</a></span></dt> | ||
100 | <dd><dl> | ||
101 | <dt><span class="section"><a href="user-configuration.html">2.8.1. User Configuration</a></span></dt> | ||
102 | <dt><span class="section"><a href="metadata-machine-configuration-and-policy-configuration.html">2.8.2. Metadata, Machine Configuration, and Policy Configuration</a></span></dt> | ||
103 | <dt><span class="section"><a href="sources-dev-environment.html">2.8.3. Sources</a></span></dt> | ||
104 | <dt><span class="section"><a href="package-feeds-dev-environment.html">2.8.4. Package Feeds</a></span></dt> | ||
105 | <dt><span class="section"><a href="bitbake-dev-environment.html">2.8.5. BitBake</a></span></dt> | ||
106 | <dt><span class="section"><a href="images-dev-environment.html">2.8.6. Images</a></span></dt> | ||
107 | <dt><span class="section"><a href="sdk-dev-environment.html">2.8.7. Application Development SDK</a></span></dt> | ||
108 | </dl></dd> | ||
109 | </dl></dd> | ||
110 | <dt><span class="chapter"><a href="overview-concepts.html">3. Yocto Project Concepts</a></span></dt> | ||
111 | <dd><dl> | ||
112 | <dt><span class="section"><a href="yocto-project-components.html">3.1. Yocto Project Components</a></span></dt> | ||
113 | <dd><dl> | ||
114 | <dt><span class="section"><a href="usingpoky-components-bitbake.html">3.1.1. BitBake</a></span></dt> | ||
115 | <dt><span class="section"><a href="usingpoky-components-metadata.html">3.1.2. Metadata (Recipes)</a></span></dt> | ||
116 | <dt><span class="section"><a href="metadata-virtual-providers.html">3.1.3. Metadata (Virtual Providers)</a></span></dt> | ||
117 | <dt><span class="section"><a href="usingpoky-components-classes.html">3.1.4. Classes</a></span></dt> | ||
118 | <dt><span class="section"><a href="usingpoky-components-configuration.html">3.1.5. Configuration</a></span></dt> | ||
119 | </dl></dd> | ||
120 | <dt><span class="section"><a href="cross-development-toolchain-generation.html">3.2. Cross-Development Toolchain Generation</a></span></dt> | ||
121 | <dt><span class="section"><a href="shared-state-cache.html">3.3. Shared State Cache</a></span></dt> | ||
122 | <dd><dl> | ||
123 | <dt><span class="section"><a href="overall-architecture.html">3.3.1. Overall Architecture</a></span></dt> | ||
124 | <dt><span class="section"><a href="overview-checksums.html">3.3.2. Checksums (Signatures)</a></span></dt> | ||
125 | <dt><span class="section"><a href="shared-state.html">3.3.3. Shared State</a></span></dt> | ||
126 | <dt><span class="section"><a href="tips-and-tricks.html">3.3.4. Tips and Tricks</a></span></dt> | ||
127 | </dl></dd> | ||
128 | <dt><span class="section"><a href="automatically-added-runtime-dependencies.html">3.4. Automatically Added Runtime Dependencies</a></span></dt> | ||
129 | <dt><span class="section"><a href="fakeroot-and-pseudo.html">3.5. Fakeroot and Pseudo</a></span></dt> | ||
130 | <dt><span class="section"><a href="wayland.html">3.6. Wayland</a></span></dt> | ||
131 | <dd><dl> | ||
132 | <dt><span class="section"><a href="wayland-support.html">3.6.1. Support</a></span></dt> | ||
133 | <dt><span class="section"><a href="enabling-wayland-in-an-image.html">3.6.2. Enabling Wayland in an Image</a></span></dt> | ||
134 | <dt><span class="section"><a href="running-weston.html">3.6.3. Running Weston</a></span></dt> | ||
135 | </dl></dd> | ||
136 | <dt><span class="section"><a href="overview-licenses.html">3.7. Licenses</a></span></dt> | ||
137 | <dd><dl> | ||
138 | <dt><span class="section"><a href="usingpoky-configuring-LIC_FILES_CHKSUM.html">3.7.1. Tracking License Changes</a></span></dt> | ||
139 | <dt><span class="section"><a href="enabling-commercially-licensed-recipes.html">3.7.2. Enabling Commercially Licensed Recipes</a></span></dt> | ||
140 | </dl></dd> | ||
141 | <dt><span class="section"><a href="x32.html">3.8. x32 psABI</a></span></dt> | ||
142 | </dl></dd> | ||
143 | </dl> | ||
144 | </div> | ||
145 | |||
146 | |||
147 | |||
148 | |||
149 | |||
150 | |||
151 | |||
152 | |||
153 | </div></body> | ||
154 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/index.xml b/documentation/getting-started/eclipse/html/getting-started/index.xml deleted file mode 100644 index 9edb4b92ac..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/index.xml +++ /dev/null | |||
@@ -1,2 +0,0 @@ | |||
1 | <?xml version="1.0" encoding="utf-8" standalone="no"?> | ||
2 | <index/> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html b/documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html deleted file mode 100644 index ef4a2aac5e..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html +++ /dev/null | |||
@@ -1,77 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.3.4.2. Invalidating 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="tips-and-tricks.html" title="3.3.4. Tips and Tricks"> | ||
9 | <link rel="prev" href="overview-debugging.html" title="3.3.4.1. Debugging"> | ||
10 | <link rel="next" href="automatically-added-runtime-dependencies.html" title="3.4. Automatically Added Runtime Dependencies"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.4.2. Invalidating Shared State"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="invalidating-shared-state"></a>3.3.4.2. Invalidating Shared State</h4></div></div></div> | ||
15 | <p> | ||
16 | The OpenEmbedded build system uses checksums and shared | ||
17 | state cache to avoid unnecessarily rebuilding tasks. | ||
18 | Collectively, this scheme is known as "shared state code." | ||
19 | </p> | ||
20 | <p> | ||
21 | As with all schemes, this one has some drawbacks. | ||
22 | It is possible that you could make implicit changes to your | ||
23 | code that the checksum calculations do not take into | ||
24 | account. | ||
25 | These implicit changes affect a task's output but do not | ||
26 | trigger the shared state code into rebuilding a recipe. | ||
27 | Consider an example during which a tool changes its output. | ||
28 | Assume that the output of <code class="filename">rpmdeps</code> | ||
29 | changes. | ||
30 | The result of the change should be that all the | ||
31 | <code class="filename">package</code> and | ||
32 | <code class="filename">package_write_rpm</code> shared state cache | ||
33 | items become invalid. | ||
34 | However, because the change to the output is | ||
35 | external to the code and therefore implicit, | ||
36 | the associated shared state cache items do not become | ||
37 | invalidated. | ||
38 | In this case, the build process uses the cached items | ||
39 | rather than running the task again. | ||
40 | Obviously, these types of implicit changes can cause | ||
41 | problems. | ||
42 | </p> | ||
43 | <p> | ||
44 | To avoid these problems during the build, you need to | ||
45 | understand the effects of any changes you make. | ||
46 | Realize that changes you make directly to a function | ||
47 | are automatically factored into the checksum calculation. | ||
48 | Thus, these explicit changes invalidate the associated | ||
49 | area of shared state cache. | ||
50 | However, you need to be aware of any implicit changes that | ||
51 | are not obvious changes to the code and could affect | ||
52 | the output of a given task. | ||
53 | </p> | ||
54 | <p> | ||
55 | When you identify an implicit change, you can easily | ||
56 | take steps to invalidate the cache and force the tasks | ||
57 | to run. | ||
58 | The steps you can take are as simple as changing a | ||
59 | function's comments in the source code. | ||
60 | For example, to invalidate package shared state files, | ||
61 | change the comment statements of | ||
62 | <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a> | ||
63 | or the comments of one of the functions it calls. | ||
64 | Even though the change is purely cosmetic, it causes the | ||
65 | checksum to be recalculated and forces the OpenEmbedded | ||
66 | build system to run the task again. | ||
67 | </p> | ||
68 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
69 | <h3 class="title">Note</h3> | ||
70 | For an example of a commit that makes a cosmetic | ||
71 | change to invalidate shared state, see this | ||
72 | <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54" target="_self">commit</a>. | ||
73 | </div> | ||
74 | <p> | ||
75 | </p> | ||
76 | </div></body> | ||
77 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/license-flag-matching.html b/documentation/getting-started/eclipse/html/getting-started/license-flag-matching.html deleted file mode 100644 index 1e08bafad1..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/license-flag-matching.html +++ /dev/null | |||
@@ -1,126 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.7.2.1. License Flag Matching</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="enabling-commercially-licensed-recipes.html" title="3.7.2. Enabling Commercially Licensed Recipes"> | ||
9 | <link rel="prev" href="enabling-commercially-licensed-recipes.html" title="3.7.2. Enabling Commercially Licensed Recipes"> | ||
10 | <link rel="next" href="other-variables-related-to-commercial-licenses.html" title="3.7.2.2. Other Variables Related to Commercial Licenses"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.2.1. License Flag Matching"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="license-flag-matching"></a>3.7.2.1. License Flag Matching</h4></div></div></div> | ||
15 | <p> | ||
16 | License flag matching allows you to control what recipes | ||
17 | the OpenEmbedded build system includes in the build. | ||
18 | Fundamentally, the build system attempts to match | ||
19 | <a class="link" href="../ref-manual/var-LICENSE_FLAGS.html" target="_self"><code class="filename">LICENSE_FLAGS</code></a> | ||
20 | strings found in recipes against | ||
21 | <a class="link" href="../ref-manual/var-LICENSE_FLAGS_WHITELIST.html" target="_self"><code class="filename">LICENSE_FLAGS_WHITELIST</code></a> | ||
22 | strings found in the whitelist. | ||
23 | A match causes the build system to include a recipe in the | ||
24 | build, while failure to find a match causes the build | ||
25 | system to exclude a recipe. | ||
26 | </p> | ||
27 | <p> | ||
28 | In general, license flag matching is simple. | ||
29 | However, understanding some concepts will help you | ||
30 | correctly and effectively use matching. | ||
31 | </p> | ||
32 | <p> | ||
33 | Before a flag | ||
34 | defined by a particular recipe is tested against the | ||
35 | contents of the whitelist, the expanded string | ||
36 | <code class="filename">_${PN}</code> is appended to the flag. | ||
37 | This expansion makes each | ||
38 | <code class="filename">LICENSE_FLAGS</code> value recipe-specific. | ||
39 | After expansion, the string is then matched against the | ||
40 | whitelist. | ||
41 | Thus, specifying | ||
42 | <code class="filename">LICENSE_FLAGS = "commercial"</code> | ||
43 | in recipe "foo", for example, results in the string | ||
44 | <code class="filename">"commercial_foo"</code>. | ||
45 | And, to create a match, that string must appear in the | ||
46 | whitelist. | ||
47 | </p> | ||
48 | <p> | ||
49 | Judicious use of the <code class="filename">LICENSE_FLAGS</code> | ||
50 | strings and the contents of the | ||
51 | <code class="filename">LICENSE_FLAGS_WHITELIST</code> variable | ||
52 | allows you a lot of flexibility for including or excluding | ||
53 | recipes based on licensing. | ||
54 | For example, you can broaden the matching capabilities by | ||
55 | using license flags string subsets in the whitelist. | ||
56 | </p> | ||
57 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
58 | <h3 class="title">Note</h3> | ||
59 | When using a string subset, be sure to use the part of | ||
60 | the expanded string that precedes the appended | ||
61 | underscore character (e.g. | ||
62 | <code class="filename">usethispart_1.3</code>, | ||
63 | <code class="filename">usethispart_1.4</code>, and so forth). | ||
64 | </div> | ||
65 | <p> | ||
66 | For example, simply specifying the string "commercial" in | ||
67 | the whitelist matches any expanded | ||
68 | <code class="filename">LICENSE_FLAGS</code> definition that starts | ||
69 | with the string "commercial" such as "commercial_foo" and | ||
70 | "commercial_bar", which are the strings the build system | ||
71 | automatically generates for hypothetical recipes named | ||
72 | "foo" and "bar" assuming those recipes simply specify the | ||
73 | following: | ||
74 | </p> | ||
75 | <pre class="literallayout"> | ||
76 | LICENSE_FLAGS = "commercial" | ||
77 | </pre> | ||
78 | <p> | ||
79 | Thus, you can choose to exhaustively | ||
80 | enumerate each license flag in the whitelist and | ||
81 | allow only specific recipes into the image, or | ||
82 | you can use a string subset that causes a broader range of | ||
83 | matches to allow a range of recipes into the image. | ||
84 | </p> | ||
85 | <p> | ||
86 | This scheme works even if the | ||
87 | <code class="filename">LICENSE_FLAGS</code> string already | ||
88 | has <code class="filename">_${PN}</code> appended. | ||
89 | For example, the build system turns the license flag | ||
90 | "commercial_1.2_foo" into "commercial_1.2_foo_foo" and | ||
91 | would match both the general "commercial" and the specific | ||
92 | "commercial_1.2_foo" strings found in the whitelist, as | ||
93 | expected. | ||
94 | </p> | ||
95 | <p> | ||
96 | Here are some other scenarios: | ||
97 | </p> | ||
98 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
99 | <li class="listitem"><p> | ||
100 | You can specify a versioned string in the recipe | ||
101 | such as "commercial_foo_1.2" in a "foo" recipe. | ||
102 | The build system expands this string to | ||
103 | "commercial_foo_1.2_foo". | ||
104 | Combine this license flag with a whitelist that has | ||
105 | the string "commercial" and you match the flag | ||
106 | along with any other flag that starts with the | ||
107 | string "commercial". | ||
108 | </p></li> | ||
109 | <li class="listitem"><p> | ||
110 | Under the same circumstances, you can use | ||
111 | "commercial_foo" in the whitelist and the build | ||
112 | system not only matches "commercial_foo_1.2" but | ||
113 | also matches any license flag with the string | ||
114 | "commercial_foo", regardless of the version. | ||
115 | </p></li> | ||
116 | <li class="listitem"><p> | ||
117 | You can be very specific and use both the | ||
118 | package and version parts in the whitelist (e.g. | ||
119 | "commercial_foo_1.2") to specifically match a | ||
120 | versioned recipe. | ||
121 | </p></li> | ||
122 | </ul></div> | ||
123 | <p> | ||
124 | </p> | ||
125 | </div></body> | ||
126 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/licensing.html b/documentation/getting-started/eclipse/html/getting-started/licensing.html deleted file mode 100644 index ade868705c..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/licensing.html +++ /dev/null | |||
@@ -1,91 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.6. Licensing</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-development-environment.html" title="Chapter 2. The Yocto Project Development Environment"> | ||
9 | <link rel="prev" href="yocto-project-repositories.html" title="2.5. Yocto Project Source Repositories"> | ||
10 | <link rel="next" href="recipe-syntax.html" title="2.7. Recipe Syntax"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.6. Licensing"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="licensing"></a>2.6. Licensing</h2></div></div></div> | ||
15 | <p> | ||
16 | Because open source projects are open to the public, they have | ||
17 | different licensing structures in place. | ||
18 | License evolution for both Open Source and Free Software has an | ||
19 | interesting history. | ||
20 | If you are interested in this history, you can find basic information | ||
21 | here: | ||
22 | </p> | ||
23 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
24 | <li class="listitem"><p> | ||
25 | <a class="ulink" href="http://en.wikipedia.org/wiki/Open-source_license" target="_self">Open source license history</a> | ||
26 | </p></li> | ||
27 | <li class="listitem"><p> | ||
28 | <a class="ulink" href="http://en.wikipedia.org/wiki/Free_software_license" target="_self">Free software license history</a> | ||
29 | </p></li> | ||
30 | </ul></div> | ||
31 | <p> | ||
32 | </p> | ||
33 | <p> | ||
34 | In general, the Yocto Project is broadly licensed under the | ||
35 | Massachusetts Institute of Technology (MIT) License. | ||
36 | MIT licensing permits the reuse of software within proprietary | ||
37 | software as long as the license is distributed with that software. | ||
38 | MIT is also compatible with the GNU General Public License (GPL). | ||
39 | Patches to the Yocto Project follow the upstream licensing scheme. | ||
40 | You can find information on the MIT license | ||
41 | <a class="ulink" href="http://www.opensource.org/licenses/mit-license.php" target="_self">here</a>. | ||
42 | You can find information on the GNU GPL | ||
43 | <a class="ulink" href="http://www.opensource.org/licenses/LGPL-3.0" target="_self">here</a>. | ||
44 | </p> | ||
45 | <p> | ||
46 | When you build an image using the Yocto Project, the build process | ||
47 | uses a known list of licenses to ensure compliance. | ||
48 | You can find this list in the | ||
49 | <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a> | ||
50 | at <code class="filename">meta/files/common-licenses</code>. | ||
51 | Once the build completes, the list of all licenses found and used | ||
52 | during that build are kept in the | ||
53 | <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a> | ||
54 | at <code class="filename">tmp/deploy/licenses</code>. | ||
55 | </p> | ||
56 | <p> | ||
57 | If a module requires a license that is not in the base list, the | ||
58 | build process generates a warning during the build. | ||
59 | These tools make it easier for a developer to be certain of the | ||
60 | licenses with which their shipped products must comply. | ||
61 | However, even with these tools it is still up to the developer to | ||
62 | resolve potential licensing issues. | ||
63 | </p> | ||
64 | <p> | ||
65 | The base list of licenses used by the build process is a combination | ||
66 | of the Software Package Data Exchange (SPDX) list and the Open | ||
67 | Source Initiative (OSI) projects. | ||
68 | <a class="ulink" href="http://spdx.org" target="_self">SPDX Group</a> is a working group of | ||
69 | the Linux Foundation that maintains a specification for a standard | ||
70 | format for communicating the components, licenses, and copyrights | ||
71 | associated with a software package. | ||
72 | <a class="ulink" href="http://opensource.org" target="_self">OSI</a> is a corporation | ||
73 | dedicated to the Open Source Definition and the effort for reviewing | ||
74 | and approving licenses that conform to the Open Source Definition | ||
75 | (OSD). | ||
76 | </p> | ||
77 | <p> | ||
78 | You can find a list of the combined SPDX and OSI licenses that the | ||
79 | Yocto Project uses in the | ||
80 | <code class="filename">meta/files/common-licenses</code> directory in your | ||
81 | <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>. | ||
82 | </p> | ||
83 | <p> | ||
84 | For information that can help you maintain compliance with various | ||
85 | open source licensing during the lifecycle of a product created using | ||
86 | the Yocto Project, see the | ||
87 | "<a class="link" href="../dev-manual/maintaining-open-source-license-compliance-during-your-products-lifecycle.html" target="_self">Maintaining Open Source License Compliance During Your Product's Lifecycle</a>" | ||
88 | section in the Yocto Project Development Tasks Manual. | ||
89 | </p> | ||
90 | </div></body> | ||
91 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/local-projects.html b/documentation/getting-started/eclipse/html/getting-started/local-projects.html deleted file mode 100644 index 9ed618701c..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/local-projects.html +++ /dev/null | |||
@@ -1,39 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.3.2. Local Projects</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="sources-dev-environment.html" title="2.8.3. Sources"> | ||
9 | <link rel="prev" href="upstream-project-releases.html" title="2.8.3.1. Upstream Project Releases"> | ||
10 | <link rel="next" href="scms.html" title="2.8.3.3. Source Control Managers (Optional)"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.3.2. Local Projects"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="local-projects"></a>2.8.3.2. Local Projects</h4></div></div></div> | ||
15 | <p> | ||
16 | Local projects are custom bits of software the user provides. | ||
17 | These bits reside somewhere local to a project - perhaps | ||
18 | a directory into which the user checks in items (e.g. | ||
19 | a local directory containing a development source tree | ||
20 | used by the group). | ||
21 | </p> | ||
22 | <p> | ||
23 | The canonical method through which to include a local project | ||
24 | is to use the | ||
25 | <a class="link" href="../ref-manual/ref-classes-externalsrc.html" target="_self"><code class="filename">externalsrc</code></a> | ||
26 | class to include that local project. | ||
27 | You use either the <code class="filename">local.conf</code> or a | ||
28 | recipe's append file to override or set the | ||
29 | recipe to point to the local directory on your disk to pull | ||
30 | in the whole source tree. | ||
31 | </p> | ||
32 | <p> | ||
33 | For information on how to use the | ||
34 | <code class="filename">externalsrc</code> class, see the | ||
35 | "<a class="link" href="../ref-manual/ref-classes-externalsrc.html" target="_self"><code class="filename">externalsrc.bbclass</code></a>" | ||
36 | section. | ||
37 | </p> | ||
38 | </div></body> | ||
39 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/metadata-machine-configuration-and-policy-configuration.html b/documentation/getting-started/eclipse/html/getting-started/metadata-machine-configuration-and-policy-configuration.html deleted file mode 100644 index 24f32f394f..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/metadata-machine-configuration-and-policy-configuration.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>2.8.2. Metadata, Machine Configuration, and Policy Configuration</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="development-concepts.html" title="2.8. Development Concepts"> | ||
9 | <link rel="prev" href="user-configuration.html" title="2.8.1. User Configuration"> | ||
10 | <link rel="next" href="distro-layer.html" title="2.8.2.1. Distro Layer"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.2. Metadata, Machine Configuration, and Policy Configuration"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="metadata-machine-configuration-and-policy-configuration"></a>2.8.2. Metadata, Machine Configuration, and Policy Configuration</h3></div></div></div> | ||
15 | <p> | ||
16 | The previous section described the user configurations that | ||
17 | define BitBake's global behavior. | ||
18 | This section takes a closer look at the layers the build system | ||
19 | uses to further control the build. | ||
20 | These layers provide Metadata for the software, machine, and | ||
21 | policy. | ||
22 | </p> | ||
23 | <p> | ||
24 | In general, three types of layer input exist: | ||
25 | </p> | ||
26 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
27 | <li class="listitem"><p><span class="emphasis"><em>Policy Configuration:</em></span> | ||
28 | Distribution Layers provide top-level or general | ||
29 | policies for the image or SDK being built. | ||
30 | For example, this layer would dictate whether BitBake | ||
31 | produces RPM or IPK packages.</p></li> | ||
32 | <li class="listitem"><p><span class="emphasis"><em>Machine Configuration:</em></span> | ||
33 | Board Support Package (BSP) layers provide machine | ||
34 | configurations. | ||
35 | This type of information is specific to a particular | ||
36 | target architecture.</p></li> | ||
37 | <li class="listitem"><p><span class="emphasis"><em>Metadata:</em></span> | ||
38 | Software layers contain user-supplied recipe files, | ||
39 | patches, and append files. | ||
40 | </p></li> | ||
41 | </ul></div> | ||
42 | <p> | ||
43 | </p> | ||
44 | <p> | ||
45 | The following figure shows an expanded representation of the | ||
46 | Metadata, Machine Configuration, and Policy Configuration input | ||
47 | (layers) boxes of the | ||
48 | <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>: | ||
49 | </p> | ||
50 | <p> | ||
51 | </p> | ||
52 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 675px"><td align="center"><img src="figures/layer-input.png" align="middle" width="720"></td></tr></table> | ||
53 | <p> | ||
54 | </p> | ||
55 | <p> | ||
56 | In general, all layers have a similar structure. | ||
57 | They all contain a licensing file | ||
58 | (e.g. <code class="filename">COPYING</code>) if the layer is to be | ||
59 | distributed, a <code class="filename">README</code> file as good practice | ||
60 | and especially if the layer is to be distributed, a | ||
61 | configuration directory, and recipe directories. | ||
62 | </p> | ||
63 | <p> | ||
64 | The Yocto Project has many layers that can be used. | ||
65 | You can see a web-interface listing of them on the | ||
66 | <a class="ulink" href="http://git.yoctoproject.org/" target="_self">Source Repositories</a> | ||
67 | page. | ||
68 | The layers are shown at the bottom categorized under | ||
69 | "Yocto Metadata Layers." | ||
70 | These layers are fundamentally a subset of the | ||
71 | <a class="ulink" href="http://layers.openembedded.org/layerindex/layers/" target="_self">OpenEmbedded Metadata Index</a>, | ||
72 | which lists all layers provided by the OpenEmbedded community. | ||
73 | </p> | ||
74 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
75 | <h3 class="title">Note</h3> | ||
76 | Layers exist in the Yocto Project Source Repositories that | ||
77 | cannot be found in the OpenEmbedded Metadata Index. | ||
78 | These layers are either deprecated or experimental in nature. | ||
79 | </div> | ||
80 | <p> | ||
81 | </p> | ||
82 | <p> | ||
83 | BitBake uses the <code class="filename">conf/bblayers.conf</code> file, | ||
84 | which is part of the user configuration, to find what layers it | ||
85 | should be using as part of the build. | ||
86 | </p> | ||
87 | <p> | ||
88 | For more information on layers, see the | ||
89 | "<a class="link" href="../dev-manual/understanding-and-creating-layers.html" target="_self">Understanding and Creating Layers</a>" | ||
90 | section in the Yocto Project Development Tasks Manual. | ||
91 | </p> | ||
92 | </div></body> | ||
93 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/metadata-virtual-providers.html b/documentation/getting-started/eclipse/html/getting-started/metadata-virtual-providers.html deleted file mode 100644 index ebbae37990..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/metadata-virtual-providers.html +++ /dev/null | |||
@@ -1,74 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.1.3. Metadata (Virtual Providers)</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="yocto-project-components.html" title="3.1. Yocto Project Components"> | ||
9 | <link rel="prev" href="usingpoky-components-metadata.html" title="3.1.2. Metadata (Recipes)"> | ||
10 | <link rel="next" href="usingpoky-components-classes.html" title="3.1.4. Classes"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.3. Metadata (Virtual Providers)"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="metadata-virtual-providers"></a>3.1.3. Metadata (Virtual Providers)</h3></div></div></div> | ||
15 | <p> | ||
16 | Prior to the build, if you know that several different recipes | ||
17 | provide the same functionality, you can use a virtual provider | ||
18 | (i.e. <code class="filename">virtual/*</code>) as a placeholder for the | ||
19 | actual provider. | ||
20 | The actual provider would be determined at build time. | ||
21 | In this case, you should add <code class="filename">virtual/*</code> | ||
22 | to | ||
23 | <a class="link" href="../ref-manual/var-DEPENDS.html" target="_self"><code class="filename">DEPENDS</code></a>, | ||
24 | rather than listing the specified provider. | ||
25 | You would select the actual provider by setting the | ||
26 | <a class="link" href="../ref-manual/var-PREFERRED_PROVIDER.html" target="_self"><code class="filename">PREFERRED_PROVIDER</code></a> | ||
27 | variable (i.e. | ||
28 | <code class="filename">PREFERRED_PROVIDER_virtual/*</code>) | ||
29 | in the build's configuration file (e.g. | ||
30 | <code class="filename">poky/build/conf/local.conf</code>). | ||
31 | </p> | ||
32 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
33 | <h3 class="title">Note</h3> | ||
34 | Any recipe that PROVIDES a <code class="filename">virtual/*</code> | ||
35 | item that is ultimately not selected through | ||
36 | <code class="filename">PREFERRED_PROVIDER</code> does not get built. | ||
37 | Preventing these recipes from building is usually the | ||
38 | desired behavior since this mechanism's purpose is to | ||
39 | select between mutually exclusive alternative providers. | ||
40 | </div> | ||
41 | <p> | ||
42 | </p> | ||
43 | <p> | ||
44 | The following lists specific examples of virtual providers: | ||
45 | </p> | ||
46 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
47 | <li class="listitem"><p> | ||
48 | <code class="filename">virtual/mesa</code>: | ||
49 | Provides <code class="filename">gbm.pc</code>. | ||
50 | </p></li> | ||
51 | <li class="listitem"><p> | ||
52 | <code class="filename">virtual/egl</code>: | ||
53 | Provides <code class="filename">egl.pc</code> and possibly | ||
54 | <code class="filename">wayland-egl.pc</code>. | ||
55 | </p></li> | ||
56 | <li class="listitem"><p> | ||
57 | <code class="filename">virtual/libgl</code>: | ||
58 | Provides <code class="filename">gl.pc</code> (i.e. libGL). | ||
59 | </p></li> | ||
60 | <li class="listitem"><p> | ||
61 | <code class="filename">virtual/libgles1</code>: | ||
62 | Provides <code class="filename">glesv1_cm.pc</code> | ||
63 | (i.e. libGLESv1_CM). | ||
64 | </p></li> | ||
65 | <li class="listitem"><p> | ||
66 | <code class="filename">virtual/libgles2</code>: | ||
67 | Provides <code class="filename">glesv2.pc</code> | ||
68 | (i.e. libGLESv2). | ||
69 | </p></li> | ||
70 | </ul></div> | ||
71 | <p> | ||
72 | </p> | ||
73 | </div></body> | ||
74 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/open-source-philosophy.html b/documentation/getting-started/eclipse/html/getting-started/open-source-philosophy.html deleted file mode 100644 index bd9467e001..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/open-source-philosophy.html +++ /dev/null | |||
@@ -1,54 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.2. Open Source Philosophy</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-development-environment.html" title="Chapter 2. The Yocto Project Development Environment"> | ||
9 | <link rel="prev" href="yp-intro.html" title="2.1. Introduction"> | ||
10 | <link rel="next" href="workflows.html" title="2.3. Workflows"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.2. Open Source Philosophy"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="open-source-philosophy"></a>2.2. Open Source Philosophy</h2></div></div></div> | ||
15 | <p> | ||
16 | Open source philosophy is characterized by software development | ||
17 | directed by peer production and collaboration through an active | ||
18 | community of developers. | ||
19 | Contrast this to the more standard centralized development models | ||
20 | used by commercial software companies where a finite set of developers | ||
21 | produces a product for sale using a defined set of procedures that | ||
22 | ultimately result in an end product whose architecture and source | ||
23 | material are closed to the public. | ||
24 | </p> | ||
25 | <p> | ||
26 | Open source projects conceptually have differing concurrent agendas, | ||
27 | approaches, and production. | ||
28 | These facets of the development process can come from anyone in the | ||
29 | public (community) that has a stake in the software project. | ||
30 | The open source environment contains new copyright, licensing, domain, | ||
31 | and consumer issues that differ from the more traditional development | ||
32 | environment. | ||
33 | In an open source environment, the end product, source material, | ||
34 | and documentation are all available to the public at no cost. | ||
35 | </p> | ||
36 | <p> | ||
37 | A benchmark example of an open source project is the Linux kernel, | ||
38 | which was initially conceived and created by Finnish computer science | ||
39 | student Linus Torvalds in 1991. | ||
40 | Conversely, a good example of a non-open source project is the | ||
41 | <span class="trademark">Windows</span>® family of operating | ||
42 | systems developed by | ||
43 | <span class="trademark">Microsoft</span>® Corporation. | ||
44 | </p> | ||
45 | <p> | ||
46 | Wikipedia has a good historical description of the Open Source | ||
47 | Philosophy | ||
48 | <a class="ulink" href="http://en.wikipedia.org/wiki/Open_source" target="_self">here</a>. | ||
49 | You can also find helpful information on how to participate in the | ||
50 | Linux Community | ||
51 | <a class="ulink" href="http://ldn.linuxfoundation.org/book/how-participate-linux-community" target="_self">here</a>. | ||
52 | </p> | ||
53 | </div></body> | ||
54 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/other-variables-related-to-commercial-licenses.html b/documentation/getting-started/eclipse/html/getting-started/other-variables-related-to-commercial-licenses.html deleted file mode 100644 index 73d152bb40..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/other-variables-related-to-commercial-licenses.html +++ /dev/null | |||
@@ -1,59 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.7.2.2. Other Variables Related to Commercial Licenses</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="enabling-commercially-licensed-recipes.html" title="3.7.2. Enabling Commercially Licensed Recipes"> | ||
9 | <link rel="prev" href="license-flag-matching.html" title="3.7.2.1. License Flag Matching"> | ||
10 | <link rel="next" href="x32.html" title="3.8. x32 psABI"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.2.2. Other Variables Related to Commercial Licenses"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="other-variables-related-to-commercial-licenses"></a>3.7.2.2. Other Variables Related to Commercial Licenses</h4></div></div></div> | ||
15 | <p> | ||
16 | Other helpful variables related to commercial | ||
17 | license handling exist and are defined in the | ||
18 | <code class="filename">poky/meta/conf/distro/include/default-distrovars.inc</code> file: | ||
19 | </p> | ||
20 | <pre class="literallayout"> | ||
21 | COMMERCIAL_AUDIO_PLUGINS ?= "" | ||
22 | COMMERCIAL_VIDEO_PLUGINS ?= "" | ||
23 | </pre> | ||
24 | <p> | ||
25 | If you want to enable these components, you can do so by | ||
26 | making sure you have statements similar to the following | ||
27 | in your <code class="filename">local.conf</code> configuration file: | ||
28 | </p> | ||
29 | <pre class="literallayout"> | ||
30 | COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \ | ||
31 | gst-plugins-ugly-mpegaudioparse" | ||
32 | COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \ | ||
33 | gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse" | ||
34 | LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp" | ||
35 | </pre> | ||
36 | <p> | ||
37 | Of course, you could also create a matching whitelist | ||
38 | for those components using the more general "commercial" | ||
39 | in the whitelist, but that would also enable all the | ||
40 | other packages with | ||
41 | <a class="link" href="../ref-manual/var-LICENSE_FLAGS.html" target="_self"><code class="filename">LICENSE_FLAGS</code></a> | ||
42 | containing "commercial", which you may or may not want: | ||
43 | </p> | ||
44 | <pre class="literallayout"> | ||
45 | LICENSE_FLAGS_WHITELIST = "commercial" | ||
46 | </pre> | ||
47 | <p> | ||
48 | </p> | ||
49 | <p> | ||
50 | Specifying audio and video plug-ins as part of the | ||
51 | <code class="filename">COMMERCIAL_AUDIO_PLUGINS</code> and | ||
52 | <code class="filename">COMMERCIAL_VIDEO_PLUGINS</code> statements | ||
53 | (along with the enabling | ||
54 | <code class="filename">LICENSE_FLAGS_WHITELIST</code>) includes the | ||
55 | plug-ins or components into built images, thus adding | ||
56 | support for media formats or components. | ||
57 | </p> | ||
58 | </div></body> | ||
59 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/overall-architecture.html b/documentation/getting-started/eclipse/html/getting-started/overall-architecture.html deleted file mode 100644 index 974b05792a..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/overall-architecture.html +++ /dev/null | |||
@@ -1,40 +0,0 @@ | |||
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> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-checksums.html b/documentation/getting-started/eclipse/html/getting-started/overview-checksums.html deleted file mode 100644 index 09ad110f71..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/overview-checksums.html +++ /dev/null | |||
@@ -1,209 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.3.2. Checksums (Signatures)</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="overall-architecture.html" title="3.3.1. Overall Architecture"> | ||
10 | <link rel="next" href="shared-state.html" title="3.3.3. Shared State"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.2. Checksums (Signatures)"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="overview-checksums"></a>3.3.2. Checksums (Signatures)</h3></div></div></div> | ||
15 | <p> | ||
16 | The shared state code uses a checksum, which is a unique | ||
17 | signature of a task's inputs, to determine if a task needs to | ||
18 | be run again. | ||
19 | Because it is a change in a task's inputs that triggers a | ||
20 | rerun, the process needs to detect all the inputs to a given | ||
21 | task. | ||
22 | For shell tasks, this turns out to be fairly easy because | ||
23 | the build process generates a "run" shell script for each task | ||
24 | and it is possible to create a checksum that gives you a good | ||
25 | idea of when the task's data changes. | ||
26 | </p> | ||
27 | <p> | ||
28 | To complicate the problem, there are things that should not be | ||
29 | included in the checksum. | ||
30 | First, there is the actual specific build path of a given | ||
31 | task - the | ||
32 | <a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a>. | ||
33 | It does not matter if the work directory changes because it | ||
34 | should not affect the output for target packages. | ||
35 | Also, the build process has the objective of making native | ||
36 | or cross packages relocatable. | ||
37 | </p> | ||
38 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
39 | <h3 class="title">Note</h3> | ||
40 | Both native and cross packages run on the build host. | ||
41 | However, cross packages generate output for the target | ||
42 | architecture. | ||
43 | </div> | ||
44 | <p> | ||
45 | The checksum therefore needs to exclude | ||
46 | <code class="filename">WORKDIR</code>. | ||
47 | The simplistic approach for excluding the work directory is to | ||
48 | set <code class="filename">WORKDIR</code> to some fixed value and | ||
49 | create the checksum for the "run" script. | ||
50 | </p> | ||
51 | <p> | ||
52 | Another problem results from the "run" scripts containing | ||
53 | functions that might or might not get called. | ||
54 | The incremental build solution contains code that figures out | ||
55 | dependencies between shell functions. | ||
56 | This code is used to prune the "run" scripts down to the | ||
57 | minimum set, thereby alleviating this problem and making the | ||
58 | "run" scripts much more readable as a bonus. | ||
59 | </p> | ||
60 | <p> | ||
61 | So far we have solutions for shell scripts. | ||
62 | What about Python tasks? | ||
63 | The same approach applies even though these tasks are more | ||
64 | difficult. | ||
65 | The process needs to figure out what variables a Python | ||
66 | function accesses and what functions it calls. | ||
67 | Again, the incremental build solution contains code that first | ||
68 | figures out the variable and function dependencies, and then | ||
69 | creates a checksum for the data used as the input to the task. | ||
70 | </p> | ||
71 | <p> | ||
72 | Like the <code class="filename">WORKDIR</code> case, situations exist | ||
73 | where dependencies should be ignored. | ||
74 | For these cases, you can instruct the build process to | ||
75 | ignore a dependency by using a line like the following: | ||
76 | </p> | ||
77 | <pre class="literallayout"> | ||
78 | PACKAGE_ARCHS[vardepsexclude] = "MACHINE" | ||
79 | </pre> | ||
80 | <p> | ||
81 | This example ensures that the | ||
82 | <a class="link" href="../ref-manual/var-PACKAGE_ARCHS.html" target="_self"><code class="filename">PACKAGE_ARCHS</code></a> | ||
83 | variable does not depend on the value of | ||
84 | <a class="link" href="../ref-manual/var-MACHINE.html" target="_self"><code class="filename">MACHINE</code></a>, | ||
85 | even if it does reference it. | ||
86 | </p> | ||
87 | <p> | ||
88 | Equally, there are cases where we need to add dependencies | ||
89 | BitBake is not able to find. | ||
90 | You can accomplish this by using a line like the following: | ||
91 | </p> | ||
92 | <pre class="literallayout"> | ||
93 | PACKAGE_ARCHS[vardeps] = "MACHINE" | ||
94 | </pre> | ||
95 | <p> | ||
96 | This example explicitly adds the <code class="filename">MACHINE</code> | ||
97 | variable as a dependency for | ||
98 | <code class="filename">PACKAGE_ARCHS</code>. | ||
99 | </p> | ||
100 | <p> | ||
101 | Consider a case with in-line Python, for example, where | ||
102 | BitBake is not able to figure out dependencies. | ||
103 | When running in debug mode (i.e. using | ||
104 | <code class="filename">-DDD</code>), BitBake produces output when it | ||
105 | discovers something for which it cannot figure out dependencies. | ||
106 | The Yocto Project team has currently not managed to cover | ||
107 | those dependencies in detail and is aware of the need to fix | ||
108 | this situation. | ||
109 | </p> | ||
110 | <p> | ||
111 | Thus far, this section has limited discussion to the direct | ||
112 | inputs into a task. | ||
113 | Information based on direct inputs is referred to as the | ||
114 | "basehash" in the code. | ||
115 | However, there is still the question of a task's indirect | ||
116 | inputs - the things that were already built and present in the | ||
117 | <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>. | ||
118 | The checksum (or signature) for a particular task needs to add | ||
119 | the hashes of all the tasks on which the particular task | ||
120 | depends. | ||
121 | Choosing which dependencies to add is a policy decision. | ||
122 | However, the effect is to generate a master checksum that | ||
123 | combines the basehash and the hashes of the task's | ||
124 | dependencies. | ||
125 | </p> | ||
126 | <p> | ||
127 | At the code level, there are a variety of ways both the | ||
128 | basehash and the dependent task hashes can be influenced. | ||
129 | Within the BitBake configuration file, we can give BitBake | ||
130 | some extra information to help it construct the basehash. | ||
131 | The following statement effectively results in a list of | ||
132 | global variable dependency excludes - variables never | ||
133 | included in any checksum: | ||
134 | </p> | ||
135 | <pre class="literallayout"> | ||
136 | BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \ | ||
137 | SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \ | ||
138 | USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \ | ||
139 | PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \ | ||
140 | CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX" | ||
141 | </pre> | ||
142 | <p> | ||
143 | The previous example excludes | ||
144 | <a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a> | ||
145 | since that variable is actually constructed as a path within | ||
146 | <a class="link" href="../ref-manual/var-TMPDIR.html" target="_self"><code class="filename">TMPDIR</code></a>, | ||
147 | which is on the whitelist. | ||
148 | </p> | ||
149 | <p> | ||
150 | The rules for deciding which hashes of dependent tasks to | ||
151 | include through dependency chains are more complex and are | ||
152 | generally accomplished with a Python function. | ||
153 | The code in <code class="filename">meta/lib/oe/sstatesig.py</code> shows | ||
154 | two examples of this and also illustrates how you can insert | ||
155 | your own policy into the system if so desired. | ||
156 | This file defines the two basic signature generators | ||
157 | <a class="link" href="../ref-manual/oe-core.html" target="_self">OE-Core</a> | ||
158 | uses: "OEBasic" and "OEBasicHash". | ||
159 | By default, there is a dummy "noop" signature handler enabled | ||
160 | in BitBake. | ||
161 | This means that behavior is unchanged from previous versions. | ||
162 | OE-Core uses the "OEBasicHash" signature handler by default | ||
163 | through this setting in the <code class="filename">bitbake.conf</code> | ||
164 | file: | ||
165 | </p> | ||
166 | <pre class="literallayout"> | ||
167 | BB_SIGNATURE_HANDLER ?= "OEBasicHash" | ||
168 | </pre> | ||
169 | <p> | ||
170 | The "OEBasicHash" <code class="filename">BB_SIGNATURE_HANDLER</code> | ||
171 | is the same as the "OEBasic" version but adds the task hash to | ||
172 | the stamp files. | ||
173 | This results in any | ||
174 | <a class="link" href="../ref-manual/metadata.html" target="_self">Metadata</a> | ||
175 | change that changes the task hash, automatically | ||
176 | causing the task to be run again. | ||
177 | This removes the need to bump | ||
178 | <a class="link" href="../ref-manual/var-PR.html" target="_self"><code class="filename">PR</code></a> | ||
179 | values, and changes to Metadata automatically ripple across | ||
180 | the build. | ||
181 | </p> | ||
182 | <p> | ||
183 | It is also worth noting that the end result of these | ||
184 | signature generators is to make some dependency and hash | ||
185 | information available to the build. | ||
186 | This information includes: | ||
187 | </p> | ||
188 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
189 | <li class="listitem"><p> | ||
190 | <code class="filename">BB_BASEHASH_task-</code><em class="replaceable"><code>taskname</code></em>: | ||
191 | The base hashes for each task in the recipe. | ||
192 | </p></li> | ||
193 | <li class="listitem"><p> | ||
194 | <code class="filename">BB_BASEHASH_</code><em class="replaceable"><code>filename</code></em><code class="filename">:</code><em class="replaceable"><code>taskname</code></em>: | ||
195 | The base hashes for each dependent task. | ||
196 | </p></li> | ||
197 | <li class="listitem"><p> | ||
198 | <code class="filename">BBHASHDEPS_</code><em class="replaceable"><code>filename</code></em><code class="filename">:</code><em class="replaceable"><code>taskname</code></em>: | ||
199 | The task dependencies for each task. | ||
200 | </p></li> | ||
201 | <li class="listitem"><p> | ||
202 | <code class="filename">BB_TASKHASH</code>: | ||
203 | The hash of the currently running task. | ||
204 | </p></li> | ||
205 | </ul></div> | ||
206 | <p> | ||
207 | </p> | ||
208 | </div></body> | ||
209 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-concepts.html b/documentation/getting-started/eclipse/html/getting-started/overview-concepts.html deleted file mode 100644 index 855d22e109..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/overview-concepts.html +++ /dev/null | |||
@@ -1,57 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>Chapter 3. Yocto Project Concepts</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="index.html" title="Getting Started With Yocto Project"> | ||
9 | <link rel="prev" href="sdk-dev-environment.html" title="2.8.7. Application Development SDK"> | ||
10 | <link rel="next" href="yocto-project-components.html" title="3.1. Yocto Project Components"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 3. Yocto Project Concepts"> | ||
13 | <div class="titlepage"><div><div><h2 class="title"> | ||
14 | <a name="overview-concepts"></a>Chapter 3. Yocto Project Concepts</h2></div></div></div> | ||
15 | <div class="toc"> | ||
16 | <p><b>Table of Contents</b></p> | ||
17 | <dl> | ||
18 | <dt><span class="section"><a href="yocto-project-components.html">3.1. Yocto Project Components</a></span></dt> | ||
19 | <dd><dl> | ||
20 | <dt><span class="section"><a href="usingpoky-components-bitbake.html">3.1.1. BitBake</a></span></dt> | ||
21 | <dt><span class="section"><a href="usingpoky-components-metadata.html">3.1.2. Metadata (Recipes)</a></span></dt> | ||
22 | <dt><span class="section"><a href="metadata-virtual-providers.html">3.1.3. Metadata (Virtual Providers)</a></span></dt> | ||
23 | <dt><span class="section"><a href="usingpoky-components-classes.html">3.1.4. Classes</a></span></dt> | ||
24 | <dt><span class="section"><a href="usingpoky-components-configuration.html">3.1.5. Configuration</a></span></dt> | ||
25 | </dl></dd> | ||
26 | <dt><span class="section"><a href="cross-development-toolchain-generation.html">3.2. Cross-Development Toolchain Generation</a></span></dt> | ||
27 | <dt><span class="section"><a href="shared-state-cache.html">3.3. Shared State Cache</a></span></dt> | ||
28 | <dd><dl> | ||
29 | <dt><span class="section"><a href="overall-architecture.html">3.3.1. Overall Architecture</a></span></dt> | ||
30 | <dt><span class="section"><a href="overview-checksums.html">3.3.2. Checksums (Signatures)</a></span></dt> | ||
31 | <dt><span class="section"><a href="shared-state.html">3.3.3. Shared State</a></span></dt> | ||
32 | <dt><span class="section"><a href="tips-and-tricks.html">3.3.4. Tips and Tricks</a></span></dt> | ||
33 | </dl></dd> | ||
34 | <dt><span class="section"><a href="automatically-added-runtime-dependencies.html">3.4. Automatically Added Runtime Dependencies</a></span></dt> | ||
35 | <dt><span class="section"><a href="fakeroot-and-pseudo.html">3.5. Fakeroot and Pseudo</a></span></dt> | ||
36 | <dt><span class="section"><a href="wayland.html">3.6. Wayland</a></span></dt> | ||
37 | <dd><dl> | ||
38 | <dt><span class="section"><a href="wayland-support.html">3.6.1. Support</a></span></dt> | ||
39 | <dt><span class="section"><a href="enabling-wayland-in-an-image.html">3.6.2. Enabling Wayland in an Image</a></span></dt> | ||
40 | <dt><span class="section"><a href="running-weston.html">3.6.3. Running Weston</a></span></dt> | ||
41 | </dl></dd> | ||
42 | <dt><span class="section"><a href="overview-licenses.html">3.7. Licenses</a></span></dt> | ||
43 | <dd><dl> | ||
44 | <dt><span class="section"><a href="usingpoky-configuring-LIC_FILES_CHKSUM.html">3.7.1. Tracking License Changes</a></span></dt> | ||
45 | <dt><span class="section"><a href="enabling-commercially-licensed-recipes.html">3.7.2. Enabling Commercially Licensed Recipes</a></span></dt> | ||
46 | </dl></dd> | ||
47 | <dt><span class="section"><a href="x32.html">3.8. x32 psABI</a></span></dt> | ||
48 | </dl> | ||
49 | </div> | ||
50 | <p> | ||
51 | This chapter describes concepts for various areas of the Yocto Project. | ||
52 | Currently, topics include Yocto Project components, cross-development | ||
53 | generation, shared state (sstate) cache, runtime dependencies, | ||
54 | Pseudo and Fakeroot, x32 psABI, Wayland support, and Licenses. | ||
55 | </p> | ||
56 | </div></body> | ||
57 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-debugging.html b/documentation/getting-started/eclipse/html/getting-started/overview-debugging.html deleted file mode 100644 index b8b4c880e7..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/overview-debugging.html +++ /dev/null | |||
@@ -1,28 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.3.4.1. Debugging</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="tips-and-tricks.html" title="3.3.4. Tips and Tricks"> | ||
9 | <link rel="prev" href="tips-and-tricks.html" title="3.3.4. Tips and Tricks"> | ||
10 | <link rel="next" href="invalidating-shared-state.html" title="3.3.4.2. Invalidating Shared State"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.4.1. Debugging"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="overview-debugging"></a>3.3.4.1. Debugging</h4></div></div></div> | ||
15 | <p> | ||
16 | Seeing what metadata went into creating the input signature | ||
17 | of a shared state (sstate) task can be a useful debugging | ||
18 | aid. | ||
19 | This information is available in signature information | ||
20 | (<code class="filename">siginfo</code>) files in | ||
21 | <a class="link" href="../ref-manual/var-SSTATE_DIR.html" target="_self"><code class="filename">SSTATE_DIR</code></a>. | ||
22 | For information on how to view and interpret information in | ||
23 | <code class="filename">siginfo</code> files, see the | ||
24 | "<a class="link" href="../dev-manual/dev-viewing-task-variable-dependencies.html" target="_self">Viewing Task Variable Dependencies</a>" | ||
25 | section in the Yocto Project Development Tasks Manual. | ||
26 | </p> | ||
27 | </div></body> | ||
28 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-development-environment.html b/documentation/getting-started/eclipse/html/getting-started/overview-development-environment.html deleted file mode 100644 index c8030fee19..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/overview-development-environment.html +++ /dev/null | |||
@@ -1,56 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>Chapter 2. The Yocto Project Development Environment</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="index.html" title="Getting Started With Yocto Project"> | ||
9 | <link rel="prev" href="overview-other-information.html" title="1.2. Other Information"> | ||
10 | <link rel="next" href="yp-intro.html" title="2.1. Introduction"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 2. The Yocto Project Development Environment"> | ||
13 | <div class="titlepage"><div><div><h2 class="title"> | ||
14 | <a name="overview-development-environment"></a>Chapter 2. The Yocto Project Development Environment</h2></div></div></div> | ||
15 | <div class="toc"> | ||
16 | <p><b>Table of Contents</b></p> | ||
17 | <dl> | ||
18 | <dt><span class="section"><a href="yp-intro.html">2.1. Introduction</a></span></dt> | ||
19 | <dt><span class="section"><a href="open-source-philosophy.html">2.2. Open Source Philosophy</a></span></dt> | ||
20 | <dt><span class="section"><a href="workflows.html">2.3. Workflows</a></span></dt> | ||
21 | <dt><span class="section"><a href="git.html">2.4. Git</a></span></dt> | ||
22 | <dd><dl> | ||
23 | <dt><span class="section"><a href="repositories-tags-and-branches.html">2.4.1. Repositories, Tags, and Branches</a></span></dt> | ||
24 | <dt><span class="section"><a href="basic-commands.html">2.4.2. Basic Commands</a></span></dt> | ||
25 | </dl></dd> | ||
26 | <dt><span class="section"><a href="yocto-project-repositories.html">2.5. Yocto Project Source Repositories</a></span></dt> | ||
27 | <dt><span class="section"><a href="licensing.html">2.6. Licensing</a></span></dt> | ||
28 | <dt><span class="section"><a href="recipe-syntax.html">2.7. Recipe Syntax</a></span></dt> | ||
29 | <dt><span class="section"><a href="development-concepts.html">2.8. Development Concepts</a></span></dt> | ||
30 | <dd><dl> | ||
31 | <dt><span class="section"><a href="user-configuration.html">2.8.1. User Configuration</a></span></dt> | ||
32 | <dt><span class="section"><a href="metadata-machine-configuration-and-policy-configuration.html">2.8.2. Metadata, Machine Configuration, and Policy Configuration</a></span></dt> | ||
33 | <dt><span class="section"><a href="sources-dev-environment.html">2.8.3. Sources</a></span></dt> | ||
34 | <dt><span class="section"><a href="package-feeds-dev-environment.html">2.8.4. Package Feeds</a></span></dt> | ||
35 | <dt><span class="section"><a href="bitbake-dev-environment.html">2.8.5. BitBake</a></span></dt> | ||
36 | <dt><span class="section"><a href="images-dev-environment.html">2.8.6. Images</a></span></dt> | ||
37 | <dt><span class="section"><a href="sdk-dev-environment.html">2.8.7. Application Development SDK</a></span></dt> | ||
38 | </dl></dd> | ||
39 | </dl> | ||
40 | </div> | ||
41 | <p> | ||
42 | This chapter takes a look at the Yocto Project development | ||
43 | environment and also provides a detailed look at what goes on during | ||
44 | development in that environment. | ||
45 | The chapter provides Yocto Project Development environment concepts that | ||
46 | help you understand how work is accomplished in an open source environment, | ||
47 | which is very different as compared to work accomplished in a closed, | ||
48 | proprietary environment. | ||
49 | </p> | ||
50 | <p> | ||
51 | Specifically, this chapter addresses open source philosophy, workflows, | ||
52 | Git, source repositories, licensing, recipe syntax, and development | ||
53 | syntax. | ||
54 | </p> | ||
55 | </div></body> | ||
56 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-licenses.html b/documentation/getting-started/eclipse/html/getting-started/overview-licenses.html deleted file mode 100644 index eca1f71d2d..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/overview-licenses.html +++ /dev/null | |||
@@ -1,29 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.7. Licenses</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="running-weston.html" title="3.6.3. Running Weston"> | ||
10 | <link rel="next" href="usingpoky-configuring-LIC_FILES_CHKSUM.html" title="3.7.1. Tracking License Changes"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7. Licenses"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="overview-licenses"></a>3.7. Licenses</h2></div></div></div> | ||
15 | <p> | ||
16 | This section describes the mechanism by which the OpenEmbedded | ||
17 | build system tracks changes to licensing text. | ||
18 | The section also describes how to enable commercially licensed | ||
19 | recipes, which by default are disabled. | ||
20 | </p> | ||
21 | <p> | ||
22 | For information that can help you maintain compliance with | ||
23 | various open source licensing during the lifecycle of the product, | ||
24 | see the | ||
25 | "<a class="link" href="../dev-manual/maintaining-open-source-license-compliance-during-your-products-lifecycle.html" target="_self">Maintaining Open Source License Compliance During Your Project's Lifecycle</a>" | ||
26 | section in the Yocto Project Development Tasks Manual. | ||
27 | </p> | ||
28 | </div></body> | ||
29 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-manual-intro.html b/documentation/getting-started/eclipse/html/getting-started/overview-manual-intro.html deleted file mode 100644 index ab4e1f338f..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/overview-manual-intro.html +++ /dev/null | |||
@@ -1,23 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>Chapter 1. The Yocto Project Overview Manual</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="index.html" title="Getting Started With Yocto Project"> | ||
9 | <link rel="prev" href="index.html" title="Getting Started With Yocto Project"> | ||
10 | <link rel="next" href="overview-welcome.html" title="1.1. Welcome"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="chapter" title="Chapter 1. The Yocto Project Overview Manual"> | ||
13 | <div class="titlepage"><div><div><h2 class="title"> | ||
14 | <a name="overview-manual-intro"></a>Chapter 1. The Yocto Project Overview Manual</h2></div></div></div> | ||
15 | <div class="toc"> | ||
16 | <p><b>Table of Contents</b></p> | ||
17 | <dl> | ||
18 | <dt><span class="section"><a href="overview-welcome.html">1.1. Welcome</a></span></dt> | ||
19 | <dt><span class="section"><a href="overview-other-information.html">1.2. Other Information</a></span></dt> | ||
20 | </dl> | ||
21 | </div> | ||
22 | </div></body> | ||
23 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-other-information.html b/documentation/getting-started/eclipse/html/getting-started/overview-other-information.html deleted file mode 100644 index 03210c6ebf..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/overview-other-information.html +++ /dev/null | |||
@@ -1,31 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>1.2. Other Information</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-manual-intro.html" title="Chapter 1. The Yocto Project Overview Manual"> | ||
9 | <link rel="prev" href="overview-welcome.html" title="1.1. Welcome"> | ||
10 | <link rel="next" href="overview-development-environment.html" title="Chapter 2. The Yocto Project Development Environment"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.2. Other Information"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="overview-other-information"></a>1.2. Other Information</h2></div></div></div> | ||
15 | <p> | ||
16 | Because this manual presents information for many different | ||
17 | topics, supplemental information is recommended for full | ||
18 | comprehension. | ||
19 | For additional introductory information on the Yocto Project, see | ||
20 | the <a class="ulink" href="http://www.yoctoproject.org" target="_self">Yocto Project Website</a>. | ||
21 | You can find an introductory to using the Yocto Project by working | ||
22 | through the | ||
23 | <a class="link" href="../yocto-project-qs/index.html" target="_self">Yocto Project Quick Start</a>. | ||
24 | </p> | ||
25 | <p> | ||
26 | For a comprehensive list of links and other documentation, see the | ||
27 | "<a class="link" href="../ref-manual/resources-links-and-related-documentation.html" target="_self">Links and Related Documentation</a>" | ||
28 | section in the Yocto Project Reference Manual. | ||
29 | </p> | ||
30 | </div></body> | ||
31 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/overview-welcome.html b/documentation/getting-started/eclipse/html/getting-started/overview-welcome.html deleted file mode 100644 index 1bc34e081c..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/overview-welcome.html +++ /dev/null | |||
@@ -1,85 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>1.1. Welcome</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-manual-intro.html" title="Chapter 1. The Yocto Project Overview Manual"> | ||
9 | <link rel="prev" href="overview-manual-intro.html" title="Chapter 1. The Yocto Project Overview Manual"> | ||
10 | <link rel="next" href="overview-other-information.html" title="1.2. Other Information"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="1.1. Welcome"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="overview-welcome"></a>1.1. Welcome</h2></div></div></div> | ||
15 | <p> | ||
16 | Welcome to the Yocto Project Overview Manual! | ||
17 | This manual introduces the Yocto Project by providing concepts, | ||
18 | software overviews, best-known-methods (BKMs), and any other | ||
19 | high-level introductory information suitable for a new Yocto | ||
20 | Project user. | ||
21 | </p> | ||
22 | <p> | ||
23 | The following list describes what you can get from this manual: | ||
24 | </p> | ||
25 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
26 | <li class="listitem"><p> | ||
27 | <span class="emphasis"><em>Major Topic:</em></span> | ||
28 | Provide a high-level description of this major topic. | ||
29 | </p></li> | ||
30 | <li class="listitem"><p> | ||
31 | <span class="emphasis"><em>Major Topic:</em></span> | ||
32 | Provide a high-level description of this major topic. | ||
33 | </p></li> | ||
34 | <li class="listitem"><p> | ||
35 | <span class="emphasis"><em>Major Topic:</em></span> | ||
36 | Provide a high-level description of this major topic. | ||
37 | </p></li> | ||
38 | <li class="listitem"><p> | ||
39 | <span class="emphasis"><em>Major Topic:</em></span> | ||
40 | Provide a high-level description of this major topic. | ||
41 | </p></li> | ||
42 | </ul></div> | ||
43 | <p> | ||
44 | </p> | ||
45 | <p> | ||
46 | This manual does not give you the following: | ||
47 | </p> | ||
48 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
49 | <li class="listitem"><p> | ||
50 | <span class="emphasis"><em>Step-by-step Instructions for Development Tasks:</em></span> | ||
51 | Instructional procedures reside in other manuals within | ||
52 | the Yocto Project documentation set. | ||
53 | For example, the | ||
54 | <a class="link" href="../dev-manual/index.html" target="_self">Yocto Project Development Tasks Manual</a> | ||
55 | provides examples on how to perform various development | ||
56 | tasks. | ||
57 | As another example, the | ||
58 | <a class="link" href="../sdk-manual/index.html" target="_self">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a> | ||
59 | manual contains detailed instructions on how to install an | ||
60 | SDK, which is used to develop applications for target | ||
61 | hardware. | ||
62 | </p></li> | ||
63 | <li class="listitem"><p> | ||
64 | <span class="emphasis"><em>Reference Material:</em></span> | ||
65 | This type of material resides in an appropriate reference | ||
66 | manual. | ||
67 | For example, system variables are documented in the | ||
68 | <a class="link" href="../ref-manual/index.html" target="_self">Yocto Project Reference Manual</a>. | ||
69 | As another example, the | ||
70 | <a class="link" href="../bsp-guide/index.html" target="_self">Yocto Project Board Support Package (BSP) Developer's Guide</a> | ||
71 | contains reference information on BSPs. | ||
72 | </p></li> | ||
73 | <li class="listitem"><p> | ||
74 | <span class="emphasis"><em>Detailed Public Information Not Specific to the | ||
75 | Yocto Project:</em></span> | ||
76 | For example, exhaustive information on how to use the | ||
77 | Source Control Manager Git is better covered with Internet | ||
78 | searches and official Git Documentation than through the | ||
79 | Yocto Project documentation. | ||
80 | </p></li> | ||
81 | </ul></div> | ||
82 | <p> | ||
83 | </p> | ||
84 | </div></body> | ||
85 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/package-feeds-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/package-feeds-dev-environment.html deleted file mode 100644 index ad3d67f660..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/package-feeds-dev-environment.html +++ /dev/null | |||
@@ -1,98 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.4. Package Feeds</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="development-concepts.html" title="2.8. Development Concepts"> | ||
9 | <link rel="prev" href="source-mirrors.html" title="2.8.3.4. Source Mirror(s)"> | ||
10 | <link rel="next" href="bitbake-dev-environment.html" title="2.8.5. BitBake"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.4. Package Feeds"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="package-feeds-dev-environment"></a>2.8.4. Package Feeds</h3></div></div></div> | ||
15 | <p> | ||
16 | When the OpenEmbedded build system generates an image or an SDK, | ||
17 | it gets the packages from a package feed area located in the | ||
18 | <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>. | ||
19 | The | ||
20 | <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a> | ||
21 | shows this package feeds area in the upper-right corner. | ||
22 | </p> | ||
23 | <p> | ||
24 | This section looks a little closer into the package feeds area used | ||
25 | by the build system. | ||
26 | Here is a more detailed look at the area: | ||
27 | </p> | ||
28 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 540px"><td align="center"><img src="figures/package-feeds.png" align="middle" width="630"></td></tr></table> | ||
29 | <p> | ||
30 | </p> | ||
31 | <p> | ||
32 | Package feeds are an intermediary step in the build process. | ||
33 | The OpenEmbedded build system provides classes to generate | ||
34 | different package types, and you specify which classes to enable | ||
35 | through the | ||
36 | <a class="link" href="../ref-manual/var-PACKAGE_CLASSES.html" target="_self"><code class="filename">PACKAGE_CLASSES</code></a> | ||
37 | variable. | ||
38 | Before placing the packages into package feeds, | ||
39 | the build process validates them with generated output quality | ||
40 | assurance checks through the | ||
41 | <a class="link" href="../ref-manual/ref-classes-insane.html" target="_self"><code class="filename">insane</code></a> | ||
42 | class. | ||
43 | </p> | ||
44 | <p> | ||
45 | The package feed area resides in the Build Directory. | ||
46 | The directory the build system uses to temporarily store packages | ||
47 | is determined by a combination of variables and the particular | ||
48 | package manager in use. | ||
49 | See the "Package Feeds" box in the illustration and note the | ||
50 | information to the right of that area. | ||
51 | In particular, the following defines where package files are | ||
52 | kept: | ||
53 | </p> | ||
54 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
55 | <li class="listitem"><p><a class="link" href="../ref-manual/var-DEPLOY_DIR.html" target="_self"><code class="filename">DEPLOY_DIR</code></a>: | ||
56 | Defined as <code class="filename">tmp/deploy</code> in the Build | ||
57 | Directory. | ||
58 | </p></li> | ||
59 | <li class="listitem"><p><code class="filename">DEPLOY_DIR_*</code>: | ||
60 | Depending on the package manager used, the package type | ||
61 | sub-folder. | ||
62 | Given RPM, IPK, or DEB packaging and tarball creation, the | ||
63 | <a class="link" href="../ref-manual/var-DEPLOY_DIR_RPM.html" target="_self"><code class="filename">DEPLOY_DIR_RPM</code></a>, | ||
64 | <a class="link" href="../ref-manual/var-DEPLOY_DIR_IPK.html" target="_self"><code class="filename">DEPLOY_DIR_IPK</code></a>, | ||
65 | <a class="link" href="../ref-manual/var-DEPLOY_DIR_DEB.html" target="_self"><code class="filename">DEPLOY_DIR_DEB</code></a>, | ||
66 | or | ||
67 | <a class="link" href="../ref-manual/var-DEPLOY_DIR_TAR.html" target="_self"><code class="filename">DEPLOY_DIR_TAR</code></a>, | ||
68 | variables are used, respectively. | ||
69 | </p></li> | ||
70 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PACKAGE_ARCH.html" target="_self"><code class="filename">PACKAGE_ARCH</code></a>: | ||
71 | Defines architecture-specific sub-folders. | ||
72 | For example, packages could exist for the i586 or qemux86 | ||
73 | architectures. | ||
74 | </p></li> | ||
75 | </ul></div> | ||
76 | <p> | ||
77 | </p> | ||
78 | <p> | ||
79 | BitBake uses the <code class="filename">do_package_write_*</code> tasks to | ||
80 | generate packages and place them into the package holding area (e.g. | ||
81 | <code class="filename">do_package_write_ipk</code> for IPK packages). | ||
82 | See the | ||
83 | "<a class="link" href="../ref-manual/ref-tasks-package_write_deb.html" target="_self"><code class="filename">do_package_write_deb</code></a>", | ||
84 | "<a class="link" href="../ref-manual/ref-tasks-package_write_ipk.html" target="_self"><code class="filename">do_package_write_ipk</code></a>", | ||
85 | "<a class="link" href="../ref-manual/ref-tasks-package_write_rpm.html" target="_self"><code class="filename">do_package_write_rpm</code></a>", | ||
86 | and | ||
87 | "<a class="link" href="../ref-manual/ref-tasks-package_write_tar.html" target="_self"><code class="filename">do_package_write_tar</code></a>" | ||
88 | sections for additional information. | ||
89 | As an example, consider a scenario where an IPK packaging manager | ||
90 | is being used and package architecture support for both i586 | ||
91 | and qemux86 exist. | ||
92 | Packages for the i586 architecture are placed in | ||
93 | <code class="filename">build/tmp/deploy/ipk/i586</code>, while packages for | ||
94 | the qemux86 architecture are placed in | ||
95 | <code class="filename">build/tmp/deploy/ipk/qemux86</code>. | ||
96 | </p> | ||
97 | </div></body> | ||
98 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/package-splitting-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/package-splitting-dev-environment.html deleted file mode 100644 index 882d66c31c..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/package-splitting-dev-environment.html +++ /dev/null | |||
@@ -1,94 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.5.4. Package Splitting</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="configuration-and-compilation-dev-environment.html" title="2.8.5.3. Configuration and Compilation"> | ||
10 | <link rel="next" href="image-generation-dev-environment.html" title="2.8.5.5. Image Generation"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.4. Package Splitting"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="package-splitting-dev-environment"></a>2.8.5.4. Package Splitting</h4></div></div></div> | ||
15 | <p> | ||
16 | After source code is configured and compiled, the | ||
17 | OpenEmbedded build system analyzes | ||
18 | the results and splits the output into packages: | ||
19 | </p> | ||
20 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 630px"><td align="center"><img src="figures/analysis-for-package-splitting.png" align="middle" width="630"></td></tr></table> | ||
21 | <p> | ||
22 | </p> | ||
23 | <p> | ||
24 | The | ||
25 | <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a> | ||
26 | and | ||
27 | <a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a> | ||
28 | tasks combine to analyze | ||
29 | the files found in the | ||
30 | <a class="link" href="../ref-manual/var-D.html" target="_self"><code class="filename">D</code></a> directory | ||
31 | and split them into subsets based on available packages and | ||
32 | files. | ||
33 | The analyzing process involves the following as well as other | ||
34 | items: splitting out debugging symbols, | ||
35 | looking at shared library dependencies between packages, | ||
36 | and looking at package relationships. | ||
37 | The <code class="filename">do_packagedata</code> task creates package | ||
38 | metadata based on the analysis such that the | ||
39 | OpenEmbedded build system can generate the final packages. | ||
40 | Working, staged, and intermediate results of the analysis | ||
41 | and package splitting process use these areas: | ||
42 | </p> | ||
43 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
44 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PKGD.html" target="_self"><code class="filename">PKGD</code></a> - | ||
45 | The destination directory for packages before they are | ||
46 | split. | ||
47 | </p></li> | ||
48 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PKGDATA_DIR.html" target="_self"><code class="filename">PKGDATA_DIR</code></a> - | ||
49 | A shared, global-state directory that holds data | ||
50 | generated during the packaging process. | ||
51 | </p></li> | ||
52 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PKGDESTWORK.html" target="_self"><code class="filename">PKGDESTWORK</code></a> - | ||
53 | A temporary work area used by the | ||
54 | <code class="filename">do_package</code> task. | ||
55 | </p></li> | ||
56 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PKGDEST.html" target="_self"><code class="filename">PKGDEST</code></a> - | ||
57 | The parent directory for packages after they have | ||
58 | been split. | ||
59 | </p></li> | ||
60 | </ul></div> | ||
61 | <p> | ||
62 | The <a class="link" href="../ref-manual/var-FILES.html" target="_self"><code class="filename">FILES</code></a> | ||
63 | variable defines the files that go into each package in | ||
64 | <a class="link" href="../ref-manual/var-PACKAGES.html" target="_self"><code class="filename">PACKAGES</code></a>. | ||
65 | If you want details on how this is accomplished, you can | ||
66 | look at the | ||
67 | <a class="link" href="../ref-manual/ref-classes-package.html" target="_self"><code class="filename">package</code></a> | ||
68 | class. | ||
69 | </p> | ||
70 | <p> | ||
71 | Depending on the type of packages being created (RPM, DEB, or | ||
72 | IPK), the <code class="filename">do_package_write_*</code> task | ||
73 | creates the actual packages and places them in the | ||
74 | Package Feed area, which is | ||
75 | <code class="filename">${TMPDIR}/deploy</code>. | ||
76 | You can see the | ||
77 | "<a class="link" href="package-feeds-dev-environment.html" title="2.8.4. Package Feeds">Package Feeds</a>" | ||
78 | section for more detail on that part of the build process. | ||
79 | </p> | ||
80 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
81 | <h3 class="title">Note</h3> | ||
82 | Support for creating feeds directly from the | ||
83 | <code class="filename">deploy/*</code> directories does not exist. | ||
84 | Creating such feeds usually requires some kind of feed | ||
85 | maintenance mechanism that would upload the new packages | ||
86 | into an official package feed (e.g. the | ||
87 | Ångström distribution). | ||
88 | This functionality is highly distribution-specific | ||
89 | and thus is not provided out of the box. | ||
90 | </div> | ||
91 | <p> | ||
92 | </p> | ||
93 | </div></body> | ||
94 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/patching-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/patching-dev-environment.html deleted file mode 100644 index 60ae6b020b..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/patching-dev-environment.html +++ /dev/null | |||
@@ -1,48 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.5.2. Patching</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="source-fetching-dev-environment.html" title="2.8.5.1. Source Fetching"> | ||
10 | <link rel="next" href="configuration-and-compilation-dev-environment.html" title="2.8.5.3. Configuration and Compilation"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.2. Patching"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="patching-dev-environment"></a>2.8.5.2. Patching</h4></div></div></div> | ||
15 | <p> | ||
16 | Once source code is fetched and unpacked, BitBake locates | ||
17 | patch files and applies them to the source files: | ||
18 | </p> | ||
19 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 450px"><td align="center"><img src="figures/patching.png" align="middle" width="540"></td></tr></table> | ||
20 | <p> | ||
21 | </p> | ||
22 | <p> | ||
23 | The | ||
24 | <a class="link" href="../ref-manual/ref-tasks-patch.html" target="_self"><code class="filename">do_patch</code></a> | ||
25 | task processes recipes by | ||
26 | using the | ||
27 | <a class="link" href="../ref-manual/var-SRC_URI.html" target="_self"><code class="filename">SRC_URI</code></a> | ||
28 | variable to locate applicable patch files, which by default | ||
29 | are <code class="filename">*.patch</code> or | ||
30 | <code class="filename">*.diff</code> files, or any file if | ||
31 | "apply=yes" is specified for the file in | ||
32 | <code class="filename">SRC_URI</code>. | ||
33 | </p> | ||
34 | <p> | ||
35 | BitBake finds and applies multiple patches for a single recipe | ||
36 | in the order in which it finds the patches. | ||
37 | Patches are applied to the recipe's source files located in the | ||
38 | <a class="link" href="../ref-manual/var-S.html" target="_self"><code class="filename">S</code></a> | ||
39 | directory. | ||
40 | </p> | ||
41 | <p> | ||
42 | For more information on how the source directories are | ||
43 | created, see the | ||
44 | "<a class="link" href="source-fetching-dev-environment.html" title="2.8.5.1. Source Fetching">Source Fetching</a>" | ||
45 | section. | ||
46 | </p> | ||
47 | </div></body> | ||
48 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/recipe-syntax.html b/documentation/getting-started/eclipse/html/getting-started/recipe-syntax.html deleted file mode 100644 index fcf46d9d35..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/recipe-syntax.html +++ /dev/null | |||
@@ -1,383 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.7. Recipe Syntax</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-development-environment.html" title="Chapter 2. The Yocto Project Development Environment"> | ||
9 | <link rel="prev" href="licensing.html" title="2.6. Licensing"> | ||
10 | <link rel="next" href="development-concepts.html" title="2.8. Development Concepts"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.7. Recipe Syntax"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="recipe-syntax"></a>2.7. Recipe Syntax</h2></div></div></div> | ||
15 | <p> | ||
16 | Understanding recipe file syntax is important for | ||
17 | writing recipes. | ||
18 | The following list overviews the basic items that make up a | ||
19 | BitBake recipe file. | ||
20 | For more complete BitBake syntax descriptions, see the | ||
21 | "<a class="link" href="../bitbake-user-manual/bitbake-user-manual-metadata.html" target="_self">Syntax and Operators</a>" | ||
22 | chapter of the BitBake User Manual. | ||
23 | </p> | ||
24 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
25 | <li class="listitem"> | ||
26 | <p><span class="emphasis"><em>Variable Assignments and Manipulations:</em></span> | ||
27 | Variable assignments allow a value to be assigned to a | ||
28 | variable. | ||
29 | The assignment can be static text or might include | ||
30 | the contents of other variables. | ||
31 | In addition to the assignment, appending and prepending | ||
32 | operations are also supported.</p> | ||
33 | <p>The following example shows some of the ways | ||
34 | you can use variables in recipes: | ||
35 | </p> | ||
36 | <pre class="literallayout"> | ||
37 | S = "${WORKDIR}/postfix-${PV}" | ||
38 | CFLAGS += "-DNO_ASM" | ||
39 | SRC_URI_append = " file://fixup.patch" | ||
40 | </pre> | ||
41 | <p> | ||
42 | </p> | ||
43 | </li> | ||
44 | <li class="listitem"> | ||
45 | <p><span class="emphasis"><em>Functions:</em></span> | ||
46 | Functions provide a series of actions to be performed. | ||
47 | You usually use functions to override the default | ||
48 | implementation of a task function or to complement | ||
49 | a default function (i.e. append or prepend to an | ||
50 | existing function). | ||
51 | Standard functions use <code class="filename">sh</code> shell | ||
52 | syntax, although access to OpenEmbedded variables and | ||
53 | internal methods are also available.</p> | ||
54 | <p>The following is an example function from the | ||
55 | <code class="filename">sed</code> recipe: | ||
56 | </p> | ||
57 | <pre class="literallayout"> | ||
58 | do_install () { | ||
59 | autotools_do_install | ||
60 | install -d ${D}${base_bindir} | ||
61 | mv ${D}${bindir}/sed ${D}${base_bindir}/sed | ||
62 | rmdir ${D}${bindir}/ | ||
63 | } | ||
64 | </pre> | ||
65 | <p> | ||
66 | It is also possible to implement new functions that | ||
67 | are called between existing tasks as long as the | ||
68 | new functions are not replacing or complementing the | ||
69 | default functions. | ||
70 | You can implement functions in Python | ||
71 | instead of shell. | ||
72 | Both of these options are not seen in the majority of | ||
73 | recipes.</p> | ||
74 | </li> | ||
75 | <li class="listitem"> | ||
76 | <p><span class="emphasis"><em>Keywords:</em></span> | ||
77 | BitBake recipes use only a few keywords. | ||
78 | You use keywords to include common | ||
79 | functions (<code class="filename">inherit</code>), load parts | ||
80 | of a recipe from other files | ||
81 | (<code class="filename">include</code> and | ||
82 | <code class="filename">require</code>) and export variables | ||
83 | to the environment (<code class="filename">export</code>).</p> | ||
84 | <p>The following example shows the use of some of | ||
85 | these keywords: | ||
86 | </p> | ||
87 | <pre class="literallayout"> | ||
88 | export POSTCONF = "${STAGING_BINDIR}/postconf" | ||
89 | inherit autoconf | ||
90 | require otherfile.inc | ||
91 | </pre> | ||
92 | <p> | ||
93 | </p> | ||
94 | </li> | ||
95 | <li class="listitem"> | ||
96 | <p><span class="emphasis"><em>Comments:</em></span> | ||
97 | Any lines that begin with the hash character | ||
98 | (<code class="filename">#</code>) are treated as comment lines | ||
99 | and are ignored: | ||
100 | </p> | ||
101 | <pre class="literallayout"> | ||
102 | # This is a comment | ||
103 | </pre> | ||
104 | <p> | ||
105 | </p> | ||
106 | </li> | ||
107 | </ul></div> | ||
108 | <p> | ||
109 | </p> | ||
110 | <p> | ||
111 | This next list summarizes the most important and most commonly | ||
112 | used parts of the recipe syntax. | ||
113 | For more information on these parts of the syntax, you can | ||
114 | reference the | ||
115 | <a class="link" href="../bitbake-user-manual/bitbake-user-manual-metadata.html" target="_self">Syntax and Operators</a> | ||
116 | chapter in the BitBake User Manual. | ||
117 | </p> | ||
118 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
119 | <li class="listitem"> | ||
120 | <p><span class="emphasis"><em>Line Continuation: <code class="filename">\</code></em></span> - | ||
121 | Use the backward slash (<code class="filename">\</code>) | ||
122 | character to split a statement over multiple lines. | ||
123 | Place the slash character at the end of the line that | ||
124 | is to be continued on the next line: | ||
125 | </p> | ||
126 | <pre class="literallayout"> | ||
127 | VAR = "A really long \ | ||
128 | line" | ||
129 | </pre> | ||
130 | <p> | ||
131 | </p> | ||
132 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
133 | <h3 class="title">Note</h3> | ||
134 | You cannot have any characters including spaces | ||
135 | or tabs after the slash character. | ||
136 | </div> | ||
137 | <p> | ||
138 | </p> | ||
139 | </li> | ||
140 | <li class="listitem"> | ||
141 | <p> | ||
142 | <span class="emphasis"><em>Using Variables: <code class="filename">${...}</code></em></span> - | ||
143 | Use the <code class="filename">${<em class="replaceable"><code>VARNAME</code></em>}</code> syntax to | ||
144 | access the contents of a variable: | ||
145 | </p> | ||
146 | <pre class="literallayout"> | ||
147 | SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/zlib-${PV}.tar.gz" | ||
148 | </pre> | ||
149 | <p> | ||
150 | </p> | ||
151 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
152 | <h3 class="title">Note</h3> | ||
153 | It is important to understand that the value of a | ||
154 | variable expressed in this form does not get | ||
155 | substituted automatically. | ||
156 | The expansion of these expressions happens | ||
157 | on-demand later (e.g. usually when a function that | ||
158 | makes reference to the variable executes). | ||
159 | This behavior ensures that the values are most | ||
160 | appropriate for the context in which they are | ||
161 | finally used. | ||
162 | On the rare occasion that you do need the variable | ||
163 | expression to be expanded immediately, you can use | ||
164 | the <code class="filename">:=</code> operator instead of | ||
165 | <code class="filename">=</code> when you make the | ||
166 | assignment, but this is not generally needed. | ||
167 | </div> | ||
168 | <p> | ||
169 | </p> | ||
170 | </li> | ||
171 | <li class="listitem"> | ||
172 | <p><span class="emphasis"><em>Quote All Assignments: <code class="filename">"<em class="replaceable"><code>value</code></em>"</code></em></span> - | ||
173 | Use double quotes around the value in all variable | ||
174 | assignments. | ||
175 | </p> | ||
176 | <pre class="literallayout"> | ||
177 | VAR1 = "${OTHERVAR}" | ||
178 | VAR2 = "The version is ${PV}" | ||
179 | </pre> | ||
180 | <p> | ||
181 | </p> | ||
182 | </li> | ||
183 | <li class="listitem"> | ||
184 | <p><span class="emphasis"><em>Conditional Assignment: <code class="filename">?=</code></em></span> - | ||
185 | Conditional assignment is used to assign a value to | ||
186 | a variable, but only when the variable is currently | ||
187 | unset. | ||
188 | Use the question mark followed by the equal sign | ||
189 | (<code class="filename">?=</code>) to make a "soft" assignment | ||
190 | used for conditional assignment. | ||
191 | Typically, "soft" assignments are used in the | ||
192 | <code class="filename">local.conf</code> file for variables | ||
193 | that are allowed to come through from the external | ||
194 | environment. | ||
195 | </p> | ||
196 | <p>Here is an example where | ||
197 | <code class="filename">VAR1</code> is set to "New value" if | ||
198 | it is currently empty. | ||
199 | However, if <code class="filename">VAR1</code> has already been | ||
200 | set, it remains unchanged: | ||
201 | </p> | ||
202 | <pre class="literallayout"> | ||
203 | VAR1 ?= "New value" | ||
204 | </pre> | ||
205 | <p> | ||
206 | In this next example, <code class="filename">VAR1</code> | ||
207 | is left with the value "Original value": | ||
208 | </p> | ||
209 | <pre class="literallayout"> | ||
210 | VAR1 = "Original value" | ||
211 | VAR1 ?= "New value" | ||
212 | </pre> | ||
213 | <p> | ||
214 | </p> | ||
215 | </li> | ||
216 | <li class="listitem"> | ||
217 | <p><span class="emphasis"><em>Appending: <code class="filename">+=</code></em></span> - | ||
218 | Use the plus character followed by the equals sign | ||
219 | (<code class="filename">+=</code>) to append values to existing | ||
220 | variables. | ||
221 | </p> | ||
222 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
223 | <h3 class="title">Note</h3> | ||
224 | This operator adds a space between the existing | ||
225 | content of the variable and the new content. | ||
226 | </div> | ||
227 | <p>Here is an example: | ||
228 | </p> | ||
229 | <pre class="literallayout"> | ||
230 | SRC_URI += "file://fix-makefile.patch" | ||
231 | </pre> | ||
232 | <p> | ||
233 | </p> | ||
234 | </li> | ||
235 | <li class="listitem"> | ||
236 | <p><span class="emphasis"><em>Prepending: <code class="filename">=+</code></em></span> - | ||
237 | Use the equals sign followed by the plus character | ||
238 | (<code class="filename">=+</code>) to prepend values to existing | ||
239 | variables. | ||
240 | </p> | ||
241 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
242 | <h3 class="title">Note</h3> | ||
243 | This operator adds a space between the new content | ||
244 | and the existing content of the variable. | ||
245 | </div> | ||
246 | <p>Here is an example: | ||
247 | </p> | ||
248 | <pre class="literallayout"> | ||
249 | VAR =+ "Starts" | ||
250 | </pre> | ||
251 | <p> | ||
252 | </p> | ||
253 | </li> | ||
254 | <li class="listitem"> | ||
255 | <p><span class="emphasis"><em>Appending: <code class="filename">_append</code></em></span> - | ||
256 | Use the <code class="filename">_append</code> operator to | ||
257 | append values to existing variables. | ||
258 | This operator does not add any additional space. | ||
259 | Also, the operator is applied after all the | ||
260 | <code class="filename">+=</code>, and | ||
261 | <code class="filename">=+</code> operators have been applied and | ||
262 | after all <code class="filename">=</code> assignments have | ||
263 | occurred. | ||
264 | </p> | ||
265 | <p>The following example shows the space being | ||
266 | explicitly added to the start to ensure the appended | ||
267 | value is not merged with the existing value: | ||
268 | </p> | ||
269 | <pre class="literallayout"> | ||
270 | SRC_URI_append = " file://fix-makefile.patch" | ||
271 | </pre> | ||
272 | <p> | ||
273 | You can also use the <code class="filename">_append</code> | ||
274 | operator with overrides, which results in the actions | ||
275 | only being performed for the specified target or | ||
276 | machine: | ||
277 | </p> | ||
278 | <pre class="literallayout"> | ||
279 | SRC_URI_append_sh4 = " file://fix-makefile.patch" | ||
280 | </pre> | ||
281 | <p> | ||
282 | </p> | ||
283 | </li> | ||
284 | <li class="listitem"> | ||
285 | <p><span class="emphasis"><em>Prepending: <code class="filename">_prepend</code></em></span> - | ||
286 | Use the <code class="filename">_prepend</code> operator to | ||
287 | prepend values to existing variables. | ||
288 | This operator does not add any additional space. | ||
289 | Also, the operator is applied after all the | ||
290 | <code class="filename">+=</code>, and | ||
291 | <code class="filename">=+</code> operators have been applied and | ||
292 | after all <code class="filename">=</code> assignments have | ||
293 | occurred. | ||
294 | </p> | ||
295 | <p>The following example shows the space being | ||
296 | explicitly added to the end to ensure the prepended | ||
297 | value is not merged with the existing value: | ||
298 | </p> | ||
299 | <pre class="literallayout"> | ||
300 | CFLAGS_prepend = "-I${S}/myincludes " | ||
301 | </pre> | ||
302 | <p> | ||
303 | You can also use the <code class="filename">_prepend</code> | ||
304 | operator with overrides, which results in the actions | ||
305 | only being performed for the specified target or | ||
306 | machine: | ||
307 | </p> | ||
308 | <pre class="literallayout"> | ||
309 | CFLAGS_prepend_sh4 = "-I${S}/myincludes " | ||
310 | </pre> | ||
311 | <p> | ||
312 | </p> | ||
313 | </li> | ||
314 | <li class="listitem"> | ||
315 | <p><span class="emphasis"><em>Overrides:</em></span> - | ||
316 | You can use overrides to set a value conditionally, | ||
317 | typically based on how the recipe is being built. | ||
318 | For example, to set the | ||
319 | <a class="link" href="../ref-manual/var-KBRANCH.html" target="_self"><code class="filename">KBRANCH</code></a> | ||
320 | variable's value to "standard/base" for any target | ||
321 | <a class="link" href="../ref-manual/var-MACHINE.html" target="_self"><code class="filename">MACHINE</code></a>, | ||
322 | except for qemuarm where it should be set to | ||
323 | "standard/arm-versatile-926ejs", you would do the | ||
324 | following: | ||
325 | </p> | ||
326 | <pre class="literallayout"> | ||
327 | KBRANCH = "standard/base" | ||
328 | KBRANCH_qemuarm = "standard/arm-versatile-926ejs" | ||
329 | </pre> | ||
330 | <p> | ||
331 | Overrides are also used to separate alternate values | ||
332 | of a variable in other situations. | ||
333 | For example, when setting variables such as | ||
334 | <a class="link" href="../ref-manual/var-FILES.html" target="_self"><code class="filename">FILES</code></a> | ||
335 | and | ||
336 | <a class="link" href="../ref-manual/var-RDEPENDS.html" target="_self"><code class="filename">RDEPENDS</code></a> | ||
337 | that are specific to individual packages produced by | ||
338 | a recipe, you should always use an override that | ||
339 | specifies the name of the package. | ||
340 | </p> | ||
341 | </li> | ||
342 | <li class="listitem"><p><span class="emphasis"><em>Indentation:</em></span> | ||
343 | Use spaces for indentation rather than than tabs. | ||
344 | For shell functions, both currently work. | ||
345 | However, it is a policy decision of the Yocto Project | ||
346 | to use tabs in shell functions. | ||
347 | Realize that some layers have a policy to use spaces | ||
348 | for all indentation. | ||
349 | </p></li> | ||
350 | <li class="listitem"> | ||
351 | <p><span class="emphasis"><em>Using Python for Complex Operations: <code class="filename">${@<em class="replaceable"><code>python_code</code></em>}</code></em></span> - | ||
352 | For more advanced processing, it is possible to use | ||
353 | Python code during variable assignments (e.g. | ||
354 | search and replacement on a variable).</p> | ||
355 | <p>You indicate Python code using the | ||
356 | <code class="filename">${@<em class="replaceable"><code>python_code</code></em>}</code> | ||
357 | syntax for the variable assignment: | ||
358 | </p> | ||
359 | <pre class="literallayout"> | ||
360 | SRC_URI = "ftp://ftp.info-zip.org/pub/infozip/src/zip${@d.getVar('PV',1).replace('.', '')}.tgz | ||
361 | </pre> | ||
362 | <p> | ||
363 | </p> | ||
364 | </li> | ||
365 | <li class="listitem"><p><span class="emphasis"><em>Shell Function Syntax:</em></span> | ||
366 | Write shell functions as if you were writing a shell | ||
367 | script when you describe a list of actions to take. | ||
368 | You should ensure that your script works with a generic | ||
369 | <code class="filename">sh</code> and that it does not require | ||
370 | any <code class="filename">bash</code> or other shell-specific | ||
371 | functionality. | ||
372 | The same considerations apply to various system | ||
373 | utilities (e.g. <code class="filename">sed</code>, | ||
374 | <code class="filename">grep</code>, <code class="filename">awk</code>, | ||
375 | and so forth) that you might wish to use. | ||
376 | If in doubt, you should check with multiple | ||
377 | implementations - including those from BusyBox. | ||
378 | </p></li> | ||
379 | </ul></div> | ||
380 | <p> | ||
381 | </p> | ||
382 | </div></body> | ||
383 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/repositories-tags-and-branches.html b/documentation/getting-started/eclipse/html/getting-started/repositories-tags-and-branches.html deleted file mode 100644 index d813948375..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/repositories-tags-and-branches.html +++ /dev/null | |||
@@ -1,173 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.4.1. Repositories, Tags, and Branches</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="git.html" title="2.4. Git"> | ||
9 | <link rel="prev" href="git.html" title="2.4. Git"> | ||
10 | <link rel="next" href="basic-commands.html" title="2.4.2. Basic Commands"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.4.1. Repositories, Tags, and Branches"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="repositories-tags-and-branches"></a>2.4.1. Repositories, Tags, and Branches</h3></div></div></div> | ||
15 | <p> | ||
16 | As mentioned briefly in the previous section and also in the | ||
17 | "<a class="link" href="workflows.html" title="2.3. Workflows">Workflows</a>" section, | ||
18 | the Yocto Project maintains source repositories at | ||
19 | <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi" target="_self">http://git.yoctoproject.org/cgit.cgi</a>. | ||
20 | If you look at this web-interface of the repositories, each item | ||
21 | is a separate Git repository. | ||
22 | </p> | ||
23 | <p> | ||
24 | Git repositories use branching techniques that track content | ||
25 | change (not files) within a project (e.g. a new feature or updated | ||
26 | documentation). | ||
27 | Creating a tree-like structure based on project divergence allows | ||
28 | for excellent historical information over the life of a project. | ||
29 | This methodology also allows for an environment from which you can | ||
30 | do lots of local experimentation on projects as you develop | ||
31 | changes or new features. | ||
32 | </p> | ||
33 | <p> | ||
34 | A Git repository represents all development efforts for a given | ||
35 | project. | ||
36 | For example, the Git repository <code class="filename">poky</code> contains | ||
37 | all changes and developments for Poky over the course of its | ||
38 | entire life. | ||
39 | That means that all changes that make up all releases are captured. | ||
40 | The repository maintains a complete history of changes. | ||
41 | </p> | ||
42 | <p> | ||
43 | You can create a local copy of any repository by "cloning" it | ||
44 | with the <code class="filename">git clone</code> command. | ||
45 | When you clone a Git repository, you end up with an identical | ||
46 | copy of the repository on your development system. | ||
47 | Once you have a local copy of a repository, you can take steps to | ||
48 | develop locally. | ||
49 | For examples on how to clone Git repositories, see the | ||
50 | "<a class="link" href="../dev-manual/working-with-yocto-project-source-files.html" target="_self">Working With Yocto Project Source Files</a>" | ||
51 | section in the Yocto Project Development Tasks Manual. | ||
52 | </p> | ||
53 | <p> | ||
54 | It is important to understand that Git tracks content change and | ||
55 | not files. | ||
56 | Git uses "branches" to organize different development efforts. | ||
57 | For example, the <code class="filename">poky</code> repository has | ||
58 | several branches that include the current "sumo" | ||
59 | branch, the "master" branch, and many branches for past | ||
60 | Yocto Project releases. | ||
61 | You can see all the branches by going to | ||
62 | <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/" target="_self">http://git.yoctoproject.org/cgit.cgi/poky/</a> and | ||
63 | clicking on the | ||
64 | <code class="filename"><a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/refs/heads" target="_self">[...]</a></code> | ||
65 | link beneath the "Branch" heading. | ||
66 | </p> | ||
67 | <p> | ||
68 | Each of these branches represents a specific area of development. | ||
69 | The "master" branch represents the current or most recent | ||
70 | development. | ||
71 | All other branches represent offshoots of the "master" branch. | ||
72 | </p> | ||
73 | <p> | ||
74 | When you create a local copy of a Git repository, the copy has | ||
75 | the same set of branches as the original. | ||
76 | This means you can use Git to create a local working area | ||
77 | (also called a branch) that tracks a specific development branch | ||
78 | from the upstream source Git repository. | ||
79 | in other words, you can define your local Git environment to | ||
80 | work on any development branch in the repository. | ||
81 | To help illustrate, consider the following example Git commands: | ||
82 | </p> | ||
83 | <pre class="literallayout"> | ||
84 | $ cd ~ | ||
85 | $ git clone git://git.yoctoproject.org/poky | ||
86 | $ cd poky | ||
87 | $ git checkout -b sumo origin/sumo | ||
88 | </pre> | ||
89 | <p> | ||
90 | In the previous example after moving to the home directory, the | ||
91 | <code class="filename">git clone</code> command creates a | ||
92 | local copy of the upstream <code class="filename">poky</code> Git repository. | ||
93 | By default, Git checks out the "master" branch for your work. | ||
94 | After changing the working directory to the new local repository | ||
95 | (i.e. <code class="filename">poky</code>), the | ||
96 | <code class="filename">git checkout</code> command creates | ||
97 | and checks out a local branch named "sumo", which | ||
98 | tracks the upstream "origin/sumo" branch. | ||
99 | Changes you make while in this branch would ultimately affect | ||
100 | the upstream "sumo" branch of the | ||
101 | <code class="filename">poky</code> repository. | ||
102 | </p> | ||
103 | <p> | ||
104 | It is important to understand that when you create and checkout a | ||
105 | local working branch based on a branch name, | ||
106 | your local environment matches the "tip" of that particular | ||
107 | development branch at the time you created your local branch, | ||
108 | which could be different from the files in the "master" branch | ||
109 | of the upstream repository. | ||
110 | In other words, creating and checking out a local branch based on | ||
111 | the "sumo" branch name is not the same as | ||
112 | cloning and checking out the "master" branch if the repository. | ||
113 | Keep reading to see how you create a local snapshot of a Yocto | ||
114 | Project Release. | ||
115 | </p> | ||
116 | <p> | ||
117 | Git uses "tags" to mark specific changes in a repository. | ||
118 | Typically, a tag is used to mark a special point such as the final | ||
119 | change before a project is released. | ||
120 | You can see the tags used with the <code class="filename">poky</code> Git | ||
121 | repository by going to | ||
122 | <a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/" target="_self">http://git.yoctoproject.org/cgit.cgi/poky/</a> and | ||
123 | clicking on the | ||
124 | <code class="filename"><a class="ulink" href="http://git.yoctoproject.org/cgit.cgi/poky/refs/tags" target="_self">[...]</a></code> | ||
125 | link beneath the "Tag" heading. | ||
126 | </p> | ||
127 | <p> | ||
128 | Some key tags for the <code class="filename">poky</code> are | ||
129 | <code class="filename">jethro-14.0.3</code>, | ||
130 | <code class="filename">morty-16.0.1</code>, | ||
131 | <code class="filename">pyro-17.0.0</code>, and | ||
132 | <code class="filename">sumo-20.0.0</code>. | ||
133 | These tags represent Yocto Project releases. | ||
134 | </p> | ||
135 | <p> | ||
136 | When you create a local copy of the Git repository, you also | ||
137 | have access to all the tags in the upstream repository. | ||
138 | Similar to branches, you can create and checkout a local working | ||
139 | Git branch based on a tag name. | ||
140 | When you do this, you get a snapshot of the Git repository that | ||
141 | reflects the state of the files when the change was made associated | ||
142 | with that tag. | ||
143 | The most common use is to checkout a working branch that matches | ||
144 | a specific Yocto Project release. | ||
145 | Here is an example: | ||
146 | </p> | ||
147 | <pre class="literallayout"> | ||
148 | $ cd ~ | ||
149 | $ git clone git://git.yoctoproject.org/poky | ||
150 | $ cd poky | ||
151 | $ git fetch --all --tags --prune | ||
152 | $ git checkout tags/pyro-17.0.0 -b my-pyro-17.0.0 | ||
153 | </pre> | ||
154 | <p> | ||
155 | In this example, the name of the top-level directory of your | ||
156 | local Yocto Project repository is <code class="filename">poky</code>. | ||
157 | After moving to the <code class="filename">poky</code> directory, the | ||
158 | <code class="filename">git fetch</code> command makes all the upstream | ||
159 | tags available locally in your repository. | ||
160 | Finally, the <code class="filename">git checkout</code> command | ||
161 | creates and checks out a branch named "my-pyro-17.0.0" that is | ||
162 | based on the specific change upstream in the repository | ||
163 | associated with the "pyro-17.0.0" tag. | ||
164 | The files in your repository now exactly match that particular | ||
165 | Yocto Project release as it is tagged in the upstream Git | ||
166 | repository. | ||
167 | It is important to understand that when you create and | ||
168 | checkout a local working branch based on a tag, your environment | ||
169 | matches a specific point in time and not the entire development | ||
170 | branch (i.e. the "tip" of the branch). | ||
171 | </p> | ||
172 | </div></body> | ||
173 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/running-weston.html b/documentation/getting-started/eclipse/html/getting-started/running-weston.html deleted file mode 100644 index b68f574134..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/running-weston.html +++ /dev/null | |||
@@ -1,53 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.6.3. Running Weston</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="wayland.html" title="3.6. Wayland"> | ||
9 | <link rel="prev" href="enable-installation-in-an-image.html" title="3.6.2.2. Installing"> | ||
10 | <link rel="next" href="overview-licenses.html" title="3.7. Licenses"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.3. Running Weston"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="running-weston"></a>3.6.3. Running Weston</h3></div></div></div> | ||
15 | <p> | ||
16 | To run Weston inside X11, enabling it as described earlier and | ||
17 | building a Sato image is sufficient. | ||
18 | If you are running your image under Sato, a Weston Launcher | ||
19 | appears in the "Utility" category. | ||
20 | </p> | ||
21 | <p> | ||
22 | Alternatively, you can run Weston through the command-line | ||
23 | interpretor (CLI), which is better suited for development work. | ||
24 | To run Weston under the CLI, you need to do the following after | ||
25 | your image is built: | ||
26 | </p> | ||
27 | <div class="orderedlist"><ol class="orderedlist" type="1"> | ||
28 | <li class="listitem"> | ||
29 | <p> | ||
30 | Run these commands to export | ||
31 | <code class="filename">XDG_RUNTIME_DIR</code>: | ||
32 | </p> | ||
33 | <pre class="literallayout"> | ||
34 | mkdir -p /tmp/$USER-weston | ||
35 | chmod 0700 /tmp/$USER-weston | ||
36 | export XDG_RUNTIME_DIR=/tmp/$USER-weston | ||
37 | </pre> | ||
38 | <p> | ||
39 | </p> | ||
40 | </li> | ||
41 | <li class="listitem"> | ||
42 | <p> | ||
43 | Launch Weston in the shell: | ||
44 | </p> | ||
45 | <pre class="literallayout"> | ||
46 | weston | ||
47 | </pre> | ||
48 | </li> | ||
49 | </ol></div> | ||
50 | <p> | ||
51 | </p> | ||
52 | </div></body> | ||
53 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/scms.html b/documentation/getting-started/eclipse/html/getting-started/scms.html deleted file mode 100644 index f2ec54340c..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/scms.html +++ /dev/null | |||
@@ -1,42 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.3.3. Source Control Managers (Optional)</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="sources-dev-environment.html" title="2.8.3. Sources"> | ||
9 | <link rel="prev" href="local-projects.html" title="2.8.3.2. Local Projects"> | ||
10 | <link rel="next" href="source-mirrors.html" title="2.8.3.4. Source Mirror(s)"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.3.3. Source Control Managers (Optional)"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="scms"></a>2.8.3.3. Source Control Managers (Optional)</h4></div></div></div> | ||
15 | <p> | ||
16 | Another place the build system can get source files from is | ||
17 | through an SCM such as Git or Subversion. | ||
18 | In this case, a repository is cloned or checked out. | ||
19 | The | ||
20 | <a class="link" href="../ref-manual/ref-tasks-fetch.html" target="_self"><code class="filename">do_fetch</code></a> | ||
21 | task inside BitBake uses | ||
22 | the <a class="link" href="../ref-manual/var-SRC_URI.html" target="_self"><code class="filename">SRC_URI</code></a> | ||
23 | variable and the argument's prefix to determine the correct | ||
24 | fetcher module. | ||
25 | </p> | ||
26 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
27 | <h3 class="title">Note</h3> | ||
28 | For information on how to have the OpenEmbedded build system | ||
29 | generate tarballs for Git repositories and place them in the | ||
30 | <a class="link" href="../ref-manual/var-DL_DIR.html" target="_self"><code class="filename">DL_DIR</code></a> | ||
31 | directory, see the | ||
32 | <a class="link" href="../ref-manual/var-BB_GENERATE_MIRROR_TARBALLS.html" target="_self"><code class="filename">BB_GENERATE_MIRROR_TARBALLS</code></a> | ||
33 | variable. | ||
34 | </div> | ||
35 | <p> | ||
36 | When fetching a repository, BitBake uses the | ||
37 | <a class="link" href="../ref-manual/var-SRCREV.html" target="_self"><code class="filename">SRCREV</code></a> | ||
38 | variable to determine the specific revision from which to | ||
39 | build. | ||
40 | </p> | ||
41 | </div></body> | ||
42 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/sdk-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/sdk-dev-environment.html deleted file mode 100644 index d2cd6a480e..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/sdk-dev-environment.html +++ /dev/null | |||
@@ -1,150 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.7. Application Development SDK</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="development-concepts.html" title="2.8. Development Concepts"> | ||
9 | <link rel="prev" href="images-dev-environment.html" title="2.8.6. Images"> | ||
10 | <link rel="next" href="overview-concepts.html" title="Chapter 3. Yocto Project Concepts"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.7. Application Development SDK"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="sdk-dev-environment"></a>2.8.7. Application Development SDK</h3></div></div></div> | ||
15 | <p> | ||
16 | In the | ||
17 | <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>, | ||
18 | the output labeled "Application Development SDK" represents an | ||
19 | SDK. | ||
20 | The SDK generation process differs depending on whether you build | ||
21 | a standard SDK | ||
22 | (e.g. <code class="filename">bitbake -c populate_sdk</code> <em class="replaceable"><code>imagename</code></em>) | ||
23 | or an extensible SDK | ||
24 | (e.g. <code class="filename">bitbake -c populate_sdk_ext</code> <em class="replaceable"><code>imagename</code></em>). | ||
25 | This section is going to take a closer look at this output: | ||
26 | </p> | ||
27 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="810"><tr style="height: 653px"><td align="center"><img src="figures/sdk.png" align="middle" width="810"></td></tr></table> | ||
28 | <p> | ||
29 | </p> | ||
30 | <p> | ||
31 | The specific form of this output is a self-extracting | ||
32 | SDK installer (<code class="filename">*.sh</code>) that, when run, | ||
33 | installs the SDK, which consists of a cross-development | ||
34 | toolchain, a set of libraries and headers, and an SDK | ||
35 | environment setup script. | ||
36 | Running this installer essentially sets up your | ||
37 | cross-development environment. | ||
38 | You can think of the cross-toolchain as the "host" | ||
39 | part because it runs on the SDK machine. | ||
40 | You can think of the libraries and headers as the "target" | ||
41 | part because they are built for the target hardware. | ||
42 | The environment setup script is added so that you can initialize | ||
43 | the environment before using the tools. | ||
44 | </p> | ||
45 | <div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
46 | <h3 class="title">Notes</h3> | ||
47 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
48 | <li class="listitem"><p> | ||
49 | The Yocto Project supports several methods by which you can | ||
50 | set up this cross-development environment. | ||
51 | These methods include downloading pre-built SDK installers | ||
52 | or building and installing your own SDK installer. | ||
53 | </p></li> | ||
54 | <li class="listitem"><p> | ||
55 | For background information on cross-development toolchains | ||
56 | in the Yocto Project development environment, see the | ||
57 | "<a class="link" href="cross-development-toolchain-generation.html" title="3.2. Cross-Development Toolchain Generation">Cross-Development Toolchain Generation</a>" | ||
58 | section. | ||
59 | </p></li> | ||
60 | <li class="listitem"><p> | ||
61 | For information on setting up a cross-development | ||
62 | environment, see the | ||
63 | <a class="link" href="../sdk-manual/index.html" target="_self">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a> | ||
64 | manual. | ||
65 | </p></li> | ||
66 | </ul></div> | ||
67 | </div> | ||
68 | <p> | ||
69 | Once built, the SDK installers are written out to the | ||
70 | <code class="filename">deploy/sdk</code> folder inside the | ||
71 | <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a> | ||
72 | as shown in the figure at the beginning of this section. | ||
73 | Depending on the type of SDK, several variables exist that help | ||
74 | configure these files. | ||
75 | The following list shows the variables associated with a standard | ||
76 | SDK: | ||
77 | </p> | ||
78 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
79 | <li class="listitem"><p><a class="link" href="../ref-manual/var-DEPLOY_DIR.html" target="_self"><code class="filename">DEPLOY_DIR</code></a>: | ||
80 | Points to the <code class="filename">deploy</code> | ||
81 | directory.</p></li> | ||
82 | <li class="listitem"><p><a class="link" href="../ref-manual/var-SDKMACHINE.html" target="_self"><code class="filename">SDKMACHINE</code></a>: | ||
83 | Specifies the architecture of the machine | ||
84 | on which the cross-development tools are run to | ||
85 | create packages for the target hardware. | ||
86 | </p></li> | ||
87 | <li class="listitem"><p><a class="link" href="../ref-manual/var-SDKIMAGE_FEATURES.html" target="_self"><code class="filename">SDKIMAGE_FEATURES</code></a>: | ||
88 | Lists the features to include in the "target" part | ||
89 | of the SDK. | ||
90 | </p></li> | ||
91 | <li class="listitem"><p><a class="link" href="../ref-manual/var-TOOLCHAIN_HOST_TASK.html" target="_self"><code class="filename">TOOLCHAIN_HOST_TASK</code></a>: | ||
92 | Lists packages that make up the host | ||
93 | part of the SDK (i.e. the part that runs on | ||
94 | the <code class="filename">SDKMACHINE</code>). | ||
95 | When you use | ||
96 | <code class="filename">bitbake -c populate_sdk <em class="replaceable"><code>imagename</code></em></code> | ||
97 | to create the SDK, a set of default packages | ||
98 | apply. | ||
99 | This variable allows you to add more packages. | ||
100 | </p></li> | ||
101 | <li class="listitem"><p><a class="link" href="../ref-manual/var-TOOLCHAIN_TARGET_TASK.html" target="_self"><code class="filename">TOOLCHAIN_TARGET_TASK</code></a>: | ||
102 | Lists packages that make up the target part | ||
103 | of the SDK (i.e. the part built for the | ||
104 | target hardware). | ||
105 | </p></li> | ||
106 | <li class="listitem"><p><a class="link" href="../ref-manual/var-SDKPATH.html" target="_self"><code class="filename">SDKPATH</code></a>: | ||
107 | Defines the default SDK installation path offered by the | ||
108 | installation script. | ||
109 | </p></li> | ||
110 | </ul></div> | ||
111 | <p> | ||
112 | This next list, shows the variables associated with an extensible | ||
113 | SDK: | ||
114 | </p> | ||
115 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
116 | <li class="listitem"><p><a class="link" href="../ref-manual/var-DEPLOY_DIR.html" target="_self"><code class="filename">DEPLOY_DIR</code></a>: | ||
117 | Points to the <code class="filename">deploy</code> directory. | ||
118 | </p></li> | ||
119 | <li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_EXT_TYPE.html" target="_self"><code class="filename">SDK_EXT_TYPE</code></a>: | ||
120 | Controls whether or not shared state artifacts are copied | ||
121 | into the extensible SDK. | ||
122 | By default, all required shared state artifacts are copied | ||
123 | into the SDK. | ||
124 | </p></li> | ||
125 | <li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_INCLUDE_PKGDATA.html" target="_self"><code class="filename">SDK_INCLUDE_PKGDATA</code></a>: | ||
126 | Specifies whether or not packagedata will be included in | ||
127 | the extensible SDK for all recipes in the "world" target. | ||
128 | </p></li> | ||
129 | <li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_INCLUDE_TOOLCHAIN.html" target="_self"><code class="filename">SDK_INCLUDE_TOOLCHAIN</code></a>: | ||
130 | Specifies whether or not the toolchain will be included | ||
131 | when building the extensible SDK. | ||
132 | </p></li> | ||
133 | <li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_LOCAL_CONF_WHITELIST.html" target="_self"><code class="filename">SDK_LOCAL_CONF_WHITELIST</code></a>: | ||
134 | A list of variables allowed through from the build system | ||
135 | configuration into the extensible SDK configuration. | ||
136 | </p></li> | ||
137 | <li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_LOCAL_CONF_BLACKLIST.html" target="_self"><code class="filename">SDK_LOCAL_CONF_BLACKLIST</code></a>: | ||
138 | A list of variables not allowed through from the build | ||
139 | system configuration into the extensible SDK configuration. | ||
140 | </p></li> | ||
141 | <li class="listitem"><p><a class="link" href="../ref-manual/var-SDK_INHERIT_BLACKLIST.html" target="_self"><code class="filename">SDK_INHERIT_BLACKLIST</code></a>: | ||
142 | A list of classes to remove from the | ||
143 | <a class="link" href="../ref-manual/var-INHERIT.html" target="_self"><code class="filename">INHERIT</code></a> | ||
144 | value globally within the extensible SDK configuration. | ||
145 | </p></li> | ||
146 | </ul></div> | ||
147 | <p> | ||
148 | </p> | ||
149 | </div></body> | ||
150 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/sdk-generation-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/sdk-generation-dev-environment.html deleted file mode 100644 index 1dfda5fab5..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/sdk-generation-dev-environment.html +++ /dev/null | |||
@@ -1,72 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.5.6. SDK Generation</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="image-generation-dev-environment.html" title="2.8.5.5. Image Generation"> | ||
10 | <link rel="next" href="stamp-files-and-the-rerunning-of-tasks.html" title="2.8.5.7. Stamp Files and the Rerunning of Tasks"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.6. SDK Generation"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="sdk-generation-dev-environment"></a>2.8.5.6. SDK Generation</h4></div></div></div> | ||
15 | <p> | ||
16 | The OpenEmbedded build system uses BitBake to generate the | ||
17 | Software Development Kit (SDK) installer script for both the | ||
18 | standard and extensible SDKs: | ||
19 | <img src="figures/sdk-generation.png" align="middle"> | ||
20 | </p> | ||
21 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
22 | <h3 class="title">Note</h3> | ||
23 | For more information on the cross-development toolchain | ||
24 | generation, see the | ||
25 | "<a class="link" href="cross-development-toolchain-generation.html" title="3.2. Cross-Development Toolchain Generation">Cross-Development Toolchain Generation</a>" | ||
26 | section. | ||
27 | For information on advantages gained when building a | ||
28 | cross-development toolchain using the | ||
29 | <a class="link" href="../ref-manual/ref-tasks-populate_sdk.html" target="_self"><code class="filename">do_populate_sdk</code></a> | ||
30 | task, see the | ||
31 | "<a class="link" href="../sdk-manual/sdk-building-an-sdk-installer.html" target="_self">Building an SDK Installer</a>" | ||
32 | section in the Yocto Project Application Development and the | ||
33 | Extensible Software Development Kit (SDK) manual. | ||
34 | </div> | ||
35 | <p> | ||
36 | Like image generation, the SDK script process consists of | ||
37 | several stages and depends on many variables. | ||
38 | The <code class="filename">do_populate_sdk</code> and | ||
39 | <code class="filename">do_populate_sdk_ext</code> tasks use these | ||
40 | key variables to help create the list of packages to actually | ||
41 | install. | ||
42 | For information on the variables listed in the figure, see the | ||
43 | "<a class="link" href="sdk-dev-environment.html" title="2.8.7. Application Development SDK">Application Development SDK</a>" | ||
44 | section. | ||
45 | </p> | ||
46 | <p> | ||
47 | The <code class="filename">do_populate_sdk</code> task helps create | ||
48 | the standard SDK and handles two parts: a target part and a | ||
49 | host part. | ||
50 | The target part is the part built for the target hardware and | ||
51 | includes libraries and headers. | ||
52 | The host part is the part of the SDK that runs on the | ||
53 | <a class="link" href="../ref-manual/var-SDKMACHINE.html" target="_self"><code class="filename">SDKMACHINE</code></a>. | ||
54 | </p> | ||
55 | <p> | ||
56 | The <code class="filename">do_populate_sdk_ext</code> task helps create | ||
57 | the extensible SDK and handles host and target parts | ||
58 | differently than its counter part does for the standard SDK. | ||
59 | For the extensible SDK, the task encapsulates the build system, | ||
60 | which includes everything needed (host and target) for the SDK. | ||
61 | </p> | ||
62 | <p> | ||
63 | Regardless of the type of SDK being constructed, the | ||
64 | tasks perform some cleanup after which a cross-development | ||
65 | environment setup script and any needed configuration files | ||
66 | are created. | ||
67 | The final output is the Cross-development | ||
68 | toolchain installation script (<code class="filename">.sh</code> file), | ||
69 | which includes the environment setup script. | ||
70 | </p> | ||
71 | </div></body> | ||
72 | </html> | ||
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 deleted file mode 100644 index 644e404b66..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/setscene-tasks-and-shared-state.html +++ /dev/null | |||
@@ -1,122 +0,0 @@ | |||
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> | ||
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> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/shared-state.html b/documentation/getting-started/eclipse/html/getting-started/shared-state.html deleted file mode 100644 index 4389684f3b..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/shared-state.html +++ /dev/null | |||
@@ -1,268 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.3.3. 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="shared-state-cache.html" title="3.3. Shared State Cache"> | ||
9 | <link rel="prev" href="overview-checksums.html" title="3.3.2. Checksums (Signatures)"> | ||
10 | <link rel="next" href="tips-and-tricks.html" title="3.3.4. Tips and Tricks"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.3. Shared State"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="shared-state"></a>3.3.3. Shared State</h3></div></div></div> | ||
15 | <p> | ||
16 | Checksums and dependencies, as discussed in the previous | ||
17 | section, solve half the problem of supporting a shared state. | ||
18 | The other part of the problem is being able to use checksum | ||
19 | information during the build and being able to reuse or rebuild | ||
20 | specific components. | ||
21 | </p> | ||
22 | <p> | ||
23 | The | ||
24 | <a class="link" href="../ref-manual/ref-classes-sstate.html" target="_self"><code class="filename">sstate</code></a> | ||
25 | class is a relatively generic implementation of how to | ||
26 | "capture" a snapshot of a given task. | ||
27 | The idea is that the build process does not care about the | ||
28 | source of a task's output. | ||
29 | Output could be freshly built or it could be downloaded and | ||
30 | unpacked from somewhere - the build process does not need to | ||
31 | worry about its origin. | ||
32 | </p> | ||
33 | <p> | ||
34 | There are two types of output, one is just about creating a | ||
35 | directory in | ||
36 | <a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a>. | ||
37 | A good example is the output of either | ||
38 | <a class="link" href="../ref-manual/ref-tasks-install.html" target="_self"><code class="filename">do_install</code></a> | ||
39 | or | ||
40 | <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>. | ||
41 | The other type of output occurs when a set of data is merged | ||
42 | into a shared directory tree such as the sysroot. | ||
43 | </p> | ||
44 | <p> | ||
45 | The Yocto Project team has tried to keep the details of the | ||
46 | implementation hidden in <code class="filename">sstate</code> class. | ||
47 | From a user's perspective, adding shared state wrapping to a task | ||
48 | is as simple as this | ||
49 | <a class="link" href="../ref-manual/ref-tasks-deploy.html" target="_self"><code class="filename">do_deploy</code></a> | ||
50 | example taken from the | ||
51 | <a class="link" href="../ref-manual/ref-classes-deploy.html" target="_self"><code class="filename">deploy</code></a> | ||
52 | class: | ||
53 | </p> | ||
54 | <pre class="literallayout"> | ||
55 | DEPLOYDIR = "${WORKDIR}/deploy-${PN}" | ||
56 | SSTATETASKS += "do_deploy" | ||
57 | do_deploy[sstate-inputdirs] = "${DEPLOYDIR}" | ||
58 | do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" | ||
59 | |||
60 | python do_deploy_setscene () { | ||
61 | sstate_setscene(d) | ||
62 | } | ||
63 | addtask do_deploy_setscene | ||
64 | do_deploy[dirs] = "${DEPLOYDIR} ${B}" | ||
65 | </pre> | ||
66 | <p> | ||
67 | The following list explains the previous example: | ||
68 | </p> | ||
69 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
70 | <li class="listitem"><p> | ||
71 | Adding "do_deploy" to <code class="filename">SSTATETASKS</code> | ||
72 | adds some required sstate-related processing, which is | ||
73 | implemented in the | ||
74 | <a class="link" href="../ref-manual/ref-classes-sstate.html" target="_self"><code class="filename">sstate</code></a> | ||
75 | class, to before and after the | ||
76 | <a class="link" href="../ref-manual/ref-tasks-deploy.html" target="_self"><code class="filename">do_deploy</code></a> | ||
77 | task. | ||
78 | </p></li> | ||
79 | <li class="listitem"><p> | ||
80 | The | ||
81 | <code class="filename">do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"</code> | ||
82 | declares that <code class="filename">do_deploy</code> places its | ||
83 | output in <code class="filename">${DEPLOYDIR}</code> when run | ||
84 | normally (i.e. when not using the sstate cache). | ||
85 | This output becomes the input to the shared state cache. | ||
86 | </p></li> | ||
87 | <li class="listitem"> | ||
88 | <p> | ||
89 | The | ||
90 | <code class="filename">do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"</code> | ||
91 | line causes the contents of the shared state cache to be | ||
92 | copied to <code class="filename">${DEPLOY_DIR_IMAGE}</code>. | ||
93 | </p> | ||
94 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
95 | <h3 class="title">Note</h3> | ||
96 | If <code class="filename">do_deploy</code> is not already in | ||
97 | the shared state cache or if its input checksum | ||
98 | (signature) has changed from when the output was | ||
99 | cached, the task will be run to populate the shared | ||
100 | state cache, after which the contents of the shared | ||
101 | state cache is copied to | ||
102 | <code class="filename">${DEPLOY_DIR_IMAGE}</code>. | ||
103 | If <code class="filename">do_deploy</code> is in the shared | ||
104 | state cache and its signature indicates that the | ||
105 | cached output is still valid (i.e. if no | ||
106 | relevant task inputs have changed), then the | ||
107 | contents of the shared state cache will be copied | ||
108 | directly to | ||
109 | <code class="filename">${DEPLOY_DIR_IMAGE}</code> by the | ||
110 | <code class="filename">do_deploy_setscene</code> task | ||
111 | instead, skipping the | ||
112 | <code class="filename">do_deploy</code> task. | ||
113 | </div> | ||
114 | <p> | ||
115 | </p> | ||
116 | </li> | ||
117 | <li class="listitem"> | ||
118 | <p> | ||
119 | The following task definition is glue logic needed to | ||
120 | make the previous settings effective: | ||
121 | </p> | ||
122 | <pre class="literallayout"> | ||
123 | python do_deploy_setscene () { | ||
124 | sstate_setscene(d) | ||
125 | } | ||
126 | addtask do_deploy_setscene | ||
127 | </pre> | ||
128 | <p> | ||
129 | <code class="filename">sstate_setscene()</code> takes the flags | ||
130 | above as input and accelerates the | ||
131 | <code class="filename">do_deploy</code> task through the | ||
132 | shared state cache if possible. | ||
133 | If the task was accelerated, | ||
134 | <code class="filename">sstate_setscene()</code> returns True. | ||
135 | Otherwise, it returns False, and the normal | ||
136 | <code class="filename">do_deploy</code> task runs. | ||
137 | For more information, see the | ||
138 | "<a class="link" href="../bitbake-user-manual/setscene.html" target="_self">setscene</a>" | ||
139 | section in the BitBake User Manual. | ||
140 | </p> | ||
141 | </li> | ||
142 | <li class="listitem"> | ||
143 | <p> | ||
144 | The <code class="filename">do_deploy[dirs] = "${DEPLOYDIR} ${B}"</code> | ||
145 | line creates <code class="filename">${DEPLOYDIR}</code> and | ||
146 | <code class="filename">${B}</code> before the | ||
147 | <code class="filename">do_deploy</code> task runs, and also sets | ||
148 | the current working directory of | ||
149 | <code class="filename">do_deploy</code> to | ||
150 | <code class="filename">${B}</code>. | ||
151 | For more information, see the | ||
152 | "<a class="link" href="../bitbake-user-manual/variable-flags.html" target="_self">Variable Flags</a>" | ||
153 | section in the BitBake User Manual. | ||
154 | </p> | ||
155 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
156 | <h3 class="title">Note</h3> | ||
157 | In cases where | ||
158 | <code class="filename">sstate-inputdirs</code> and | ||
159 | <code class="filename">sstate-outputdirs</code> would be the | ||
160 | same, you can use | ||
161 | <code class="filename">sstate-plaindirs</code>. | ||
162 | For example, to preserve the | ||
163 | <code class="filename">${PKGD}</code> and | ||
164 | <code class="filename">${PKGDEST}</code> output from the | ||
165 | <a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a> | ||
166 | task, use the following: | ||
167 | <pre class="literallayout"> | ||
168 | do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}" | ||
169 | </pre> | ||
170 | </div> | ||
171 | <p> | ||
172 | </p> | ||
173 | </li> | ||
174 | <li class="listitem"> | ||
175 | <p> | ||
176 | <code class="filename">sstate-inputdirs</code> and | ||
177 | <code class="filename">sstate-outputdirs</code> can also be used | ||
178 | with multiple directories. | ||
179 | For example, the following declares | ||
180 | <code class="filename">PKGDESTWORK</code> and | ||
181 | <code class="filename">SHLIBWORK</code> as shared state | ||
182 | input directories, which populates the shared state | ||
183 | cache, and <code class="filename">PKGDATA_DIR</code> and | ||
184 | <code class="filename">SHLIBSDIR</code> as the corresponding | ||
185 | shared state output directories: | ||
186 | </p> | ||
187 | <pre class="literallayout"> | ||
188 | do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}" | ||
189 | do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}" | ||
190 | </pre> | ||
191 | <p> | ||
192 | </p> | ||
193 | </li> | ||
194 | <li class="listitem"> | ||
195 | <p> | ||
196 | These methods also include the ability to take a | ||
197 | lockfile when manipulating shared state directory | ||
198 | structures, for cases where file additions or removals | ||
199 | are sensitive: | ||
200 | </p> | ||
201 | <pre class="literallayout"> | ||
202 | do_package[sstate-lockfile] = "${PACKAGELOCK}" | ||
203 | </pre> | ||
204 | <p> | ||
205 | </p> | ||
206 | </li> | ||
207 | </ul></div> | ||
208 | <p> | ||
209 | </p> | ||
210 | <p> | ||
211 | Behind the scenes, the shared state code works by looking in | ||
212 | <a class="link" href="../ref-manual/var-SSTATE_DIR.html" target="_self"><code class="filename">SSTATE_DIR</code></a> | ||
213 | and | ||
214 | <a class="link" href="../ref-manual/var-SSTATE_MIRRORS.html" target="_self"><code class="filename">SSTATE_MIRRORS</code></a> | ||
215 | for shared state files. | ||
216 | Here is an example: | ||
217 | </p> | ||
218 | <pre class="literallayout"> | ||
219 | SSTATE_MIRRORS ?= "\ | ||
220 | file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ | ||
221 | file://.* file:///some/local/dir/sstate/PATH" | ||
222 | </pre> | ||
223 | <p> | ||
224 | </p> | ||
225 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
226 | <h3 class="title">Note</h3> | ||
227 | The shared state directory | ||
228 | (<code class="filename">SSTATE_DIR</code>) is organized into | ||
229 | two-character subdirectories, where the subdirectory | ||
230 | names are based on the first two characters of the hash. | ||
231 | If the shared state directory structure for a mirror has the | ||
232 | same structure as <code class="filename">SSTATE_DIR</code>, you must | ||
233 | specify "PATH" as part of the URI to enable the build system | ||
234 | to map to the appropriate subdirectory. | ||
235 | </div> | ||
236 | <p> | ||
237 | </p> | ||
238 | <p> | ||
239 | The shared state package validity can be detected just by | ||
240 | looking at the filename since the filename contains the task | ||
241 | checksum (or signature) as described earlier in this section. | ||
242 | If a valid shared state package is found, the build process | ||
243 | downloads it and uses it to accelerate the task. | ||
244 | </p> | ||
245 | <p> | ||
246 | The build processes use the <code class="filename">*_setscene</code> | ||
247 | tasks for the task acceleration phase. | ||
248 | BitBake goes through this phase before the main execution | ||
249 | code and tries to accelerate any tasks for which it can find | ||
250 | shared state packages. | ||
251 | If a shared state package for a task is available, the | ||
252 | shared state package is used. | ||
253 | This means the task and any tasks on which it is dependent | ||
254 | are not executed. | ||
255 | </p> | ||
256 | <p> | ||
257 | As a real world example, the aim is when building an IPK-based | ||
258 | image, only the | ||
259 | <a class="link" href="../ref-manual/ref-tasks-package_write_ipk.html" target="_self"><code class="filename">do_package_write_ipk</code></a> | ||
260 | tasks would have their shared state packages fetched and | ||
261 | extracted. | ||
262 | Since the sysroot is not used, it would never get extracted. | ||
263 | This is another reason why a task-based approach is preferred | ||
264 | over a recipe-based approach, which would have to install the | ||
265 | output from every task. | ||
266 | </p> | ||
267 | </div></body> | ||
268 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/software-layer.html b/documentation/getting-started/eclipse/html/getting-started/software-layer.html deleted file mode 100644 index 26e169a281..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/software-layer.html +++ /dev/null | |||
@@ -1,27 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.2.3. Software Layer</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="metadata-machine-configuration-and-policy-configuration.html" title="2.8.2. Metadata, Machine Configuration, and Policy Configuration"> | ||
9 | <link rel="prev" href="bsp-layer.html" title="2.8.2.2. BSP Layer"> | ||
10 | <link rel="next" href="sources-dev-environment.html" title="2.8.3. Sources"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.2.3. Software Layer"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="software-layer"></a>2.8.2.3. Software Layer</h4></div></div></div> | ||
15 | <p> | ||
16 | The software layer provides the Metadata for additional | ||
17 | software packages used during the build. | ||
18 | This layer does not include Metadata that is specific to the | ||
19 | distribution or the machine, which are found in their | ||
20 | respective layers. | ||
21 | </p> | ||
22 | <p> | ||
23 | This layer contains any new recipes that your project needs | ||
24 | in the form of recipe files. | ||
25 | </p> | ||
26 | </div></body> | ||
27 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/source-fetching-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/source-fetching-dev-environment.html deleted file mode 100644 index afcdafdc76..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/source-fetching-dev-environment.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>2.8.5.1. Source Fetching</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="bitbake-dev-environment.html" title="2.8.5. BitBake"> | ||
10 | <link rel="next" href="patching-dev-environment.html" title="2.8.5.2. Patching"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.1. Source Fetching"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="source-fetching-dev-environment"></a>2.8.5.1. Source Fetching</h4></div></div></div> | ||
15 | <p> | ||
16 | The first stages of building a recipe are to fetch and unpack | ||
17 | the source code: | ||
18 | </p> | ||
19 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="585"><tr style="height: 450px"><td align="center"><img src="figures/source-fetching.png" align="middle" width="585"></td></tr></table> | ||
20 | <p> | ||
21 | </p> | ||
22 | <p> | ||
23 | The | ||
24 | <a class="link" href="../ref-manual/ref-tasks-fetch.html" target="_self"><code class="filename">do_fetch</code></a> | ||
25 | and | ||
26 | <a class="link" href="../ref-manual/ref-tasks-unpack.html" target="_self"><code class="filename">do_unpack</code></a> | ||
27 | tasks fetch the source files and unpack them into the work | ||
28 | directory. | ||
29 | </p> | ||
30 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
31 | <h3 class="title">Note</h3> | ||
32 | For every local file (e.g. <code class="filename">file://</code>) | ||
33 | that is part of a recipe's | ||
34 | <a class="link" href="../ref-manual/var-SRC_URI.html" target="_self"><code class="filename">SRC_URI</code></a> | ||
35 | statement, the OpenEmbedded build system takes a checksum | ||
36 | of the file for the recipe and inserts the checksum into | ||
37 | the signature for the <code class="filename">do_fetch</code>. | ||
38 | If any local file has been modified, the | ||
39 | <code class="filename">do_fetch</code> task and all tasks that | ||
40 | depend on it are re-executed. | ||
41 | </div> | ||
42 | <p> | ||
43 | By default, everything is accomplished in the | ||
44 | <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>, | ||
45 | which has a defined structure. | ||
46 | For additional general information on the Build Directory, | ||
47 | see the | ||
48 | "<a class="link" href="../ref-manual/structure-core-build.html" target="_self"><code class="filename">build/</code></a>" | ||
49 | section in the Yocto Project Reference Manual. | ||
50 | </p> | ||
51 | <p> | ||
52 | Unpacked source files are pointed to by the | ||
53 | <a class="link" href="../ref-manual/var-S.html" target="_self"><code class="filename">S</code></a> | ||
54 | variable. | ||
55 | Each recipe has an area in the Build Directory where the | ||
56 | unpacked source code resides. | ||
57 | The name of that directory for any given recipe is defined from | ||
58 | several different variables. | ||
59 | You can see the variables that define these directories | ||
60 | by looking at the figure: | ||
61 | </p> | ||
62 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
63 | <li class="listitem"><p><a class="link" href="../ref-manual/var-TMPDIR.html" target="_self"><code class="filename">TMPDIR</code></a> - | ||
64 | The base directory where the OpenEmbedded build system | ||
65 | performs all its work during the build. | ||
66 | </p></li> | ||
67 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PACKAGE_ARCH.html" target="_self"><code class="filename">PACKAGE_ARCH</code></a> - | ||
68 | The architecture of the built package or packages. | ||
69 | </p></li> | ||
70 | <li class="listitem"><p><a class="link" href="../ref-manual/var-TARGET_OS.html" target="_self"><code class="filename">TARGET_OS</code></a> - | ||
71 | The operating system of the target device. | ||
72 | </p></li> | ||
73 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PN.html" target="_self"><code class="filename">PN</code></a> - | ||
74 | The name of the built package. | ||
75 | </p></li> | ||
76 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PV.html" target="_self"><code class="filename">PV</code></a> - | ||
77 | The version of the recipe used to build the package. | ||
78 | </p></li> | ||
79 | <li class="listitem"><p><a class="link" href="../ref-manual/var-PR.html" target="_self"><code class="filename">PR</code></a> - | ||
80 | The revision of the recipe used to build the package. | ||
81 | </p></li> | ||
82 | <li class="listitem"><p><a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a> - | ||
83 | The location within <code class="filename">TMPDIR</code> where | ||
84 | a specific package is built. | ||
85 | </p></li> | ||
86 | <li class="listitem"><p><a class="link" href="../ref-manual/var-S.html" target="_self"><code class="filename">S</code></a> - | ||
87 | Contains the unpacked source files for a given recipe. | ||
88 | </p></li> | ||
89 | </ul></div> | ||
90 | <p> | ||
91 | </p> | ||
92 | </div></body> | ||
93 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/source-mirrors.html b/documentation/getting-started/eclipse/html/getting-started/source-mirrors.html deleted file mode 100644 index 178903c96e..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/source-mirrors.html +++ /dev/null | |||
@@ -1,37 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.3.4. Source Mirror(s)</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="sources-dev-environment.html" title="2.8.3. Sources"> | ||
9 | <link rel="prev" href="scms.html" title="2.8.3.3. Source Control Managers (Optional)"> | ||
10 | <link rel="next" href="package-feeds-dev-environment.html" title="2.8.4. Package Feeds"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.3.4. Source Mirror(s)"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="source-mirrors"></a>2.8.3.4. Source Mirror(s)</h4></div></div></div> | ||
15 | <p> | ||
16 | Two kinds of mirrors exist: pre-mirrors and regular mirrors. | ||
17 | The | ||
18 | <a class="link" href="../ref-manual/var-PREMIRRORS.html" target="_self"><code class="filename">PREMIRRORS</code></a> | ||
19 | and | ||
20 | <a class="link" href="../ref-manual/var-MIRRORS.html" target="_self"><code class="filename">MIRRORS</code></a> | ||
21 | variables point to these, respectively. | ||
22 | BitBake checks pre-mirrors before looking upstream for any | ||
23 | source files. | ||
24 | Pre-mirrors are appropriate when you have a shared directory | ||
25 | that is not a directory defined by the | ||
26 | <a class="link" href="../ref-manual/var-DL_DIR.html" target="_self"><code class="filename">DL_DIR</code></a> | ||
27 | variable. | ||
28 | A Pre-mirror typically points to a shared directory that is | ||
29 | local to your organization. | ||
30 | </p> | ||
31 | <p> | ||
32 | Regular mirrors can be any site across the Internet that is | ||
33 | used as an alternative location for source code should the | ||
34 | primary site not be functioning for some reason or another. | ||
35 | </p> | ||
36 | </div></body> | ||
37 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/sources-dev-environment.html b/documentation/getting-started/eclipse/html/getting-started/sources-dev-environment.html deleted file mode 100644 index ab7718074f..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/sources-dev-environment.html +++ /dev/null | |||
@@ -1,80 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.3. Sources</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="development-concepts.html" title="2.8. Development Concepts"> | ||
9 | <link rel="prev" href="software-layer.html" title="2.8.2.3. Software Layer"> | ||
10 | <link rel="next" href="upstream-project-releases.html" title="2.8.3.1. Upstream Project Releases"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.3. Sources"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="sources-dev-environment"></a>2.8.3. Sources</h3></div></div></div> | ||
15 | <p> | ||
16 | In order for the OpenEmbedded build system to create an image or | ||
17 | any target, it must be able to access source files. | ||
18 | The | ||
19 | <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a> | ||
20 | represents source files using the "Upstream Project Releases", | ||
21 | "Local Projects", and "SCMs (optional)" boxes. | ||
22 | The figure represents mirrors, which also play a role in locating | ||
23 | source files, with the "Source Mirror(s)" box. | ||
24 | </p> | ||
25 | <p> | ||
26 | The method by which source files are ultimately organized is | ||
27 | a function of the project. | ||
28 | For example, for released software, projects tend to use tarballs | ||
29 | or other archived files that can capture the state of a release | ||
30 | guaranteeing that it is statically represented. | ||
31 | On the other hand, for a project that is more dynamic or | ||
32 | experimental in nature, a project might keep source files in a | ||
33 | repository controlled by a Source Control Manager (SCM) such as | ||
34 | Git. | ||
35 | Pulling source from a repository allows you to control | ||
36 | the point in the repository (the revision) from which you want to | ||
37 | build software. | ||
38 | Finally, a combination of the two might exist, which would give the | ||
39 | consumer a choice when deciding where to get source files. | ||
40 | </p> | ||
41 | <p> | ||
42 | BitBake uses the | ||
43 | <a class="link" href="../ref-manual/var-SRC_URI.html" target="_self"><code class="filename">SRC_URI</code></a> | ||
44 | variable to point to source files regardless of their location. | ||
45 | Each recipe must have a <code class="filename">SRC_URI</code> variable | ||
46 | that points to the source. | ||
47 | </p> | ||
48 | <p> | ||
49 | Another area that plays a significant role in where source files | ||
50 | come from is pointed to by the | ||
51 | <a class="link" href="../ref-manual/var-DL_DIR.html" target="_self"><code class="filename">DL_DIR</code></a> | ||
52 | variable. | ||
53 | This area is a cache that can hold previously downloaded source. | ||
54 | You can also instruct the OpenEmbedded build system to create | ||
55 | tarballs from Git repositories, which is not the default behavior, | ||
56 | and store them in the <code class="filename">DL_DIR</code> by using the | ||
57 | <a class="link" href="../ref-manual/var-BB_GENERATE_MIRROR_TARBALLS.html" target="_self"><code class="filename">BB_GENERATE_MIRROR_TARBALLS</code></a> | ||
58 | variable. | ||
59 | </p> | ||
60 | <p> | ||
61 | Judicious use of a <code class="filename">DL_DIR</code> directory can | ||
62 | save the build system a trip across the Internet when looking | ||
63 | for files. | ||
64 | A good method for using a download directory is to have | ||
65 | <code class="filename">DL_DIR</code> point to an area outside of your | ||
66 | Build Directory. | ||
67 | Doing so allows you to safely delete the Build Directory | ||
68 | if needed without fear of removing any downloaded source file. | ||
69 | </p> | ||
70 | <p> | ||
71 | The remainder of this section provides a deeper look into the | ||
72 | source files and the mirrors. | ||
73 | Here is a more detailed look at the source file area of the | ||
74 | base figure: | ||
75 | </p> | ||
76 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="630"><tr style="height: 675px"><td align="center"><img src="figures/source-input.png" align="middle" width="630"></td></tr></table> | ||
77 | <p> | ||
78 | </p> | ||
79 | </div></body> | ||
80 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/stamp-files-and-the-rerunning-of-tasks.html b/documentation/getting-started/eclipse/html/getting-started/stamp-files-and-the-rerunning-of-tasks.html deleted file mode 100644 index b649c69b2b..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/stamp-files-and-the-rerunning-of-tasks.html +++ /dev/null | |||
@@ -1,83 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.5.7. Stamp Files and the Rerunning of Tasks</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="sdk-generation-dev-environment.html" title="2.8.5.6. SDK Generation"> | ||
10 | <link rel="next" href="setscene-tasks-and-shared-state.html" title="2.8.5.8. Setscene Tasks and Shared State"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.7. Stamp Files and the Rerunning of Tasks"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="stamp-files-and-the-rerunning-of-tasks"></a>2.8.5.7. Stamp Files and the Rerunning of Tasks</h4></div></div></div> | ||
15 | <p> | ||
16 | For each task that completes successfully, BitBake writes a | ||
17 | stamp file into the | ||
18 | <a class="link" href="../ref-manual/var-STAMPS_DIR.html" target="_self"><code class="filename">STAMPS_DIR</code></a> | ||
19 | directory. | ||
20 | The beginning of the stamp file's filename is determined by the | ||
21 | <a class="link" href="../ref-manual/var-STAMP.html" target="_self"><code class="filename">STAMP</code></a> | ||
22 | variable, and the end of the name consists of the task's name | ||
23 | and current | ||
24 | <a class="link" href="overview-checksums.html" title="3.3.2. Checksums (Signatures)">input checksum</a>. | ||
25 | </p> | ||
26 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
27 | <h3 class="title">Note</h3> | ||
28 | This naming scheme assumes that | ||
29 | <a class="link" href="../bitbake-user-manual/var-BB_SIGNATURE_HANDLER.html" target="_self"><code class="filename">BB_SIGNATURE_HANDLER</code></a> | ||
30 | is "OEBasicHash", which is almost always the case in | ||
31 | current OpenEmbedded. | ||
32 | </div> | ||
33 | <p> | ||
34 | To determine if a task needs to be rerun, BitBake checks if a | ||
35 | stamp file with a matching input checksum exists for the task. | ||
36 | If such a stamp file exists, the task's output is assumed to | ||
37 | exist and still be valid. | ||
38 | If the file does not exist, the task is rerun. | ||
39 | </p> | ||
40 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
41 | <h3 class="title">Note</h3> | ||
42 | <p>The stamp mechanism is more general than the shared | ||
43 | state (sstate) cache mechanism described in the | ||
44 | "<a class="link" href="setscene-tasks-and-shared-state.html" title="2.8.5.8. Setscene Tasks and Shared State">Setscene Tasks and Shared State</a>" | ||
45 | section. | ||
46 | BitBake avoids rerunning any task that has a valid | ||
47 | stamp file, not just tasks that can be accelerated through | ||
48 | the sstate cache.</p> | ||
49 | <p>However, you should realize that stamp files only | ||
50 | serve as a marker that some work has been done and that | ||
51 | these files do not record task output. | ||
52 | The actual task output would usually be somewhere in | ||
53 | <a class="link" href="../ref-manual/var-TMPDIR.html" target="_self"><code class="filename">TMPDIR</code></a> | ||
54 | (e.g. in some recipe's | ||
55 | <a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a>.) | ||
56 | What the sstate cache mechanism adds is a way to cache task | ||
57 | output that can then be shared between build machines. | ||
58 | </p> | ||
59 | </div> | ||
60 | <p> | ||
61 | Since <code class="filename">STAMPS_DIR</code> is usually a subdirectory | ||
62 | of <code class="filename">TMPDIR</code>, removing | ||
63 | <code class="filename">TMPDIR</code> will also remove | ||
64 | <code class="filename">STAMPS_DIR</code>, which means tasks will | ||
65 | properly be rerun to repopulate <code class="filename">TMPDIR</code>. | ||
66 | </p> | ||
67 | <p> | ||
68 | If you want some task to always be considered "out of date", | ||
69 | you can mark it with the | ||
70 | <a class="link" href="../bitbake-user-manual/variable-flags.html" target="_self"><code class="filename">nostamp</code></a> | ||
71 | varflag. | ||
72 | If some other task depends on such a task, then that task will | ||
73 | also always be considered out of date, which might not be what | ||
74 | you want. | ||
75 | </p> | ||
76 | <p> | ||
77 | For details on how to view information about a task's | ||
78 | signature, see the | ||
79 | "<a class="link" href="../dev-manual/dev-viewing-task-variable-dependencies.html" target="_self">Viewing Task Variable Dependencies</a>" | ||
80 | section in the Yocto Project Development Tasks Manual. | ||
81 | </p> | ||
82 | </div></body> | ||
83 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/tips-and-tricks.html b/documentation/getting-started/eclipse/html/getting-started/tips-and-tricks.html deleted file mode 100644 index d0c8522d95..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/tips-and-tricks.html +++ /dev/null | |||
@@ -1,22 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.3.4. Tips and Tricks</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.html" title="3.3.3. Shared State"> | ||
10 | <link rel="next" href="overview-debugging.html" title="3.3.4.1. Debugging"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.3.4. Tips and Tricks"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="tips-and-tricks"></a>3.3.4. Tips and Tricks</h3></div></div></div> | ||
15 | <p> | ||
16 | The code in the build system that supports incremental builds | ||
17 | is not simple code. | ||
18 | This section presents some tips and tricks that help you work | ||
19 | around issues related to shared state code. | ||
20 | </p> | ||
21 | </div></body> | ||
22 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/upstream-project-releases.html b/documentation/getting-started/eclipse/html/getting-started/upstream-project-releases.html deleted file mode 100644 index ef9bc18dde..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/upstream-project-releases.html +++ /dev/null | |||
@@ -1,25 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.3.1. Upstream Project Releases</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="sources-dev-environment.html" title="2.8.3. Sources"> | ||
9 | <link rel="prev" href="sources-dev-environment.html" title="2.8.3. Sources"> | ||
10 | <link rel="next" href="local-projects.html" title="2.8.3.2. Local Projects"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.3.1. Upstream Project Releases"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="upstream-project-releases"></a>2.8.3.1. Upstream Project Releases</h4></div></div></div> | ||
15 | <p> | ||
16 | Upstream project releases exist anywhere in the form of an | ||
17 | archived file (e.g. tarball or zip file). | ||
18 | These files correspond to individual recipes. | ||
19 | For example, the figure uses specific releases each for | ||
20 | BusyBox, Qt, and Dbus. | ||
21 | An archive file can be for any released product that can be | ||
22 | built using a recipe. | ||
23 | </p> | ||
24 | </div></body> | ||
25 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/user-configuration.html b/documentation/getting-started/eclipse/html/getting-started/user-configuration.html deleted file mode 100644 index 6f10791e7a..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/user-configuration.html +++ /dev/null | |||
@@ -1,232 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.8.1. User Configuration</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="development-concepts.html" title="2.8. Development Concepts"> | ||
9 | <link rel="prev" href="development-concepts.html" title="2.8. Development Concepts"> | ||
10 | <link rel="next" href="metadata-machine-configuration-and-policy-configuration.html" title="2.8.2. Metadata, Machine Configuration, and Policy Configuration"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.1. User Configuration"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="user-configuration"></a>2.8.1. User Configuration</h3></div></div></div> | ||
15 | <p> | ||
16 | User configuration helps define the build. | ||
17 | Through user configuration, you can tell BitBake the | ||
18 | target architecture for which you are building the image, | ||
19 | where to store downloaded source, and other build properties. | ||
20 | </p> | ||
21 | <p> | ||
22 | The following figure shows an expanded representation of the | ||
23 | "User Configuration" box of the | ||
24 | <a class="link" href="development-concepts.html#general-yocto-environment-figure">general Yocto Project Development Environment figure</a>: | ||
25 | </p> | ||
26 | <p> | ||
27 | </p> | ||
28 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr style="height: 405px"><td align="center"><img src="figures/user-configuration.png" align="middle" height="405"></td></tr></table> | ||
29 | <p> | ||
30 | </p> | ||
31 | <p> | ||
32 | BitBake needs some basic configuration files in order to complete | ||
33 | a build. | ||
34 | These files are <code class="filename">*.conf</code> files. | ||
35 | The minimally necessary ones reside as example files in the | ||
36 | <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>. | ||
37 | For simplicity, this section refers to the Source Directory as | ||
38 | the "Poky Directory." | ||
39 | </p> | ||
40 | <p> | ||
41 | When you clone the <code class="filename">poky</code> Git repository or you | ||
42 | download and unpack a Yocto Project release, you can set up the | ||
43 | Source Directory to be named anything you want. | ||
44 | For this discussion, the cloned repository uses the default | ||
45 | name <code class="filename">poky</code>. | ||
46 | </p> | ||
47 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
48 | <h3 class="title">Note</h3> | ||
49 | The Poky repository is primarily an aggregation of existing | ||
50 | repositories. | ||
51 | It is not a canonical upstream source. | ||
52 | </div> | ||
53 | <p> | ||
54 | </p> | ||
55 | <p> | ||
56 | The <code class="filename">meta-poky</code> layer inside Poky contains | ||
57 | a <code class="filename">conf</code> directory that has example | ||
58 | configuration files. | ||
59 | These example files are used as a basis for creating actual | ||
60 | configuration files when you source the build environment | ||
61 | script | ||
62 | (i.e. | ||
63 | <a class="link" href="../ref-manual/structure-core-script.html" target="_self"><code class="filename">oe-init-build-env</code></a>). | ||
64 | </p> | ||
65 | <p> | ||
66 | Sourcing the build environment script creates a | ||
67 | <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a> | ||
68 | if one does not already exist. | ||
69 | BitBake uses the Build Directory for all its work during builds. | ||
70 | The Build Directory has a <code class="filename">conf</code> directory that | ||
71 | contains default versions of your <code class="filename">local.conf</code> | ||
72 | and <code class="filename">bblayers.conf</code> configuration files. | ||
73 | These default configuration files are created only if versions | ||
74 | do not already exist in the Build Directory at the time you | ||
75 | source the build environment setup script. | ||
76 | </p> | ||
77 | <p> | ||
78 | Because the Poky repository is fundamentally an aggregation of | ||
79 | existing repositories, some users might be familiar with running | ||
80 | the <code class="filename">oe-init-build-env</code> script in the context | ||
81 | of separate OpenEmbedded-Core and BitBake repositories rather than a | ||
82 | single Poky repository. | ||
83 | This discussion assumes the script is executed from within a cloned | ||
84 | or unpacked version of Poky. | ||
85 | </p> | ||
86 | <p> | ||
87 | Depending on where the script is sourced, different sub-scripts | ||
88 | are called to set up the Build Directory (Yocto or OpenEmbedded). | ||
89 | Specifically, the script | ||
90 | <code class="filename">scripts/oe-setup-builddir</code> inside the | ||
91 | poky directory sets up the Build Directory and seeds the directory | ||
92 | (if necessary) with configuration files appropriate for the | ||
93 | Yocto Project development environment. | ||
94 | </p> | ||
95 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
96 | <h3 class="title">Note</h3> | ||
97 | The <code class="filename">scripts/oe-setup-builddir</code> script | ||
98 | uses the <code class="filename">$TEMPLATECONF</code> variable to | ||
99 | determine which sample configuration files to locate. | ||
100 | </div> | ||
101 | <p> | ||
102 | </p> | ||
103 | <p> | ||
104 | The <code class="filename">local.conf</code> file provides many | ||
105 | basic variables that define a build environment. | ||
106 | Here is a list of a few. | ||
107 | To see the default configurations in a <code class="filename">local.conf</code> | ||
108 | file created by the build environment script, see the | ||
109 | <code class="filename">local.conf.sample</code> in the | ||
110 | <code class="filename">meta-poky</code> layer: | ||
111 | </p> | ||
112 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
113 | <li class="listitem"><p><span class="emphasis"><em>Parallelism Options:</em></span> | ||
114 | Controlled by the | ||
115 | <a class="link" href="../ref-manual/var-BB_NUMBER_THREADS.html" target="_self"><code class="filename">BB_NUMBER_THREADS</code></a>, | ||
116 | <a class="link" href="../ref-manual/var-PARALLEL_MAKE.html" target="_self"><code class="filename">PARALLEL_MAKE</code></a>, | ||
117 | and | ||
118 | <a class="link" href="../bitbake-user-manual/var-BB_NUMBER_PARSE_THREADS.html" target="_self"><code class="filename">BB_NUMBER_PARSE_THREADS</code></a> | ||
119 | variables.</p></li> | ||
120 | <li class="listitem"><p><span class="emphasis"><em>Target Machine Selection:</em></span> | ||
121 | Controlled by the | ||
122 | <a class="link" href="../ref-manual/var-MACHINE.html" target="_self"><code class="filename">MACHINE</code></a> | ||
123 | variable.</p></li> | ||
124 | <li class="listitem"><p><span class="emphasis"><em>Download Directory:</em></span> | ||
125 | Controlled by the | ||
126 | <a class="link" href="../ref-manual/var-DL_DIR.html" target="_self"><code class="filename">DL_DIR</code></a> | ||
127 | variable.</p></li> | ||
128 | <li class="listitem"><p><span class="emphasis"><em>Shared State Directory:</em></span> | ||
129 | Controlled by the | ||
130 | <a class="link" href="../ref-manual/var-SSTATE_DIR.html" target="_self"><code class="filename">SSTATE_DIR</code></a> | ||
131 | variable.</p></li> | ||
132 | <li class="listitem"><p><span class="emphasis"><em>Build Output:</em></span> | ||
133 | Controlled by the | ||
134 | <a class="link" href="../ref-manual/var-TMPDIR.html" target="_self"><code class="filename">TMPDIR</code></a> | ||
135 | variable.</p></li> | ||
136 | </ul></div> | ||
137 | <p> | ||
138 | </p> | ||
139 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
140 | <h3 class="title">Note</h3> | ||
141 | Configurations set in the <code class="filename">conf/local.conf</code> | ||
142 | file can also be set in the | ||
143 | <code class="filename">conf/site.conf</code> and | ||
144 | <code class="filename">conf/auto.conf</code> configuration files. | ||
145 | </div> | ||
146 | <p> | ||
147 | </p> | ||
148 | <p> | ||
149 | The <code class="filename">bblayers.conf</code> file tells BitBake what | ||
150 | layers you want considered during the build. | ||
151 | By default, the layers listed in this file include layers | ||
152 | minimally needed by the build system. | ||
153 | However, you must manually add any custom layers you have created. | ||
154 | You can find more information on working with the | ||
155 | <code class="filename">bblayers.conf</code> file in the | ||
156 | "<a class="link" href="../dev-manual/enabling-your-layer.html" target="_self">Enabling Your Layer</a>" | ||
157 | section in the Yocto Project Development Tasks Manual. | ||
158 | </p> | ||
159 | <p> | ||
160 | The files <code class="filename">site.conf</code> and | ||
161 | <code class="filename">auto.conf</code> are not created by the environment | ||
162 | initialization script. | ||
163 | If you want the <code class="filename">site.conf</code> file, you need to | ||
164 | create that yourself. | ||
165 | The <code class="filename">auto.conf</code> file is typically created by | ||
166 | an autobuilder: | ||
167 | </p> | ||
168 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
169 | <li class="listitem"> | ||
170 | <p><span class="emphasis"><em><code class="filename">site.conf</code>:</em></span> | ||
171 | You can use the <code class="filename">conf/site.conf</code> | ||
172 | configuration file to configure multiple build directories. | ||
173 | For example, suppose you had several build environments and | ||
174 | they shared some common features. | ||
175 | You can set these default build properties here. | ||
176 | A good example is perhaps the packaging format to use | ||
177 | through the | ||
178 | <a class="link" href="../ref-manual/var-PACKAGE_CLASSES.html" target="_self"><code class="filename">PACKAGE_CLASSES</code></a> | ||
179 | variable.</p> | ||
180 | <p>One useful scenario for using the | ||
181 | <code class="filename">conf/site.conf</code> file is to extend your | ||
182 | <a class="link" href="../ref-manual/var-BBPATH.html" target="_self"><code class="filename">BBPATH</code></a> | ||
183 | variable to include the path to a | ||
184 | <code class="filename">conf/site.conf</code>. | ||
185 | Then, when BitBake looks for Metadata using | ||
186 | <code class="filename">BBPATH</code>, it finds the | ||
187 | <code class="filename">conf/site.conf</code> file and applies your | ||
188 | common configurations found in the file. | ||
189 | To override configurations in a particular build directory, | ||
190 | alter the similar configurations within that build | ||
191 | directory's <code class="filename">conf/local.conf</code> file. | ||
192 | </p> | ||
193 | </li> | ||
194 | <li class="listitem"><p><span class="emphasis"><em><code class="filename">auto.conf</code>:</em></span> | ||
195 | The file is usually created and written to by | ||
196 | an autobuilder. | ||
197 | The settings put into the file are typically the same as | ||
198 | you would find in the <code class="filename">conf/local.conf</code> | ||
199 | or the <code class="filename">conf/site.conf</code> files. | ||
200 | </p></li> | ||
201 | </ul></div> | ||
202 | <p> | ||
203 | </p> | ||
204 | <p> | ||
205 | You can edit all configuration files to further define | ||
206 | any particular build environment. | ||
207 | This process is represented by the "User Configuration Edits" | ||
208 | box in the figure. | ||
209 | </p> | ||
210 | <p> | ||
211 | When you launch your build with the | ||
212 | <code class="filename">bitbake <em class="replaceable"><code>target</code></em></code> | ||
213 | command, BitBake sorts out the configurations to ultimately | ||
214 | define your build environment. | ||
215 | It is important to understand that the OpenEmbedded build system | ||
216 | reads the configuration files in a specific order: | ||
217 | <code class="filename">site.conf</code>, <code class="filename">auto.conf</code>, | ||
218 | and <code class="filename">local.conf</code>. | ||
219 | And, the build system applies the normal assignment statement | ||
220 | rules. | ||
221 | Because the files are parsed in a specific order, variable | ||
222 | assignments for the same variable could be affected. | ||
223 | For example, if the <code class="filename">auto.conf</code> file and | ||
224 | the <code class="filename">local.conf</code> set | ||
225 | <em class="replaceable"><code>variable1</code></em> to different values, because | ||
226 | the build system parses <code class="filename">local.conf</code> after | ||
227 | <code class="filename">auto.conf</code>, | ||
228 | <em class="replaceable"><code>variable1</code></em> is assigned the value from | ||
229 | the <code class="filename">local.conf</code> file. | ||
230 | </p> | ||
231 | </div></body> | ||
232 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html deleted file mode 100644 index 7e43ebd923..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html +++ /dev/null | |||
@@ -1,76 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.7.1.2. Explanation of Syntax</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="usingpoky-configuring-LIC_FILES_CHKSUM.html" title="3.7.1. Tracking License Changes"> | ||
9 | <link rel="prev" href="usingpoky-specifying-LIC_FILES_CHKSUM.html" title="3.7.1.1. Specifying the LIC_FILES_CHKSUM Variable"> | ||
10 | <link rel="next" href="enabling-commercially-licensed-recipes.html" title="3.7.2. Enabling Commercially Licensed Recipes"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.1.2. Explanation of Syntax"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax"></a>3.7.1.2. Explanation of Syntax</h4></div></div></div> | ||
15 | <p> | ||
16 | As mentioned in the previous section, the | ||
17 | <code class="filename">LIC_FILES_CHKSUM</code> variable lists all | ||
18 | the important files that contain the license text for the | ||
19 | source code. | ||
20 | It is possible to specify a checksum for an entire file, | ||
21 | or a specific section of a file (specified by beginning and | ||
22 | ending line numbers with the "beginline" and "endline" | ||
23 | parameters, respectively). | ||
24 | The latter is useful for source files with a license | ||
25 | notice header, README documents, and so forth. | ||
26 | If you do not use the "beginline" parameter, then it is | ||
27 | assumed that the text begins on the first line of the file. | ||
28 | Similarly, if you do not use the "endline" parameter, | ||
29 | it is assumed that the license text ends with the last | ||
30 | line of the file. | ||
31 | </p> | ||
32 | <p> | ||
33 | The "md5" parameter stores the md5 checksum of the license | ||
34 | text. | ||
35 | If the license text changes in any way as compared to | ||
36 | this parameter then a mismatch occurs. | ||
37 | This mismatch triggers a build failure and notifies | ||
38 | the developer. | ||
39 | Notification allows the developer to review and address | ||
40 | the license text changes. | ||
41 | Also note that if a mismatch occurs during the build, | ||
42 | the correct md5 checksum is placed in the build log and | ||
43 | can be easily copied to the recipe. | ||
44 | </p> | ||
45 | <p> | ||
46 | There is no limit to how many files you can specify using | ||
47 | the <code class="filename">LIC_FILES_CHKSUM</code> variable. | ||
48 | Generally, however, every project requires a few | ||
49 | specifications for license tracking. | ||
50 | Many projects have a "COPYING" file that stores the | ||
51 | license information for all the source code files. | ||
52 | This practice allows you to just track the "COPYING" | ||
53 | file as long as it is kept up to date. | ||
54 | </p> | ||
55 | <div class="note" title="Tips" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
56 | <h3 class="title">Tips</h3> | ||
57 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
58 | <li class="listitem"><p> | ||
59 | If you specify an empty or invalid "md5" | ||
60 | parameter, BitBake returns an md5 mis-match | ||
61 | error and displays the correct "md5" parameter | ||
62 | value during the build. | ||
63 | The correct parameter is also captured in | ||
64 | the build log. | ||
65 | </p></li> | ||
66 | <li class="listitem"><p> | ||
67 | If the whole file contains only license text, | ||
68 | you do not need to use the "beginline" and | ||
69 | "endline" parameters. | ||
70 | </p></li> | ||
71 | </ul></div> | ||
72 | </div> | ||
73 | <p> | ||
74 | </p> | ||
75 | </div></body> | ||
76 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-bitbake.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-bitbake.html deleted file mode 100644 index 39fa32b154..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-bitbake.html +++ /dev/null | |||
@@ -1,82 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.1.1. BitBake</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="yocto-project-components.html" title="3.1. Yocto Project Components"> | ||
9 | <link rel="prev" href="yocto-project-components.html" title="3.1. Yocto Project Components"> | ||
10 | <link rel="next" href="usingpoky-components-metadata.html" title="3.1.2. Metadata (Recipes)"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.1. BitBake"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="usingpoky-components-bitbake"></a>3.1.1. BitBake</h3></div></div></div> | ||
15 | <p> | ||
16 | BitBake is the tool at the heart of the OpenEmbedded build | ||
17 | system and is responsible for parsing the | ||
18 | <a class="link" href="../ref-manual/metadata.html" target="_self">Metadata</a>, | ||
19 | generating a list of tasks from it, and then executing those | ||
20 | tasks. | ||
21 | </p> | ||
22 | <p> | ||
23 | This section briefly introduces BitBake. | ||
24 | If you want more information on BitBake, see the | ||
25 | <a class="link" href="../bitbake-user-manual/bitbake-user-manual.html" target="_self">BitBake User Manual</a>. | ||
26 | </p> | ||
27 | <p> | ||
28 | To see a list of the options BitBake supports, use either of | ||
29 | the following commands: | ||
30 | </p> | ||
31 | <pre class="literallayout"> | ||
32 | $ bitbake -h | ||
33 | $ bitbake --help | ||
34 | </pre> | ||
35 | <p> | ||
36 | </p> | ||
37 | <p> | ||
38 | The most common usage for BitBake is | ||
39 | <code class="filename">bitbake <em class="replaceable"><code>packagename</code></em></code>, | ||
40 | where <code class="filename">packagename</code> is the name of the | ||
41 | package you want to build (referred to as the "target" in this | ||
42 | manual). | ||
43 | The target often equates to the first part of a recipe's | ||
44 | filename (e.g. "foo" for a recipe named | ||
45 | <code class="filename">foo_1.3.0-r0.bb</code>). | ||
46 | So, to process the | ||
47 | <code class="filename">matchbox-desktop_1.2.3.bb</code> recipe file, you | ||
48 | might type the following: | ||
49 | </p> | ||
50 | <pre class="literallayout"> | ||
51 | $ bitbake matchbox-desktop | ||
52 | </pre> | ||
53 | <p> | ||
54 | Several different versions of | ||
55 | <code class="filename">matchbox-desktop</code> might exist. | ||
56 | BitBake chooses the one selected by the distribution | ||
57 | configuration. | ||
58 | You can get more details about how BitBake chooses between | ||
59 | different target versions and providers in the | ||
60 | "<a class="link" href="../bitbake-user-manual/bb-bitbake-preferences.html" target="_self">Preferences</a>" | ||
61 | section of the BitBake User Manual. | ||
62 | </p> | ||
63 | <p> | ||
64 | BitBake also tries to execute any dependent tasks first. | ||
65 | So for example, before building | ||
66 | <code class="filename">matchbox-desktop</code>, BitBake would build a | ||
67 | cross compiler and <code class="filename">glibc</code> if they had not | ||
68 | already been built. | ||
69 | </p> | ||
70 | <p> | ||
71 | A useful BitBake option to consider is the | ||
72 | <code class="filename">-k</code> or <code class="filename">--continue</code> | ||
73 | option. | ||
74 | This option instructs BitBake to try and continue processing | ||
75 | the job as long as possible even after encountering an error. | ||
76 | When an error occurs, the target that failed and those that | ||
77 | depend on it cannot be remade. | ||
78 | However, when you use this option other dependencies can | ||
79 | still be processed. | ||
80 | </p> | ||
81 | </div></body> | ||
82 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-classes.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-classes.html deleted file mode 100644 index 809906c999..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-classes.html +++ /dev/null | |||
@@ -1,30 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.1.4. Classes</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="yocto-project-components.html" title="3.1. Yocto Project Components"> | ||
9 | <link rel="prev" href="metadata-virtual-providers.html" title="3.1.3. Metadata (Virtual Providers)"> | ||
10 | <link rel="next" href="usingpoky-components-configuration.html" title="3.1.5. Configuration"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.4. Classes"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="usingpoky-components-classes"></a>3.1.4. Classes</h3></div></div></div> | ||
15 | <p> | ||
16 | Class files (<code class="filename">.bbclass</code>) contain information | ||
17 | that is useful to share between | ||
18 | <a class="link" href="../ref-manual/metadata.html" target="_self">Metadata</a> | ||
19 | files. | ||
20 | An example is the | ||
21 | <a class="link" href="../ref-manual/ref-classes-autotools.html" target="_self"><code class="filename">autotools</code></a> | ||
22 | class, which contains common settings for any application that | ||
23 | Autotools uses. | ||
24 | The | ||
25 | "<a class="link" href="../ref-manual/ref-classes.html" target="_self">Classes</a>" | ||
26 | chapter in the Yocto Project Reference Manual provides | ||
27 | details about classes and how to use them. | ||
28 | </p> | ||
29 | </div></body> | ||
30 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-configuration.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-configuration.html deleted file mode 100644 index a1ca039c9b..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-configuration.html +++ /dev/null | |||
@@ -1,27 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.1.5. Configuration</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="yocto-project-components.html" title="3.1. Yocto Project Components"> | ||
9 | <link rel="prev" href="usingpoky-components-classes.html" title="3.1.4. Classes"> | ||
10 | <link rel="next" href="cross-development-toolchain-generation.html" title="3.2. Cross-Development Toolchain Generation"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.5. Configuration"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="usingpoky-components-configuration"></a>3.1.5. Configuration</h3></div></div></div> | ||
15 | <p> | ||
16 | The configuration files (<code class="filename">.conf</code>) define | ||
17 | various configuration variables that govern the OpenEmbedded | ||
18 | build process. | ||
19 | These files fall into several areas that define machine | ||
20 | configuration options, distribution configuration options, | ||
21 | compiler tuning options, general common configuration options, | ||
22 | and user configuration options in | ||
23 | <code class="filename">local.conf</code>, which is found in the | ||
24 | <a class="link" href="../ref-manual/build-directory.html" target="_self">Build Directory</a>. | ||
25 | </p> | ||
26 | </div></body> | ||
27 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-metadata.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-metadata.html deleted file mode 100644 index b25324502e..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-components-metadata.html +++ /dev/null | |||
@@ -1,35 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.1.2. Metadata (Recipes)</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="yocto-project-components.html" title="3.1. Yocto Project Components"> | ||
9 | <link rel="prev" href="usingpoky-components-bitbake.html" title="3.1.1. BitBake"> | ||
10 | <link rel="next" href="metadata-virtual-providers.html" title="3.1.3. Metadata (Virtual Providers)"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1.2. Metadata (Recipes)"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="usingpoky-components-metadata"></a>3.1.2. Metadata (Recipes)</h3></div></div></div> | ||
15 | <p> | ||
16 | Files that have the <code class="filename">.bb</code> suffix are | ||
17 | "recipes" files. | ||
18 | In general, a recipe contains information about a single piece | ||
19 | of software. | ||
20 | This information includes the location from which to download | ||
21 | the unaltered source, any source patches to be applied to that | ||
22 | source (if needed), which special configuration options to | ||
23 | apply, how to compile the source files, and how to package the | ||
24 | compiled output. | ||
25 | </p> | ||
26 | <p> | ||
27 | The term "package" is sometimes used to refer to recipes. | ||
28 | However, since the word "package" is used for the packaged | ||
29 | output from the OpenEmbedded build system (i.e. | ||
30 | <code class="filename">.ipk</code> or <code class="filename">.deb</code> files), | ||
31 | this document avoids using the term "package" when referring | ||
32 | to recipes. | ||
33 | </p> | ||
34 | </div></body> | ||
35 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-configuring-LIC_FILES_CHKSUM.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-configuring-LIC_FILES_CHKSUM.html deleted file mode 100644 index ee59e3bc10..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-configuring-LIC_FILES_CHKSUM.html +++ /dev/null | |||
@@ -1,24 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.7.1. Tracking License Changes</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-licenses.html" title="3.7. Licenses"> | ||
9 | <link rel="prev" href="overview-licenses.html" title="3.7. Licenses"> | ||
10 | <link rel="next" href="usingpoky-specifying-LIC_FILES_CHKSUM.html" title="3.7.1.1. Specifying the LIC_FILES_CHKSUM Variable"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.1. Tracking License Changes"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="usingpoky-configuring-LIC_FILES_CHKSUM"></a>3.7.1. Tracking License Changes</h3></div></div></div> | ||
15 | <p> | ||
16 | The license of an upstream project might change in the future. | ||
17 | In order to prevent these changes going unnoticed, the | ||
18 | <a class="link" href="../ref-manual/var-LIC_FILES_CHKSUM.html" target="_self"><code class="filename">LIC_FILES_CHKSUM</code></a> | ||
19 | variable tracks changes to the license text. The checksums are | ||
20 | validated at the end of the configure step, and if the | ||
21 | checksums do not match, the build will fail. | ||
22 | </p> | ||
23 | </div></body> | ||
24 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/usingpoky-specifying-LIC_FILES_CHKSUM.html b/documentation/getting-started/eclipse/html/getting-started/usingpoky-specifying-LIC_FILES_CHKSUM.html deleted file mode 100644 index ed9a3cc501..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/usingpoky-specifying-LIC_FILES_CHKSUM.html +++ /dev/null | |||
@@ -1,82 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.7.1.1. Specifying the LIC_FILES_CHKSUM Variable</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="usingpoky-configuring-LIC_FILES_CHKSUM.html" title="3.7.1. Tracking License Changes"> | ||
9 | <link rel="prev" href="usingpoky-configuring-LIC_FILES_CHKSUM.html" title="3.7.1. Tracking License Changes"> | ||
10 | <link rel="next" href="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax.html" title="3.7.1.2. Explanation of Syntax"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.7.1.1. Specifying the LIC_FILES_CHKSUM Variable"> | ||
13 | <div class="titlepage"><div><div><h4 class="title"> | ||
14 | <a name="usingpoky-specifying-LIC_FILES_CHKSUM"></a>3.7.1.1. Specifying the <code class="filename">LIC_FILES_CHKSUM</code> Variable</h4></div></div></div> | ||
15 | <p> | ||
16 | The <code class="filename">LIC_FILES_CHKSUM</code> | ||
17 | variable contains checksums of the license text in the | ||
18 | source code for the recipe. | ||
19 | Following is an example of how to specify | ||
20 | <code class="filename">LIC_FILES_CHKSUM</code>: | ||
21 | </p> | ||
22 | <pre class="literallayout"> | ||
23 | LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \ | ||
24 | file://licfile1.txt;beginline=5;endline=29;md5=yyyy \ | ||
25 | file://licfile2.txt;endline=50;md5=zzzz \ | ||
26 | ..." | ||
27 | </pre> | ||
28 | <p> | ||
29 | </p> | ||
30 | <div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
31 | <h3 class="title">Notes</h3> | ||
32 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
33 | <li class="listitem"><p> | ||
34 | When using "beginline" and "endline", realize | ||
35 | that line numbering begins with one and not | ||
36 | zero. | ||
37 | Also, the included lines are inclusive (i.e. | ||
38 | lines five through and including 29 in the | ||
39 | previous example for | ||
40 | <code class="filename">licfile1.txt</code>). | ||
41 | </p></li> | ||
42 | <li class="listitem"><p> | ||
43 | When a license check fails, the selected license | ||
44 | text is included as part of the QA message. | ||
45 | Using this output, you can determine the exact | ||
46 | start and finish for the needed license text. | ||
47 | </p></li> | ||
48 | </ul></div> | ||
49 | </div> | ||
50 | <p> | ||
51 | </p> | ||
52 | <p> | ||
53 | The build system uses the | ||
54 | <a class="link" href="../ref-manual/var-S.html" target="_self"><code class="filename">S</code></a> | ||
55 | variable as the default directory when searching files | ||
56 | listed in <code class="filename">LIC_FILES_CHKSUM</code>. | ||
57 | The previous example employs the default directory. | ||
58 | </p> | ||
59 | <p> | ||
60 | Consider this next example: | ||
61 | </p> | ||
62 | <pre class="literallayout"> | ||
63 | LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\ | ||
64 | md5=bb14ed3c4cda583abc85401304b5cd4e" | ||
65 | LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6" | ||
66 | </pre> | ||
67 | <p> | ||
68 | </p> | ||
69 | <p> | ||
70 | The first line locates a file in | ||
71 | <code class="filename">${S}/src/ls.c</code> and isolates lines five | ||
72 | through 16 as license text. | ||
73 | The second line refers to a file in | ||
74 | <a class="link" href="../ref-manual/var-WORKDIR.html" target="_self"><code class="filename">WORKDIR</code></a>. | ||
75 | </p> | ||
76 | <p> | ||
77 | Note that <code class="filename">LIC_FILES_CHKSUM</code> variable is | ||
78 | mandatory for all recipes, unless the | ||
79 | <code class="filename">LICENSE</code> variable is set to "CLOSED". | ||
80 | </p> | ||
81 | </div></body> | ||
82 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/wayland-support.html b/documentation/getting-started/eclipse/html/getting-started/wayland-support.html deleted file mode 100644 index da810a4439..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/wayland-support.html +++ /dev/null | |||
@@ -1,46 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.6.1. Support</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="wayland.html" title="3.6. Wayland"> | ||
9 | <link rel="prev" href="wayland.html" title="3.6. Wayland"> | ||
10 | <link rel="next" href="enabling-wayland-in-an-image.html" title="3.6.2. Enabling Wayland in an Image"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6.1. Support"> | ||
13 | <div class="titlepage"><div><div><h3 class="title"> | ||
14 | <a name="wayland-support"></a>3.6.1. Support</h3></div></div></div> | ||
15 | <p> | ||
16 | The Wayland protocol libraries and the reference Weston | ||
17 | compositor ship as integrated packages in the | ||
18 | <code class="filename">meta</code> layer of the | ||
19 | <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>. | ||
20 | Specifically, you can find the recipes that build both Wayland | ||
21 | and Weston at | ||
22 | <code class="filename">meta/recipes-graphics/wayland</code>. | ||
23 | </p> | ||
24 | <p> | ||
25 | You can build both the Wayland and Weston packages for use only | ||
26 | with targets that accept the | ||
27 | <a class="ulink" href="https://en.wikipedia.org/wiki/Mesa_(computer_graphics)" target="_self">Mesa 3D and Direct Rendering Infrastructure</a>, | ||
28 | which is also known as Mesa DRI. | ||
29 | This implies that you cannot build and use the packages if your | ||
30 | target uses, for example, the | ||
31 | <span class="trademark">Intel</span>® Embedded Media | ||
32 | and Graphics Driver | ||
33 | (<span class="trademark">Intel</span>® EMGD) that | ||
34 | overrides Mesa DRI. | ||
35 | </p> | ||
36 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
37 | <h3 class="title">Note</h3> | ||
38 | Due to lack of EGL support, Weston 1.0.3 will not run | ||
39 | directly on the emulated QEMU hardware. | ||
40 | However, this version of Weston will run under X emulation | ||
41 | without issues. | ||
42 | </div> | ||
43 | <p> | ||
44 | </p> | ||
45 | </div></body> | ||
46 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/wayland.html b/documentation/getting-started/eclipse/html/getting-started/wayland.html deleted file mode 100644 index 0747c9238c..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/wayland.html +++ /dev/null | |||
@@ -1,34 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.6. Wayland</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="fakeroot-and-pseudo.html" title="3.5. Fakeroot and Pseudo"> | ||
10 | <link rel="next" href="wayland-support.html" title="3.6.1. Support"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.6. Wayland"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="wayland"></a>3.6. Wayland</h2></div></div></div> | ||
15 | <p> | ||
16 | <a class="ulink" href="http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)" target="_self">Wayland</a> | ||
17 | is a computer display server protocol that | ||
18 | provides a method for compositing window managers to communicate | ||
19 | directly with applications and video hardware and expects them to | ||
20 | communicate with input hardware using other libraries. | ||
21 | Using Wayland with supporting targets can result in better control | ||
22 | over graphics frame rendering than an application might otherwise | ||
23 | achieve. | ||
24 | </p> | ||
25 | <p> | ||
26 | The Yocto Project provides the Wayland protocol libraries and the | ||
27 | reference | ||
28 | <a class="ulink" href="http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston" target="_self">Weston</a> | ||
29 | compositor as part of its release. | ||
30 | This section describes what you need to do to implement Wayland and | ||
31 | use the compositor when building an image for a supporting target. | ||
32 | </p> | ||
33 | </div></body> | ||
34 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/workflows.html b/documentation/getting-started/eclipse/html/getting-started/workflows.html deleted file mode 100644 index 9d53975678..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/workflows.html +++ /dev/null | |||
@@ -1,207 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.3. Workflows</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-development-environment.html" title="Chapter 2. The Yocto Project Development Environment"> | ||
9 | <link rel="prev" href="open-source-philosophy.html" title="2.2. Open Source Philosophy"> | ||
10 | <link rel="next" href="git.html" title="2.4. Git"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.3. Workflows"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="workflows"></a>2.3. Workflows</h2></div></div></div> | ||
15 | <p> | ||
16 | This section provides workflow concepts using the Yocto Project and | ||
17 | Git. | ||
18 | In particular, the information covers basic practices that describe | ||
19 | roles and actions in a collaborative development environment. | ||
20 | </p> | ||
21 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
22 | <h3 class="title">Note</h3> | ||
23 | If you are familiar with this type of development environment, you | ||
24 | might not want to read this section. | ||
25 | </div> | ||
26 | <p> | ||
27 | </p> | ||
28 | <p> | ||
29 | The Yocto Project files are maintained using Git in "master" | ||
30 | branches whose Git histories track every change and whose structures | ||
31 | provides branches for all diverging functionality. | ||
32 | Although there is no need to use Git, many open source projects do so. | ||
33 | </p> | ||
34 | <p> | ||
35 | |||
36 | </p> | ||
37 | <p> | ||
38 | For the Yocto Project, a key individual called the "maintainer" is | ||
39 | responsible for the "master" branch of a given Git repository. | ||
40 | The "master" branch is the “upstream” repository from which final or | ||
41 | most recent builds of the project occur. | ||
42 | The maintainer is responsible for accepting changes from other | ||
43 | developers and for organizing the underlying branch structure to | ||
44 | reflect release strategies and so forth. | ||
45 | </p> | ||
46 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
47 | <h3 class="title">Note</h3>For information on finding out who is responsible for (maintains) | ||
48 | a particular area of code, see the | ||
49 | "<a class="link" href="../dev-manual/how-to-submit-a-change.html" target="_self">Submitting a Change to the Yocto Project</a>" | ||
50 | section of the Yocto Project Development Tasks Manual. | ||
51 | </div> | ||
52 | <p> | ||
53 | </p> | ||
54 | <p> | ||
55 | The Yocto Project <code class="filename">poky</code> Git repository also has an | ||
56 | upstream contribution Git repository named | ||
57 | <code class="filename">poky-contrib</code>. | ||
58 | You can see all the branches in this repository using the web interface | ||
59 | of the | ||
60 | <a class="ulink" href="http://git.yoctoproject.org" target="_self">Source Repositories</a> organized | ||
61 | within the "Poky Support" area. | ||
62 | These branches temporarily hold changes to the project that have been | ||
63 | submitted or committed by the Yocto Project development team and by | ||
64 | community members who contribute to the project. | ||
65 | The maintainer determines if the changes are qualified to be moved | ||
66 | from the "contrib" branches into the "master" branch of the Git | ||
67 | repository. | ||
68 | </p> | ||
69 | <p> | ||
70 | Developers (including contributing community members) create and | ||
71 | maintain cloned repositories of the upstream "master" branch. | ||
72 | The cloned repositories are local to their development platforms and | ||
73 | are used to develop changes. | ||
74 | When a developer is satisfied with a particular feature or change, | ||
75 | they "push" the changes to the appropriate "contrib" repository. | ||
76 | </p> | ||
77 | <p> | ||
78 | Developers are responsible for keeping their local repository | ||
79 | up-to-date with "master". | ||
80 | They are also responsible for straightening out any conflicts that | ||
81 | might arise within files that are being worked on simultaneously by | ||
82 | more than one person. | ||
83 | All this work is done locally on the developer’s machine before | ||
84 | anything is pushed to a "contrib" area and examined at the maintainer’s | ||
85 | level. | ||
86 | </p> | ||
87 | <p> | ||
88 | A somewhat formal method exists by which developers commit changes | ||
89 | and push them into the "contrib" area and subsequently request that | ||
90 | the maintainer include them into "master". | ||
91 | This process is called “submitting a patch” or "submitting a change." | ||
92 | For information on submitting patches and changes, see the | ||
93 | "<a class="link" href="../dev-manual/how-to-submit-a-change.html" target="_self">Submitting a Change to the Yocto Project</a>" | ||
94 | section in the Yocto Project Development Tasks Manual. | ||
95 | </p> | ||
96 | <p> | ||
97 | To summarize the development workflow: a single point of entry | ||
98 | exists for changes into the project’s "master" branch of the | ||
99 | Git repository, which is controlled by the project’s maintainer. | ||
100 | And, a set of developers exist who independently develop, test, and | ||
101 | submit changes to "contrib" areas for the maintainer to examine. | ||
102 | The maintainer then chooses which changes are going to become a | ||
103 | permanent part of the project. | ||
104 | </p> | ||
105 | <p> | ||
106 | </p> | ||
107 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 270px"><td align="left"><img src="figures/git-workflow.png" align="left" height="270"></td></tr></table> | ||
108 | <p> | ||
109 | </p> | ||
110 | <p> | ||
111 | While each development environment is unique, there are some best | ||
112 | practices or methods that help development run smoothly. | ||
113 | The following list describes some of these practices. | ||
114 | For more information about Git workflows, see the workflow topics in | ||
115 | the | ||
116 | <a class="ulink" href="http://book.git-scm.com" target="_self">Git Community Book</a>. | ||
117 | </p> | ||
118 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
119 | <li class="listitem"> | ||
120 | <p> | ||
121 | <span class="emphasis"><em>Make Small Changes:</em></span> | ||
122 | It is best to keep the changes you commit small as compared to | ||
123 | bundling many disparate changes into a single commit. | ||
124 | This practice not only keeps things manageable but also allows | ||
125 | the maintainer to more easily include or refuse changes.</p> | ||
126 | <p>It is also good practice to leave the repository in a | ||
127 | state that allows you to still successfully build your project. | ||
128 | In other words, do not commit half of a feature, | ||
129 | then add the other half as a separate, later commit. | ||
130 | Each commit should take you from one buildable project state | ||
131 | to another buildable state. | ||
132 | </p> | ||
133 | </li> | ||
134 | <li class="listitem"><p> | ||
135 | <span class="emphasis"><em>Use Branches Liberally:</em></span> | ||
136 | It is very easy to create, use, and delete local branches in | ||
137 | your working Git repository. | ||
138 | You can name these branches anything you like. | ||
139 | It is helpful to give them names associated with the particular | ||
140 | feature or change on which you are working. | ||
141 | Once you are done with a feature or change and have merged it | ||
142 | into your local master branch, simply discard the temporary | ||
143 | branch. | ||
144 | </p></li> | ||
145 | <li class="listitem"><p> | ||
146 | <span class="emphasis"><em>Merge Changes:</em></span> | ||
147 | The <code class="filename">git merge</code> command allows you to take | ||
148 | the changes from one branch and fold them into another branch. | ||
149 | This process is especially helpful when more than a single | ||
150 | developer might be working on different parts of the same | ||
151 | feature. | ||
152 | Merging changes also automatically identifies any collisions | ||
153 | or "conflicts" that might happen as a result of the same lines | ||
154 | of code being altered by two different developers. | ||
155 | </p></li> | ||
156 | <li class="listitem"><p> | ||
157 | <span class="emphasis"><em>Manage Branches:</em></span> | ||
158 | Because branches are easy to use, you should use a system | ||
159 | where branches indicate varying levels of code readiness. | ||
160 | For example, you can have a "work" branch to develop in, a | ||
161 | "test" branch where the code or change is tested, a "stage" | ||
162 | branch where changes are ready to be committed, and so forth. | ||
163 | As your project develops, you can merge code across the | ||
164 | branches to reflect ever-increasing stable states of the | ||
165 | development. | ||
166 | </p></li> | ||
167 | <li class="listitem"><p> | ||
168 | <span class="emphasis"><em>Use Push and Pull:</em></span> | ||
169 | The push-pull workflow is based on the concept of developers | ||
170 | "pushing" local commits to a remote repository, which is | ||
171 | usually a contribution repository. | ||
172 | This workflow is also based on developers "pulling" known | ||
173 | states of the project down into their local development | ||
174 | repositories. | ||
175 | The workflow easily allows you to pull changes submitted by | ||
176 | other developers from the upstream repository into your | ||
177 | work area ensuring that you have the most recent software | ||
178 | on which to develop. | ||
179 | The Yocto Project has two scripts named | ||
180 | <code class="filename">create-pull-request</code> and | ||
181 | <code class="filename">send-pull-request</code> that ship with the | ||
182 | release to facilitate this workflow. | ||
183 | You can find these scripts in the <code class="filename">scripts</code> | ||
184 | folder of the | ||
185 | <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>. | ||
186 | For information on how to use these scripts, see the | ||
187 | "<a class="link" href="../dev-manual/pushing-a-change-upstream.html" target="_self">Using Scripts to Push a Change Upstream and Request a Pull</a>" | ||
188 | section in the Yocto Project Development Tasks Manual. | ||
189 | </p></li> | ||
190 | <li class="listitem"><p> | ||
191 | <span class="emphasis"><em>Patch Workflow:</em></span> | ||
192 | This workflow allows you to notify the maintainer through an | ||
193 | email that you have a change (or patch) you would like | ||
194 | considered for the "master" branch of the Git repository. | ||
195 | To send this type of change, you format the patch and then | ||
196 | send the email using the Git commands | ||
197 | <code class="filename">git format-patch</code> and | ||
198 | <code class="filename">git send-email</code>. | ||
199 | For information on how to use these scripts, see the | ||
200 | "<a class="link" href="../dev-manual/how-to-submit-a-change.html" target="_self">Submitting a Change to the Yocto Project</a>" | ||
201 | section in the Yocto Project Development Tasks Manual. | ||
202 | </p></li> | ||
203 | </ul></div> | ||
204 | <p> | ||
205 | </p> | ||
206 | </div></body> | ||
207 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/x32.html b/documentation/getting-started/eclipse/html/getting-started/x32.html deleted file mode 100644 index daffedbeea..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/x32.html +++ /dev/null | |||
@@ -1,75 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.8. x32 psABI</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="other-variables-related-to-commercial-licenses.html" title="3.7.2.2. Other Variables Related to Commercial Licenses"> | ||
10 | </head> | ||
11 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.8. x32 psABI"> | ||
12 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
13 | <a name="x32"></a>3.8. x32 psABI</h2></div></div></div> | ||
14 | <p> | ||
15 | x32 processor-specific Application Binary Interface | ||
16 | (<a class="ulink" href="https://software.intel.com/en-us/node/628948" target="_self">x32 psABI</a>) | ||
17 | is a native 32-bit processor-specific ABI for | ||
18 | <span class="trademark">Intel</span>® 64 (x86-64) | ||
19 | architectures. | ||
20 | An ABI defines the calling conventions between functions in a | ||
21 | processing environment. | ||
22 | The interface determines what registers are used and what the sizes are | ||
23 | for various C data types. | ||
24 | </p> | ||
25 | <p> | ||
26 | Some processing environments prefer using 32-bit applications even | ||
27 | when running on Intel 64-bit platforms. | ||
28 | Consider the i386 psABI, which is a very old 32-bit ABI for Intel | ||
29 | 64-bit platforms. | ||
30 | The i386 psABI does not provide efficient use and access of the | ||
31 | Intel 64-bit processor resources, leaving the system underutilized. | ||
32 | Now consider the x86_64 psABI. | ||
33 | This ABI is newer and uses 64-bits for data sizes and program | ||
34 | pointers. | ||
35 | The extra bits increase the footprint size of the programs, | ||
36 | libraries, and also increases the memory and file system size | ||
37 | requirements. | ||
38 | Executing under the x32 psABI enables user programs to utilize CPU | ||
39 | and system resources more efficiently while keeping the memory | ||
40 | footprint of the applications low. | ||
41 | Extra bits are used for registers but not for addressing mechanisms. | ||
42 | </p> | ||
43 | <p> | ||
44 | The Yocto Project supports the final specifications of x32 psABI | ||
45 | as follows: | ||
46 | </p> | ||
47 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
48 | <li class="listitem"><p> | ||
49 | You can create packages and images in x32 psABI format on | ||
50 | x86_64 architecture targets. | ||
51 | </p></li> | ||
52 | <li class="listitem"><p> | ||
53 | You can successfully build recipes with the x32 toolchain. | ||
54 | </p></li> | ||
55 | <li class="listitem"><p> | ||
56 | You can create and boot | ||
57 | <code class="filename">core-image-minimal</code> and | ||
58 | <code class="filename">core-image-sato</code> images. | ||
59 | </p></li> | ||
60 | <li class="listitem"><p> | ||
61 | RPM Package Manager (RPM) support exists for x32 binaries. | ||
62 | </p></li> | ||
63 | <li class="listitem"><p> | ||
64 | Support for large images exists. | ||
65 | </p></li> | ||
66 | </ul></div> | ||
67 | <p> | ||
68 | </p> | ||
69 | <p> | ||
70 | For steps on how to use x32 psABI, see the | ||
71 | "<a class="link" href="../dev-manual/using-x32-psabi.html" target="_self">Using x32 psABI</a>" | ||
72 | section in the Yocto Project Development Tasks Manual. | ||
73 | </p> | ||
74 | </div></body> | ||
75 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/yocto-project-components.html b/documentation/getting-started/eclipse/html/getting-started/yocto-project-components.html deleted file mode 100644 index 0ad63b2402..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/yocto-project-components.html +++ /dev/null | |||
@@ -1,62 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>3.1. Yocto Project Components</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="overview-concepts.html" title="Chapter 3. Yocto Project Concepts"> | ||
10 | <link rel="next" href="usingpoky-components-bitbake.html" title="3.1.1. BitBake"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.1. Yocto Project Components"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="yocto-project-components"></a>3.1. Yocto Project Components</h2></div></div></div> | ||
15 | <p> | ||
16 | The | ||
17 | <a class="link" href="../ref-manual/bitbake-term.html" target="_self">BitBake</a> | ||
18 | task executor together with various types of configuration files | ||
19 | form the OpenEmbedded Core. | ||
20 | This section overviews these components by describing their use and | ||
21 | how they interact. | ||
22 | </p> | ||
23 | <p> | ||
24 | BitBake handles the parsing and execution of the data files. | ||
25 | The data itself is of various types: | ||
26 | </p> | ||
27 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
28 | <li class="listitem"><p> | ||
29 | <span class="emphasis"><em>Recipes:</em></span> | ||
30 | Provides details about particular pieces of software. | ||
31 | </p></li> | ||
32 | <li class="listitem"><p> | ||
33 | <span class="emphasis"><em>Class Data:</em></span> | ||
34 | Abstracts common build information (e.g. how to build a | ||
35 | Linux kernel). | ||
36 | </p></li> | ||
37 | <li class="listitem"><p> | ||
38 | <span class="emphasis"><em>Configuration Data:</em></span> | ||
39 | Defines machine-specific settings, policy decisions, and | ||
40 | so forth. | ||
41 | Configuration data acts as the glue to bind everything | ||
42 | together. | ||
43 | </p></li> | ||
44 | </ul></div> | ||
45 | <p> | ||
46 | </p> | ||
47 | <p> | ||
48 | BitBake knows how to combine multiple data sources together and | ||
49 | refers to each data source as a layer. | ||
50 | For information on layers, see the | ||
51 | "<a class="link" href="../dev-manual/understanding-and-creating-layers.html" target="_self">Understanding and Creating Layers</a>" | ||
52 | section of the Yocto Project Development Tasks Manual. | ||
53 | </p> | ||
54 | <p> | ||
55 | Following are some brief details on these core components. | ||
56 | For additional information on how these components interact during | ||
57 | a build, see the | ||
58 | "<a class="link" href="development-concepts.html" title="2.8. Development Concepts">Development Concepts</a>" | ||
59 | section. | ||
60 | </p> | ||
61 | </div></body> | ||
62 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/yocto-project-repositories.html b/documentation/getting-started/eclipse/html/getting-started/yocto-project-repositories.html deleted file mode 100644 index 3dcc2af5eb..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/yocto-project-repositories.html +++ /dev/null | |||
@@ -1,135 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.5. Yocto Project Source Repositories</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-development-environment.html" title="Chapter 2. The Yocto Project Development Environment"> | ||
9 | <link rel="prev" href="basic-commands.html" title="2.4.2. Basic Commands"> | ||
10 | <link rel="next" href="licensing.html" title="2.6. Licensing"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.5. Yocto Project Source Repositories"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="yocto-project-repositories"></a>2.5. Yocto Project Source Repositories</h2></div></div></div> | ||
15 | <p> | ||
16 | The Yocto Project team maintains complete source repositories for all | ||
17 | Yocto Project files at | ||
18 | <a class="ulink" href="http://git.yoctoproject.org/cgit/cgit.cgi" target="_self">http://git.yoctoproject.org/cgit/cgit.cgi</a>. | ||
19 | This web-based source code browser is organized into categories by | ||
20 | function such as IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and | ||
21 | so forth. | ||
22 | From the interface, you can click on any particular item in the "Name" | ||
23 | column and see the URL at the bottom of the page that you need to clone | ||
24 | a Git repository for that particular item. | ||
25 | Having a local Git repository of the | ||
26 | <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a>, | ||
27 | which is usually named "poky", allows | ||
28 | you to make changes, contribute to the history, and ultimately enhance | ||
29 | the Yocto Project's tools, Board Support Packages, and so forth. | ||
30 | </p> | ||
31 | <p> | ||
32 | For any supported release of Yocto Project, you can also go to the | ||
33 | <a class="ulink" href="http://www.yoctoproject.org" target="_self">Yocto Project Website</a> and | ||
34 | select the "Downloads" tab and get a released tarball of the | ||
35 | <code class="filename">poky</code> repository or any supported BSP tarballs. | ||
36 | Unpacking these tarballs gives you a snapshot of the released | ||
37 | files. | ||
38 | </p> | ||
39 | <div class="note" title="Notes" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
40 | <h3 class="title">Notes</h3> | ||
41 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
42 | <li class="listitem"><p> | ||
43 | The recommended method for setting up the Yocto Project | ||
44 | <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a> | ||
45 | and the files for supported BSPs | ||
46 | (e.g., <code class="filename">meta-intel</code>) is to use | ||
47 | <a class="link" href="git.html" title="2.4. Git">Git</a> to create a local copy of | ||
48 | the upstream repositories. | ||
49 | </p></li> | ||
50 | <li class="listitem"><p> | ||
51 | Be sure to always work in matching branches for both | ||
52 | the selected BSP repository and the | ||
53 | <a class="link" href="../ref-manual/source-directory.html" target="_self">Source Directory</a> | ||
54 | (i.e. <code class="filename">poky</code>) repository. | ||
55 | For example, if you have checked out the "master" branch | ||
56 | of <code class="filename">poky</code> and you are going to use | ||
57 | <code class="filename">meta-intel</code>, be sure to checkout the | ||
58 | "master" branch of <code class="filename">meta-intel</code>. | ||
59 | </p></li> | ||
60 | </ul></div> | ||
61 | </div> | ||
62 | <p> | ||
63 | </p> | ||
64 | <p> | ||
65 | In summary, here is where you can get the project files needed for | ||
66 | development: | ||
67 | </p> | ||
68 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
69 | <li class="listitem"> | ||
70 | <p><a name="source-repositories"></a> | ||
71 | <span class="emphasis"><em> | ||
72 | <a class="ulink" href="http://git.yoctoproject.org/cgit/cgit.cgi" target="_self">Source Repositories:</a> | ||
73 | </em></span> | ||
74 | This area contains IDE Plugins, Matchbox, Poky, Poky Support, | ||
75 | Tools, Yocto Linux Kernel, and Yocto Metadata Layers. | ||
76 | You can create local copies of Git repositories for each of | ||
77 | these areas.</p> | ||
78 | <p> | ||
79 | </p> | ||
80 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 360px"><td align="center"><img src="figures/source-repos.png" align="middle" width="540"></td></tr></table> | ||
81 | <p> | ||
82 | For steps on how to view and access these upstream Git | ||
83 | repositories, see the | ||
84 | "<a class="link" href="../dev-manual/accessing-source-repositories.html" target="_self">Accessing Source Repositories</a>" | ||
85 | Section in the Yocto Project Development Tasks Manual. | ||
86 | </p> | ||
87 | </li> | ||
88 | <li class="listitem"> | ||
89 | <p><a name="index-downloads"></a> | ||
90 | <span class="emphasis"><em> | ||
91 | <a class="ulink" href="http://downloads.yoctoproject.org/releases/" target="_self">Index of /releases:</a> | ||
92 | </em></span> | ||
93 | This is an index of releases such as | ||
94 | the <span class="trademark">Eclipse</span>™ | ||
95 | Yocto Plug-in, miscellaneous support, Poky, Pseudo, installers | ||
96 | for cross-development toolchains, and all released versions of | ||
97 | Yocto Project in the form of images or tarballs. | ||
98 | Downloading and extracting these files does not produce a local | ||
99 | copy of the Git repository but rather a snapshot of a | ||
100 | particular release or image.</p> | ||
101 | <p> | ||
102 | </p> | ||
103 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 315px"><td align="center"><img src="figures/index-downloads.png" align="middle" height="315"></td></tr></table> | ||
104 | <p> | ||
105 | For steps on how to view and access these files, see the | ||
106 | "<a class="link" href="../dev-manual/accessing-index-of-releases.html" target="_self">Accessing Index of Releases</a>" | ||
107 | section in the Yocto Project Development Tasks Manual. | ||
108 | </p> | ||
109 | </li> | ||
110 | <li class="listitem"> | ||
111 | <p><a name="downloads-page"></a> | ||
112 | <span class="emphasis"><em>"Downloads" page for the | ||
113 | <a class="ulink" href="http://www.yoctoproject.org" target="_self">Yocto Project Website</a>: | ||
114 | </em></span></p> | ||
115 | <p class="writernotes">This section will change due to | ||
116 | reworking of the YP Website.</p> | ||
117 | <p>The Yocto Project website includes a "Downloads" tab | ||
118 | that allows you to download any Yocto Project | ||
119 | release and Board Support Package (BSP) in tarball form. | ||
120 | The tarballs are similar to those found in the | ||
121 | <a class="ulink" href="http://downloads.yoctoproject.org/releases/" target="_self">Index of /releases:</a> area.</p> | ||
122 | <p> | ||
123 | </p> | ||
124 | <table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="540"><tr style="height: 360px"><td align="center"><img src="figures/yp-download.png" align="middle" width="540"></td></tr></table> | ||
125 | <p> | ||
126 | For steps on how to use the "Downloads" page, see the | ||
127 | "<a class="link" href="../dev-manual/using-the-downloads-page.html" target="_self">Using the Downloads Page</a>" | ||
128 | section in the Yocto Project Development Tasks Manual. | ||
129 | </p> | ||
130 | </li> | ||
131 | </ul></div> | ||
132 | <p> | ||
133 | </p> | ||
134 | </div></body> | ||
135 | </html> | ||
diff --git a/documentation/getting-started/eclipse/html/getting-started/yp-intro.html b/documentation/getting-started/eclipse/html/getting-started/yp-intro.html deleted file mode 100644 index 42ad0d3088..0000000000 --- a/documentation/getting-started/eclipse/html/getting-started/yp-intro.html +++ /dev/null | |||
@@ -1,119 +0,0 @@ | |||
1 | <html> | ||
2 | <head> | ||
3 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> | ||
4 | <title>2.1. Introduction</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-development-environment.html" title="Chapter 2. The Yocto Project Development Environment"> | ||
9 | <link rel="prev" href="overview-development-environment.html" title="Chapter 2. The Yocto Project Development Environment"> | ||
10 | <link rel="next" href="open-source-philosophy.html" title="2.2. Open Source Philosophy"> | ||
11 | </head> | ||
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.1. Introduction"> | ||
13 | <div class="titlepage"><div><div><h2 class="title" style="clear: both"> | ||
14 | <a name="yp-intro"></a>2.1. Introduction</h2></div></div></div> | ||
15 | <p> | ||
16 | The Yocto Project is an open-source collaboration project whose | ||
17 | focus is for developers of embedded Linux systems. | ||
18 | Among other things, the Yocto Project uses an | ||
19 | <a class="link" href="../ref-manual/build-system-term.html" target="_self">OpenEmbedded build system</a>. | ||
20 | The build system, which is based on the OpenEmbedded (OE) project and | ||
21 | uses the | ||
22 | <a class="link" href="../ref-manual/bitbake-term.html" target="_self">BitBake</a> tool, | ||
23 | constructs complete Linux images for architectures based on ARM, MIPS, | ||
24 | PowerPC, x86 and x86-64. | ||
25 | </p> | ||
26 | <div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;"> | ||
27 | <h3 class="title">Note</h3> | ||
28 | Historically, the OpenEmbedded build system, which is the | ||
29 | combination of BitBake and OE components, formed a reference | ||
30 | build host that was known as | ||
31 | "<a class="link" href="../ref-manual/poky.html" target="_self">Poky</a>" | ||
32 | (<span class="emphasis"><em>Pah</em></span>-kee). | ||
33 | The term "Poky", as used throughout the Yocto Project Documentation | ||
34 | set, can have different meanings. | ||
35 | </div> | ||
36 | <p> | ||
37 | The Yocto Project provides various ancillary tools for the embedded | ||
38 | developer and also features the Sato reference User Interface, which | ||
39 | is optimized for stylus-driven, low-resolution screens. | ||
40 | </p> | ||
41 | <div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="720"><tr><td align="center"><img src="figures/YP-flow-diagram.png" align="middle" width="720"></td></tr></table></div> | ||
42 | <p> | ||
43 | Here are some highlights for the Yocto Project: | ||
44 | </p> | ||
45 | <div class="itemizedlist"><ul class="itemizedlist" type="disc"> | ||
46 | <li class="listitem"><p> | ||
47 | Provides a recent Linux kernel along with a set of system | ||
48 | commands and libraries suitable for the embedded | ||
49 | environment. | ||
50 | </p></li> | ||
51 | <li class="listitem"><p> | ||
52 | Makes available system components such as X11, GTK+, Qt, | ||
53 | Clutter, and SDL (among others) so you can create a rich user | ||
54 | experience on devices that have display hardware. | ||
55 | For devices that do not have a display or where you wish to | ||
56 | use alternative UI frameworks, these components need not be | ||
57 | installed. | ||
58 | </p></li> | ||
59 | <li class="listitem"><p> | ||
60 | Creates a focused and stable core compatible with the | ||
61 | OpenEmbedded project with which you can easily and reliably | ||
62 | build and develop. | ||
63 | </p></li> | ||
64 | <li class="listitem"><p> | ||
65 | Fully supports a wide range of hardware and device emulation | ||
66 | through the Quick EMUlator (QEMU). | ||
67 | </p></li> | ||
68 | <li class="listitem"><p> | ||
69 | Provides a layer mechanism that allows you to easily extend | ||
70 | the system, make customizations, and keep them organized. | ||
71 | </p></li> | ||
72 | </ul></div> | ||
73 | <p> | ||
74 | You can use the Yocto Project to generate images for many kinds | ||
75 | of devices. | ||
76 | As mentioned earlier, the Yocto Project supports creation of | ||
77 | reference images that you can boot within and emulate using QEMU. | ||
78 | The standard example machines target QEMU full-system | ||
79 | emulation for 32-bit and 64-bit variants of x86, ARM, MIPS, and | ||
80 | PowerPC architectures. | ||
81 | Beyond emulation, you can use the layer mechanism to extend | ||
82 | support to just about any platform that Linux can run on and that | ||
83 | a toolchain can target. | ||
84 | </p> | ||
85 | <p> | ||
86 | Another Yocto Project feature is the Sato reference User | ||
87 | Interface. | ||
88 | This optional UI that is based on GTK+ is intended for devices with | ||
89 | restricted screen sizes and is included as part of the | ||
90 | OpenEmbedded Core layer so that developers can test parts of the | ||
91 | software stack. | ||
92 | </p> | ||
93 | <p> | ||
94 | While the Yocto Project does not provide a strict testing framework, | ||
95 | it does provide or generate for you artifacts that let you perform | ||
96 | target-level and emulated testing and debugging. | ||
97 | Additionally, if you are an | ||
98 | <span class="trademark">Eclipse</span>™ IDE user, you can | ||
99 | install an Eclipse Yocto Plug-in to allow you to develop within that | ||
100 | familiar environment. | ||
101 | </p> | ||
102 | <p> | ||
103 | By default, using the Yocto Project to build an image creates a Poky | ||
104 | distribution. | ||
105 | However, you can create your own distribution by providing key | ||
106 | <a class="link" href="../ref-manual/metadata.html" target="_self">Metadata</a>. | ||
107 | A good example is Angstrom, which has had a distribution | ||
108 | based on the Yocto Project since its inception. | ||
109 | Other examples include commercial distributions like | ||
110 | <a class="ulink" href="https://www.yoctoproject.org/organization/wind-river-systems" target="_self">Wind River Linux</a>, | ||
111 | <a class="ulink" href="https://www.yoctoproject.org/organization/mentor-graphics" target="_self">Mentor Embedded Linux</a>, | ||
112 | <a class="ulink" href="https://www.yoctoproject.org/organization/enea-ab" target="_self">ENEA Linux</a> | ||
113 | and <a class="ulink" href="https://www.yoctoproject.org/ecosystem/member-organizations" target="_self">others</a>. | ||
114 | See the "<a class="link" href="../dev-manual/creating-your-own-distribution.html" target="_self">Creating Your Own Distribution</a>" | ||
115 | section in the Yocto Project Development Tasks Manual for more | ||
116 | information. | ||
117 | </p> | ||
118 | </div></body> | ||
119 | </html> | ||