summaryrefslogtreecommitdiffstats
path: root/documentation/dev-manual/dev-manual-newbie.xml
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/dev-manual/dev-manual-newbie.xml')
-rw-r--r--documentation/dev-manual/dev-manual-newbie.xml103
1 files changed, 57 insertions, 46 deletions
diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 57079fa0c5..fbd12946e1 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -119,6 +119,63 @@
119 </para> 119 </para>
120</section> 120</section>
121 121
122<section id='yocto-project-terms'>
123 <title>Yocto Project Terms</title>
124
125 <para>
126 Following is a list of terms and definitions users new to the Yocto Project development
127 environment might find helpful.
128 Some terms are universal but are included here just in case:
129 <itemizedlist>
130 <listitem><para><emphasis>Image</emphasis> - An image is a collection of recipes created with
131 Bitbake (baked).
132 Images run on specific hardware and use cases.</para></listitem>
133 <listitem><para><emphasis>Recipe</emphasis> - A set of instructions for building packages.
134 A recipe describes where you get source code and which patches to apply.
135 Recipes describe dependencies for libraries or for other recipes and they
136 also contain configuration and compilation options.
137 Recipes also let you ‘install’ customizations.
138 Recipes contain the logical unit of execution, the software/images to build and
139 use the <filename>.bb</filename> file extension.</para></listitem>
140 <listitem><para><emphasis>BitBake</emphasis> - The task executor and scheduler used by Yocto Project
141 to build images.
142 For more information on BitBake, see the <ulink url='http://bitbake.berlios.de/manual/'>
143 BitBake documentation</ulink>.</para></listitem>
144 <listitem><para><emphasis>Package</emphasis> - A collection of ‘baked’ recipes.
145 You ‘bake’ something by running it through Bitbake.</para></listitem>
146 <listitem><para><emphasis>Layer</emphasis> - A logical collection of recipes representing the core,
147 a BSP, or an application stack.</para></listitem>
148 <listitem><para><emphasis>Metadata</emphasis> - Information for a build that is generally
149 architecture-independent.
150 This information includes Task definitions in recipes, classes, and configuration
151 information.</para></listitem>
152 <listitem><para><emphasis>Configuration File</emphasis>: Configuration information in the
153 <filename>.conf</filename> files provides global definitions of variables.
154 The <filename>build/conf/local.conf</filename> configuration file defines local user-defined variables.
155 The <filename>distro/poky.conf</filename> configuration file defines Yocto ‘distro’ configuration
156 variables.
157 The <filename>machine/beagleboard.conf</filename> configuration file defines machine-specific variables
158 (i.e. Texas Instruments ARM Cortex-A8 development board in this example.
159 Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
160 <listitem><para><emphasis>Classes</emphasis> - Files that encapsulate and inherit logic.
161 Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
162 <listitem><para><emphasis>Append Files</emphasis> - Files that append build information to
163 a recipe file.
164 Information in append files override the information in the similarly-named recipe file.
165 Append files use the <filename>.bbappend</filename> filename suffix.</para></listitem>
166 <listitem><para><emphasis>Tasks</emphasis> - Arbitrary groups of software used to contain Recipes.
167 You simply use Tasks to hold recipes that when build usually accomplished a single task.
168 For example, a task could contain the recipes for a company’s proprietary or value-add software.
169 Or the task could contain the recipes that enable graphics.
170 A task is really just another recipe.
171 Because task files are recipes, they end with the <filename>.bb</filename> filename
172 extension.</para></listitem>
173 <listitem><para><emphasis>Common OE-Core</emphasis> - A core set of metadata originating
174 with OpenEmbedded (OE) that is shared between OE and the Yocto Project.</para></listitem>
175 </itemizedlist>
176 </para>
177</section>
178
122<section id='licensing'> 179<section id='licensing'>
123 <title>Licensing</title> 180 <title>Licensing</title>
124 181
@@ -287,52 +344,6 @@
287 </para> 344 </para>
288 345
289 <para> 346 <para>
290 Following are the definitions for some terms used in the Yocto Project.
291 [WRITER NOTE: I need to move this list of definitions somewhere useful.]
292 <itemizedlist>
293 <listitem><para><emphasis>Image</emphasis> - An image is a collection of recipes created with
294 Bitbake (baked). Images run on specific hardware and use cases.</para></listitem>
295 <listitem><para><emphasis>Recipe</emphasis> - A set of instructions for building packages.
296 A recipe describes where you get the source and which patches to apply.
297 Recipes describe dependencies for libraries or for other recipes and they
298 also contain configuration and compilation options.
299 Recipes also let you ‘install’ customizations.
300 Recipes contain the logical unit of execution, the software/images to build and
301 use the <filename>.bb</filename> file extension.</para></listitem>
302 <listitem><para><emphasis>BitBake</emphasis> - The task executor and scheduler used by Yocto Project
303 to build images.
304 For more information on BitBake, see the <ulink url='http://bitbake.berlios.de/manual/'>
305 BitBake documentation</ulink>.</para></listitem>
306 <listitem><para><emphasis>Package</emphasis> - A collection of ‘baked’ recipes.
307 You ‘bake’ something by running it through Bitbake.</para></listitem>
308 <listitem><para><emphasis>Layer</emphasis> - A logical collection of recipes representing the core,
309 a BSP, or an application stack.</para></listitem>
310 <listitem><para><emphasis>Metadata</emphasis> - Information for a build that is generally
311 architecture-independent.
312 This information includes Task definitions in recipes, classes, and configuration
313 information.</para></listitem>
314 <listitem><para><emphasis>Configuration File</emphasis>: Configuration information in the
315 <filename>.conf</filename> files provides global definition of variables.
316 The <filename>build/conf/local.conf</filename> configuration file defines local user-defined variables.
317 The <filename>distro/poky.conf</filename> configuration file defines Yocto ‘distro’ configuration
318 variables.
319 The <filename>machine/beagleboard.conf</filename> configuration file defines machine-specific variables.
320 Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
321 <listitem><para><emphasis>Classes</emphasis> - Files that encapsulate and inherit logic.
322 Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
323 <listitem><para><emphasis>Tasks</emphasis> - Arbitrary groups of software used to contain Recipes.
324 You simply use Tasks to hold recipes that when build usually accomplished a single task.
325 For example, a task could contain the recipes for a company’s proprietary or value-add software.
326 Or the task could contain the recipes that enable graphics.
327 A task is really just another recipe.
328 Because task files are recipes, they end with the <filename>.bb</filename> filename
329 extension.</para></listitem>
330 <listitem><para><emphasis>Common OE-Core</emphasis> - A core set of metadata originating
331 with OpenEmbedded (OE) that is shared between OE and the Yocto Project.</para></listitem>
332 </itemizedlist>
333 </para>
334
335 <para>
336 A master Git repository exists that contains the project. 347 A master Git repository exists that contains the project.
337 Usually a key individual is responsible for this repository. 348 Usually a key individual is responsible for this repository.
338 It is the “upstream” repository where the final builds of the project occur. 349 It is the “upstream” repository where the final builds of the project occur.