diff options
Diffstat (limited to 'documentation/ref-manual/ref-terms.xml')
-rw-r--r-- | documentation/ref-manual/ref-terms.xml | 525 |
1 files changed, 0 insertions, 525 deletions
diff --git a/documentation/ref-manual/ref-terms.xml b/documentation/ref-manual/ref-terms.xml deleted file mode 100644 index 2a0452bd78..0000000000 --- a/documentation/ref-manual/ref-terms.xml +++ /dev/null | |||
@@ -1,525 +0,0 @@ | |||
1 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" | ||
2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" | ||
3 | [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > | ||
4 | <!--SPDX-License-Identifier: CC-BY-2.0-UK--> | ||
5 | |||
6 | <chapter id='ref-terms'> | ||
7 | <title>Yocto Project Terms</title> | ||
8 | |||
9 | <para> | ||
10 | Following is a list of terms and definitions users new to the Yocto | ||
11 | Project development environment might find helpful. | ||
12 | While some of these terms are universal, the list includes them | ||
13 | just in case: | ||
14 | <itemizedlist> | ||
15 | <listitem><para> | ||
16 | <emphasis>Append Files:</emphasis> | ||
17 | Files that append build information to a recipe file. | ||
18 | Append files are known as BitBake append files and | ||
19 | <filename>.bbappend</filename> files. | ||
20 | The OpenEmbedded build system expects every append file to have | ||
21 | a corresponding recipe (<filename>.bb</filename>) file. | ||
22 | Furthermore, the append file and corresponding recipe file | ||
23 | must use the same root filename. | ||
24 | The filenames can differ only in the file type suffix used | ||
25 | (e.g. | ||
26 | <filename>formfactor_0.0.bb</filename> and | ||
27 | <filename>formfactor_0.0.bbappend</filename>).</para> | ||
28 | |||
29 | <para>Information in append files extends or overrides the | ||
30 | information in the similarly-named recipe file. | ||
31 | For an example of an append file in use, see the | ||
32 | "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer</ulink>" | ||
33 | section in the Yocto Project Development Tasks Manual.</para> | ||
34 | |||
35 | <para>When you name an append file, you can use the | ||
36 | "<filename>%</filename>" wildcard character to allow for | ||
37 | matching recipe names. | ||
38 | For example, suppose you have an append file named as follows: | ||
39 | <literallayout class='monospaced'> | ||
40 | busybox_1.21.%.bbappend | ||
41 | </literallayout> | ||
42 | That append file would match any | ||
43 | <filename>busybox_1.21.</filename><replaceable>x</replaceable><filename>.bb</filename> | ||
44 | version of the recipe. | ||
45 | So, the append file would match any of the following recipe names: | ||
46 | <literallayout class='monospaced'> | ||
47 | busybox_1.21.1.bb | ||
48 | busybox_1.21.2.bb | ||
49 | busybox_1.21.3.bb | ||
50 | busybox_1.21.10.bb | ||
51 | busybox_1.21.25.bb | ||
52 | </literallayout> | ||
53 | <note><title>Important</title> | ||
54 | The use of the "<filename>%</filename>" character | ||
55 | is limited in that it only works directly in front of the | ||
56 | <filename>.bbappend</filename> portion of the append file's | ||
57 | name. | ||
58 | You cannot use the wildcard character in any other | ||
59 | location of the name. | ||
60 | </note> | ||
61 | </para></listitem> | ||
62 | <listitem><para id='bitbake-term'> | ||
63 | <emphasis>BitBake:</emphasis> | ||
64 | The task executor and scheduler used by the OpenEmbedded build | ||
65 | system to build images. | ||
66 | For more information on BitBake, see the | ||
67 | <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>. | ||
68 | </para></listitem> | ||
69 | <listitem><para id='board-support-package-bsp-term'> | ||
70 | <emphasis>Board Support Package (BSP):</emphasis> | ||
71 | A group of drivers, definitions, and other components that | ||
72 | provide support for a specific hardware configuration. | ||
73 | For more information on BSPs, see the | ||
74 | <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>. | ||
75 | </para></listitem> | ||
76 | <listitem> | ||
77 | <para id='build-directory'> | ||
78 | <emphasis>Build Directory:</emphasis> | ||
79 | This term refers to the area used by the OpenEmbedded build | ||
80 | system for builds. | ||
81 | The area is created when you <filename>source</filename> the | ||
82 | setup environment script that is found in the Source Directory | ||
83 | (i.e. <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>). | ||
84 | The | ||
85 | <link linkend='var-TOPDIR'><filename>TOPDIR</filename></link> | ||
86 | variable points to the Build Directory.</para> | ||
87 | |||
88 | <para>You have a lot of flexibility when creating the Build | ||
89 | Directory. | ||
90 | Following are some examples that show how to create the | ||
91 | directory. | ||
92 | The examples assume your | ||
93 | <link linkend='source-directory'>Source Directory</link> is | ||
94 | named <filename>poky</filename>: | ||
95 | <itemizedlist> | ||
96 | <listitem><para>Create the Build Directory inside your | ||
97 | Source Directory and let the name of the Build | ||
98 | Directory default to <filename>build</filename>: | ||
99 | <literallayout class='monospaced'> | ||
100 | $ cd $HOME/poky | ||
101 | $ source &OE_INIT_FILE; | ||
102 | </literallayout> | ||
103 | </para></listitem> | ||
104 | <listitem><para>Create the Build Directory inside your | ||
105 | home directory and specifically name it | ||
106 | <filename>test-builds</filename>: | ||
107 | <literallayout class='monospaced'> | ||
108 | $ cd $HOME | ||
109 | $ source poky/&OE_INIT_FILE; test-builds | ||
110 | </literallayout> | ||
111 | </para></listitem> | ||
112 | <listitem><para> | ||
113 | Provide a directory path and specifically name the | ||
114 | Build Directory. | ||
115 | Any intermediate folders in the pathname must exist. | ||
116 | This next example creates a Build Directory named | ||
117 | <filename>YP-&POKYVERSION;</filename> | ||
118 | in your home directory within the existing | ||
119 | directory <filename>mybuilds</filename>: | ||
120 | <literallayout class='monospaced'> | ||
121 | $ cd $HOME | ||
122 | $ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION; | ||
123 | </literallayout> | ||
124 | </para></listitem> | ||
125 | </itemizedlist> | ||
126 | <note> | ||
127 | By default, the Build Directory contains | ||
128 | <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>, | ||
129 | which is a temporary directory the build system uses for | ||
130 | its work. | ||
131 | <filename>TMPDIR</filename> cannot be under NFS. | ||
132 | Thus, by default, the Build Directory cannot be under NFS. | ||
133 | However, if you need the Build Directory to be under NFS, | ||
134 | you can set this up by setting <filename>TMPDIR</filename> | ||
135 | in your <filename>local.conf</filename> file | ||
136 | to use a local drive. | ||
137 | Doing so effectively separates <filename>TMPDIR</filename> | ||
138 | from <filename>TOPDIR</filename>, which is the Build | ||
139 | Directory. | ||
140 | </note> | ||
141 | </para></listitem> | ||
142 | <listitem><para id='hardware-build-system-term'> | ||
143 | <emphasis>Build Host:</emphasis> | ||
144 | The system used to build images in a Yocto Project | ||
145 | Development environment. | ||
146 | The build system is sometimes referred to as the | ||
147 | <firstterm>development host</firstterm>. | ||
148 | </para></listitem> | ||
149 | <listitem><para> | ||
150 | <emphasis>Classes:</emphasis> | ||
151 | Files that provide for logic encapsulation and inheritance so | ||
152 | that commonly used patterns can be defined once and then | ||
153 | easily used in multiple recipes. | ||
154 | For reference information on the Yocto Project classes, see the | ||
155 | "<link linkend='ref-classes'>Classes</link>" chapter. | ||
156 | Class files end with the <filename>.bbclass</filename> | ||
157 | filename extension. | ||
158 | </para></listitem> | ||
159 | <listitem><para> | ||
160 | <emphasis>Configuration File:</emphasis> | ||
161 | Files that hold global definitions of variables, | ||
162 | user-defined variables, and hardware configuration | ||
163 | information. | ||
164 | These files tell the OpenEmbedded build system what to | ||
165 | build and what to put into the image to support a | ||
166 | particular platform.</para> | ||
167 | |||
168 | <para>Configuration files end with a <filename>.conf</filename> | ||
169 | filename extension. | ||
170 | The <filename>conf/local.conf</filename> configuration file in | ||
171 | the | ||
172 | <link linkend='build-directory'>Build Directory</link> | ||
173 | contains user-defined variables that affect every build. | ||
174 | The <filename>meta-poky/conf/distro/poky.conf</filename> | ||
175 | configuration file defines Yocto "distro" configuration | ||
176 | variables used only when building with this policy. | ||
177 | Machine configuration files, which | ||
178 | are located throughout the | ||
179 | <link linkend='source-directory'>Source Directory</link>, define | ||
180 | variables for specific hardware and are only used when building | ||
181 | for that target (e.g. the | ||
182 | <filename>machine/beaglebone.conf</filename> configuration | ||
183 | file defines variables for the Texas Instruments ARM Cortex-A8 | ||
184 | development board). | ||
185 | </para></listitem> | ||
186 | <listitem><para id='term-container-layer'> | ||
187 | <emphasis>Container Layer:</emphasis> | ||
188 | Layers that hold other layers. | ||
189 | An example of a container layer is OpenEmbedded's | ||
190 | <ulink url='https://github.com/openembedded/meta-openembedded'><filename>meta-openembedded</filename></ulink> | ||
191 | layer. | ||
192 | The <filename>meta-openembedded</filename> layer contains | ||
193 | many <filename>meta-*</filename> layers. | ||
194 | </para></listitem> | ||
195 | <listitem><para id='cross-development-toolchain'> | ||
196 | <emphasis>Cross-Development Toolchain:</emphasis> | ||
197 | In general, a cross-development toolchain is a collection of | ||
198 | software development tools and utilities that run on one | ||
199 | architecture and allow you to develop software for a | ||
200 | different, or targeted, architecture. | ||
201 | These toolchains contain cross-compilers, linkers, and | ||
202 | debuggers that are specific to the target architecture.</para> | ||
203 | |||
204 | <para>The Yocto Project supports two different cross-development | ||
205 | toolchains: | ||
206 | <itemizedlist> | ||
207 | <listitem><para> | ||
208 | A toolchain only used by and within | ||
209 | BitBake when building an image for a target | ||
210 | architecture. | ||
211 | </para></listitem> | ||
212 | <listitem><para>A relocatable toolchain used outside of | ||
213 | BitBake by developers when developing applications | ||
214 | that will run on a targeted device. | ||
215 | </para></listitem> | ||
216 | </itemizedlist></para> | ||
217 | |||
218 | <para>Creation of these toolchains is simple and automated. | ||
219 | For information on toolchain concepts as they apply to the | ||
220 | Yocto Project, see the | ||
221 | "<ulink url='&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>" | ||
222 | section in the Yocto Project Overview and Concepts Manual. | ||
223 | You can also find more information on using the | ||
224 | relocatable toolchain in the | ||
225 | <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink> | ||
226 | manual. | ||
227 | </para></listitem> | ||
228 | <listitem><para> | ||
229 | <emphasis>Extensible Software Development Kit (eSDK):</emphasis> | ||
230 | A custom SDK for application developers. | ||
231 | This eSDK allows developers to incorporate their library | ||
232 | and programming changes back into the image to make | ||
233 | their code available to other application developers.</para> | ||
234 | |||
235 | <para>For information on the eSDK, see the | ||
236 | <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink> | ||
237 | manual. | ||
238 | </para></listitem> | ||
239 | <listitem><para> | ||
240 | <emphasis>Image:</emphasis> | ||
241 | An image is an artifact of the BitBake build process given | ||
242 | a collection of recipes and related Metadata. | ||
243 | Images are the binary output that run on specific hardware or | ||
244 | QEMU and are used for specific use-cases. | ||
245 | For a list of the supported image types that the Yocto Project | ||
246 | provides, see the | ||
247 | "<link linkend='ref-images'>Images</link>" | ||
248 | chapter. | ||
249 | </para></listitem> | ||
250 | <listitem><para> | ||
251 | <emphasis>Layer:</emphasis> | ||
252 | A collection of related recipes. | ||
253 | Layers allow you to consolidate related metadata to | ||
254 | customize your build. | ||
255 | Layers also isolate information used when building | ||
256 | for multiple architectures. | ||
257 | Layers are hierarchical in their ability to override | ||
258 | previous specifications. | ||
259 | You can include any number of available layers from the | ||
260 | Yocto Project and customize the build by adding your | ||
261 | layers after them. | ||
262 | You can search the Layer Index for layers used within | ||
263 | Yocto Project.</para> | ||
264 | |||
265 | <para>For introductory information on layers, see the | ||
266 | "<ulink url='&YOCTO_DOCS_OM_URL;#the-yocto-project-layer-model'>The Yocto Project Layer Model</ulink>" | ||
267 | section in the Yocto Project Overview and Concepts Manual. | ||
268 | For more detailed information on layers, see the | ||
269 | "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" | ||
270 | section in the Yocto Project Development Tasks Manual. | ||
271 | For a discussion specifically on BSP Layers, see the | ||
272 | "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" | ||
273 | section in the Yocto Project Board Support Packages (BSP) | ||
274 | Developer's Guide. | ||
275 | </para></listitem> | ||
276 | <listitem><para id='metadata'> | ||
277 | <emphasis>Metadata:</emphasis> | ||
278 | A key element of the Yocto Project is the Metadata that | ||
279 | is used to construct a Linux distribution and is contained | ||
280 | in the files that the | ||
281 | <link linkend='build-system-term'>OpenEmbedded build system</link> | ||
282 | parses when building an image. | ||
283 | In general, Metadata includes recipes, configuration | ||
284 | files, and other information that refers to the build | ||
285 | instructions themselves, as well as the data used to | ||
286 | control what things get built and the effects of the | ||
287 | build. | ||
288 | Metadata also includes commands and data used to | ||
289 | indicate what versions of software are used, from | ||
290 | where they are obtained, and changes or additions to the | ||
291 | software itself (patches or auxiliary files) that | ||
292 | are used to fix bugs or customize the software for use | ||
293 | in a particular situation. | ||
294 | OpenEmbedded-Core is an important set of validated | ||
295 | metadata.</para> | ||
296 | |||
297 | <para>In the context of the kernel ("kernel Metadata"), the | ||
298 | term refers to the kernel config fragments and features | ||
299 | contained in the | ||
300 | <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache'><filename>yocto-kernel-cache</filename></ulink> | ||
301 | Git repository. | ||
302 | </para></listitem> | ||
303 | <listitem><para id='oe-core'> | ||
304 | <emphasis>OpenEmbedded-Core (OE-Core):</emphasis> | ||
305 | OE-Core is metadata comprised of foundational recipes, | ||
306 | classes, and associated files that are meant to be | ||
307 | common among many different OpenEmbedded-derived systems, | ||
308 | including the Yocto Project. | ||
309 | OE-Core is a curated subset of an original repository | ||
310 | developed by the OpenEmbedded community that has been | ||
311 | pared down into a smaller, core set of continuously | ||
312 | validated recipes. | ||
313 | The result is a tightly controlled and an quality-assured | ||
314 | core set of recipes.</para> | ||
315 | |||
316 | <para>You can see the Metadata in the | ||
317 | <filename>meta</filename> directory of the Yocto Project | ||
318 | <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Source Repositories</ulink>. | ||
319 | </para></listitem> | ||
320 | <listitem><para id='build-system-term'> | ||
321 | <emphasis>OpenEmbedded Build System:</emphasis> | ||
322 | The build system specific to the Yocto Project. | ||
323 | The OpenEmbedded build system is based on another project known | ||
324 | as "Poky", which uses | ||
325 | <link linkend='bitbake-term'>BitBake</link> as the task | ||
326 | executor. | ||
327 | Throughout the Yocto Project documentation set, the | ||
328 | OpenEmbedded build system is sometimes referred to simply | ||
329 | as "the build system". | ||
330 | If other build systems, such as a host or target build system | ||
331 | are referenced, the documentation clearly states the | ||
332 | difference. | ||
333 | <note> | ||
334 | For some historical information about Poky, see the | ||
335 | <link linkend='poky'>Poky</link> term. | ||
336 | </note> | ||
337 | </para></listitem> | ||
338 | <listitem><para> | ||
339 | <emphasis>Package:</emphasis> | ||
340 | In the context of the Yocto Project, this term refers to a | ||
341 | recipe's packaged output produced by BitBake (i.e. a | ||
342 | "baked recipe"). | ||
343 | A package is generally the compiled binaries produced from the | ||
344 | recipe's sources. | ||
345 | You "bake" something by running it through BitBake.</para> | ||
346 | |||
347 | <para>It is worth noting that the term "package" can, | ||
348 | in general, have subtle meanings. | ||
349 | For example, the packages referred to in the | ||
350 | "<link linkend='required-packages-for-the-build-host'>Required Packages for the Build Host</link>" | ||
351 | section are compiled binaries that, when installed, add | ||
352 | functionality to your Linux distribution.</para> | ||
353 | |||
354 | <para>Another point worth noting is that historically within | ||
355 | the Yocto Project, recipes were referred to as packages - thus, | ||
356 | the existence of several BitBake variables that are seemingly | ||
357 | mis-named, | ||
358 | (e.g. <link linkend='var-PR'><filename>PR</filename></link>, | ||
359 | <link linkend='var-PV'><filename>PV</filename></link>, and | ||
360 | <link linkend='var-PE'><filename>PE</filename></link>). | ||
361 | </para></listitem> | ||
362 | <listitem><para> | ||
363 | <emphasis>Package Groups:</emphasis> | ||
364 | Arbitrary groups of software Recipes. | ||
365 | You use package groups to hold recipes that, when built, | ||
366 | usually accomplish a single task. | ||
367 | For example, a package group could contain the recipes for a | ||
368 | company's proprietary or value-add software. | ||
369 | Or, the package group could contain the recipes that enable | ||
370 | graphics. | ||
371 | A package group is really just another recipe. | ||
372 | Because package group files are recipes, they end with the | ||
373 | <filename>.bb</filename> filename extension. | ||
374 | </para></listitem> | ||
375 | <listitem><para id='poky'> | ||
376 | <emphasis>Poky:</emphasis> | ||
377 | Poky, which is pronounced <emphasis>Pock</emphasis>-ee, | ||
378 | is a reference embedded distribution and a reference | ||
379 | test configuration. | ||
380 | Poky provides the following: | ||
381 | <itemizedlist> | ||
382 | <listitem><para> | ||
383 | A base-level functional distro used to illustrate | ||
384 | how to customize a distribution. | ||
385 | </para></listitem> | ||
386 | <listitem><para> | ||
387 | A means by which to test the Yocto Project | ||
388 | components (i.e. Poky is used to validate | ||
389 | the Yocto Project). | ||
390 | </para></listitem> | ||
391 | <listitem><para> | ||
392 | A vehicle through which you can download | ||
393 | the Yocto Project. | ||
394 | </para></listitem> | ||
395 | </itemizedlist> | ||
396 | Poky is not a product level distro. | ||
397 | Rather, it is a good starting point for customization. | ||
398 | <note> | ||
399 | Poky began as an open-source | ||
400 | project initially developed by OpenedHand. | ||
401 | OpenedHand developed Poky from the existing | ||
402 | OpenEmbedded build system to create a commercially | ||
403 | supportable build system for embedded Linux. | ||
404 | After Intel Corporation acquired OpenedHand, the | ||
405 | poky project became the basis for the Yocto Project's | ||
406 | build system. | ||
407 | </note> | ||
408 | </para></listitem> | ||
409 | <listitem><para> | ||
410 | <emphasis>Recipe:</emphasis> | ||
411 | A set of instructions for building packages. | ||
412 | A recipe describes where you get source code, which patches | ||
413 | to apply, how to configure the source, how to compile it and so on. | ||
414 | Recipes also describe dependencies for libraries or for other | ||
415 | recipes. | ||
416 | Recipes represent the logical unit of execution, the software | ||
417 | to build, the images to build, and use the | ||
418 | <filename>.bb</filename> file extension. | ||
419 | </para></listitem> | ||
420 | <listitem><para id='reference-kit-term'> | ||
421 | <emphasis>Reference Kit:</emphasis> | ||
422 | A working example of a system, which includes a | ||
423 | <link linkend='board-support-package-bsp-term'>BSP</link> | ||
424 | as well as a | ||
425 | <link linkend='hardware-build-system-term'>build host</link> | ||
426 | and other components, that can work on specific hardware. | ||
427 | </para></listitem> | ||
428 | <listitem> | ||
429 | <para id='source-directory'> | ||
430 | <emphasis>Source Directory:</emphasis> | ||
431 | This term refers to the directory structure created as a result | ||
432 | of creating a local copy of the <filename>poky</filename> Git | ||
433 | repository <filename>git://git.yoctoproject.org/poky</filename> | ||
434 | or expanding a released <filename>poky</filename> tarball. | ||
435 | <note> | ||
436 | Creating a local copy of the <filename>poky</filename> | ||
437 | Git repository is the recommended method for setting up | ||
438 | your Source Directory. | ||
439 | </note> | ||
440 | Sometimes you might hear the term "poky directory" used to refer | ||
441 | to this directory structure. | ||
442 | <note> | ||
443 | The OpenEmbedded build system does not support file or | ||
444 | directory names that contain spaces. | ||
445 | Be sure that the Source Directory you use does not contain | ||
446 | these types of names. | ||
447 | </note></para> | ||
448 | |||
449 | <para>The Source Directory contains BitBake, Documentation, | ||
450 | Metadata and other files that all support the Yocto Project. | ||
451 | Consequently, you must have the Source Directory in place on | ||
452 | your development system in order to do any development using | ||
453 | the Yocto Project.</para> | ||
454 | |||
455 | <para>When you create a local copy of the Git repository, you | ||
456 | can name the repository anything you like. | ||
457 | Throughout much of the documentation, "poky" | ||
458 | is used as the name of the top-level folder of the local copy of | ||
459 | the poky Git repository. | ||
460 | So, for example, cloning the <filename>poky</filename> Git | ||
461 | repository results in a local Git repository whose top-level | ||
462 | folder is also named "poky".</para> | ||
463 | |||
464 | <para>While it is not recommended that you use tarball expansion | ||
465 | to set up the Source Directory, if you do, the top-level | ||
466 | directory name of the Source Directory is derived from the | ||
467 | Yocto Project release tarball. | ||
468 | For example, downloading and unpacking | ||
469 | <filename>&YOCTO_POKY_TARBALL;</filename> results in a | ||
470 | Source Directory whose root folder is named | ||
471 | <filename>&YOCTO_POKY;</filename>.</para> | ||
472 | |||
473 | <para>It is important to understand the differences between the | ||
474 | Source Directory created by unpacking a released tarball as | ||
475 | compared to cloning | ||
476 | <filename>git://git.yoctoproject.org/poky</filename>. | ||
477 | When you unpack a tarball, you have an exact copy of the files | ||
478 | based on the time of release - a fixed release point. | ||
479 | Any changes you make to your local files in the Source Directory | ||
480 | are on top of the release and will remain local only. | ||
481 | On the other hand, when you clone the <filename>poky</filename> | ||
482 | Git repository, you have an active development repository with | ||
483 | access to the upstream repository's branches and tags. | ||
484 | In this case, any local changes you make to the local | ||
485 | Source Directory can be later applied to active development | ||
486 | branches of the upstream <filename>poky</filename> Git | ||
487 | repository.</para> | ||
488 | |||
489 | <para>For more information on concepts related to Git | ||
490 | repositories, branches, and tags, see the | ||
491 | "<ulink url='&YOCTO_DOCS_OM_URL;#repositories-tags-and-branches'>Repositories, Tags, and Branches</ulink>" | ||
492 | section in the Yocto Project Overview and Concepts Manual. | ||
493 | </para></listitem> | ||
494 | <listitem><para><emphasis>Task:</emphasis> | ||
495 | A unit of execution for BitBake (e.g. | ||
496 | <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>, | ||
497 | <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>, | ||
498 | <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>, | ||
499 | and so forth). | ||
500 | </para></listitem> | ||
501 | <listitem><para id='toaster-term'><emphasis>Toaster:</emphasis> | ||
502 | A web interface to the Yocto Project's | ||
503 | <link linkend='build-system-term'>OpenEmbedded Build System</link>. | ||
504 | The interface enables you to configure and run your builds. | ||
505 | Information about builds is collected and stored in a database. | ||
506 | For information on Toaster, see the | ||
507 | <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>. | ||
508 | </para></listitem> | ||
509 | <listitem><para> | ||
510 | <emphasis>Upstream:</emphasis> | ||
511 | A reference to source code or repositories | ||
512 | that are not local to the development system but located in a | ||
513 | master area that is controlled by the maintainer of the source | ||
514 | code. | ||
515 | For example, in order for a developer to work on a particular | ||
516 | piece of code, they need to first get a copy of it from an | ||
517 | "upstream" source. | ||
518 | </para></listitem> | ||
519 | </itemizedlist> | ||
520 | </para> | ||
521 | |||
522 | </chapter> | ||
523 | <!-- | ||
524 | vim: expandtab tw=80 ts=4 | ||
525 | --> | ||