blob: ccf5e274a7dc6455455e95d3d530543667d77d9c [file] [log] [blame]
Brad Bishop316dfdd2018-06-25 12:45:53 -04001<!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
5<chapter id='overview-yp'>
6 <title>Introducing the Yocto Project</title>
7
8 <section id='what-is-the-yocto-project'>
9 <title>What is the Yocto Project?</title>
10
11 <para>
12 The Yocto Project is an open source collaboration project
13 that helps developers create custom Linux-based systems that are
14 designed for embedded products regardless of the product's hardware
15 architecture.
16 Yocto Project provides a flexible toolset and a development
17 environment that allows embedded device developers across the
18 world to collaborate through shared technologies, software stacks,
19 configurations, and best practices used to create these tailored
20 Linux images.
21 </para>
22
23 <para>
24 Thousands of developers worldwide have discovered that Yocto
25 Project provides advantages in both systems and applications
26 development, archival and management benefits, and customizations
27 used for speed, footprint, and memory utilization.
28 The project is a standard when it comes to delivering embedded
29 software stacks.
30 The project allows software customizations and build interchange
31 for multiple hardware platforms as well as software stacks that
32 can be maintained and scaled.
33 </para>
34
35 <para id='yp-key-dev-elements'>
36 <imagedata fileref="figures/key-dev-elements.png" format="PNG" align='center' width="8in"/>
37 </para>
38
39 <para>
40 For further introductory information on the Yocto Project, you
41 might be interested in this
42 <ulink url='https://www.embedded.com/electronics-blogs/say-what-/4458600/Why-the-Yocto-Project-for-my-IoT-Project-'>article</ulink>
43 by Drew Moseley and in this short introductory
44 <ulink url='https://www.youtube.com/watch?v=utZpKM7i5Z4'>video</ulink>.
45 </para>
46
47 <para>
48 The remainder of this section overviews advantages and challenges
49 tied to the Yocto Project.
50 </para>
51
52 <section id='gs-features'>
53 <title>Features</title>
54
55 <para>
56 The following list describes features and advantages of the
57 Yocto Project:
58 <itemizedlist>
59 <listitem><para>
60 <emphasis>Widely Adopted Across the Industry:</emphasis>
61 Semiconductor, operating system, software, and
62 service vendors exist whose products and services
63 adopt and support the Yocto Project.
64 For a look at the Yocto Project community and
65 the companies involved with the Yocto
66 Project, see the "COMMUNITY" and "ECOSYSTEM" tabs
67 on the
68 <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink>
69 home page.
70 </para></listitem>
71 <listitem><para>
72 <emphasis>Architecture Agnostic:</emphasis>
73 Yocto Project supports Intel, ARM, MIPS, AMD, PPC
74 and other architectures.
75 Most ODMs, OSVs, and chip vendors create and supply
76 BSPs that support their hardware.
77 If you have custom silicon, you can create a BSP
78 that supports that architecture.</para>
79
80 <para>Aside from lots of architecture support, the
81 Yocto Project fully supports a wide range of device
82 emulation through the Quick EMUlator (QEMU).
83 </para></listitem>
84 <listitem><para>
85 <emphasis>Images and Code Transfer Easily:</emphasis>
86 Yocto Project output can easily move between
87 architectures without moving to new development
88 environments.
89 Additionally, if you have used the Yocto Project to
90 create an image or application and you find yourself
91 not able to support it, commercial Linux vendors such
92 as Wind River, Mentor Graphics, Timesys, and ENEA could
93 take it and provide ongoing support.
94 These vendors have offerings that are built using
95 the Yocto Project.
96 </para></listitem>
97 <listitem><para>
98 <emphasis>Flexibility:</emphasis>
99 Corporations use the Yocto Project many different ways.
100 One example is to create an internal Linux distribution
101 as a code base the corporation can use across multiple
102 product groups.
103 Through customization and layering, a project group
104 can leverage the base Linux distribution to create
105 a distribution that works for their product needs.
106 </para></listitem>
107 <listitem><para>
108 <emphasis>Ideal for Constrained Embedded and IoT devices:</emphasis>
109 Unlike a full Linux distribution, you can use the
110 Yocto Project to create exactly what you need for
111 embedded devices.
112 You only add the feature support or packages that you
113 absolutely need for the device.
114 For devices that have display hardware, you can use
115 available system components such as X11, GTK+, Qt,
116 Clutter, and SDL (among others) to create a rich user
117 experience.
118 For devices that do not have a display or where you
119 want to use alternative UI frameworks, you can choose
120 to not install these components.
121 </para></listitem>
122 <listitem><para>
123 <emphasis>Comprehensive Toolchain Capabilities:</emphasis>
124 Toolchains for supported architectures satisfy most
125 use cases.
126 However, if your hardware supports features that are
127 not part of a standard toolchain, you can easily
128 customize that toolchain through specification of
129 platform-specific tuning parameters.
130 And, should you need to use a third-party toolchain,
131 mechanisms built into the Yocto Project allow for that.
132 </para></listitem>
133 <listitem><para>
134 <emphasis>Mechanism Rules Over Policy:</emphasis>
135 Focusing on mechanism rather than policy ensures that
136 you are free to set policies based on the needs of your
137 design instead of adopting decisions enforced by some
138 system software provider.
139 </para></listitem>
140 <listitem><para>
141 <emphasis>Uses a Layer Model:</emphasis>
142 The Yocto Project
143 <link linkend='the-yocto-project-layer-model'>layer infrastructure</link>
144 groups related functionality into separate bundles.
145 You can incrementally add these grouped functionalities
146 to your project as needed.
147 Using layers to isolate and group functionality
148 reduces project complexity and redundancy, allows you
149 to easily extend the system, make customizations,
150 and keep functionality organized.
151 </para></listitem>
152 <listitem><para>
153 <emphasis>Supports Partial Builds:</emphasis>
154 You can build and rebuild individual packages as
155 needed.
156 Yocto Project accomplishes this through its
157 <link linkend='shared-state-cache'>shared-state cache</link>
158 (sstate) scheme.
159 Being able to build and debug components individually
160 eases project development.
161 </para></listitem>
162 <listitem><para>
163 <emphasis>Releases According to a Strict Schedule:</emphasis>
164 Major releases occur on a
165 <ulink url='&YOCTO_DOCS_REF_URL;#ref-release-process'>six-month cycle</ulink>
166 predictably in October and April.
167 The most recent two releases support point releases
168 to address common vulnerabilities and exposures.
169 This predictability is crucial for projects based on
170 the Yocto Project and allows development teams to
171 plan activities.
172 </para></listitem>
173 <listitem><para>
174 <emphasis>Rich Ecosystem of Individuals and Organizations:</emphasis>
175 For open source projects, the value of community is
176 very important.
177 Support forums, expertise, and active developers who
178 continue to push the Yocto Project forward are readily
179 available.
180 </para></listitem>
181 <listitem><para>
182 <emphasis>Binary Reproducibility:</emphasis>
183 The Yocto Project allows you to be very specific about
184 dependencies and achieves very high percentages of
185 binary reproducibility (e.g. 99.8% for
186 <filename>core-image-minimal</filename>).
187 When distributions are not specific about which
188 packages are pulled in and in what order to support
189 dependencies, other build systems can arbitrarily
190 include packages.
191 </para></listitem>
192 <listitem><para>
193 <emphasis>License Manifest:</emphasis>
194 The Yocto Project provides a
195 <ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>license manifest</ulink>
196 for review by people who need to track the use of open
197 source licenses (e.g.legal teams).
198 </para></listitem>
199 </itemizedlist>
200 </para>
201 </section>
202
203 <section id='gs-challenges'>
204 <title>Challenges</title>
205
206 <para>
207 The following list presents challenges you might encounter
208 when developing using the Yocto Project:
209 <itemizedlist>
210 <listitem><para>
211 <emphasis>Steep Learning Curve:</emphasis>
212 The Yocto Project has a steep learning curve and has
213 many different ways to accomplish similar tasks.
214 It can be difficult to choose how to proceed when
215 varying methods exist by which to accomplish a given
216 task.
217 </para></listitem>
218 <listitem><para>
219 <emphasis>Understanding What Changes You Need to Make
220 For Your Design Requires Some Research:</emphasis>
221 Beyond the simple tutorial stage, understanding what
222 changes need to be made for your particular design
223 can require a significant amount of research and
224 investigation.
225 For information that helps you transition from
226 trying out the Yocto Project to using it for your
227 project, see the
228 "<ulink url='&YOCTO_HOME_URL;/docs/what-i-wish-id-known/'>What I wish I'd Known</ulink>"
229 and
230 "<ulink url='&YOCTO_HOME_URL;/docs/transitioning-to-a-custom-environment/'>Transitioning to a Custom Environment for Systems Development</ulink>"
231 documents on the Yocto Project website.
232 </para></listitem>
233 <listitem><para>
234 <emphasis>Project Workflow Could Be Confusing:</emphasis>
235 The
236 <link linkend='overview-development-environment'>Yocto Project workflow</link>
237 could be confusing if you are used to traditional
238 desktop and server software development.
239 In a desktop development environment, mechanisms exist
240 to easily pull and install new packages, which are
241 typically pre-compiled binaries from servers accessible
242 over the Internet.
243 Using the Yocto Project, you must modify your
244 configuration and rebuild to add additional packages.
245 </para></listitem>
246 <listitem><para>
247 <emphasis>Working in a Cross-Build Environment Can
248 Feel Unfamiliar:</emphasis>
249 When developing code to run on a target, compilation,
250 execution, and testing done on the actual target
251 can be faster than running a BitBake build on a
252 development host and then deploying binaries to the
253 target for test.
254 While the Yocto Project does support development tools
255 on the target, the additional step of integrating your
256 changes back into the Yocto Project build environment
257 would be required.
258 Yocto Project supports an intermediate approach that
259 involves making changes on the development system
260 within the BitBake environment and then deploying only
261 the updated packages to the target.</para>
262
263 <para>The Yocto Project
264 <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>
265 produces packages in standard formats (i.e. RPM,
266 DEB, IPK, and TAR).
267 You can deploy these packages into the running system
268 on the target by using utilities on the target such
269 as <filename>rpm</filename> or
270 <filename>ipk</filename>.
271 </para></listitem>
272 <listitem><para>
273 <emphasis>Initial Build Times Can be Significant:</emphasis>
274 Long initial build times are unfortunately unavoidable
275 due to the large number of packages initially built
276 from scratch for a fully functioning Linux system.
277 Once that initial build is completed, however, the
278 shared-state (sstate) cache mechanism Yocto Project
279 uses keeps the system from rebuilding packages that
280 have not been "touched" since the last build.
281 The sstate mechanism significantly reduces times
282 for successive builds.
283 </para></listitem>
284 </itemizedlist>
285 </para>
286 </section>
287 </section>
288
289 <section id='the-yocto-project-layer-model'>
290 <title>The Yocto Project Layer Model</title>
291
292 <para>
293 The Yocto Project's "Layer Model" is a development model for
294 embedded and IoT Linux creation that distinguishes the
295 Yocto Project from other simple build systems.
296 The Layer Model simultaneously supports collaboration and
297 customization.
298 Layers are repositories that contain related sets of instructions
299 that tell the
300 <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>
301 what to do.
302 You can collaborate, share, and reuse layers.
303 </para>
304
305 <para>
306 Layers can contain changes to previous instructions or settings
307 at any time.
308 This powerful override capability is what allows you to customize
309 previously supplied collaborative or community layers to suit your
310 product requirements.
311 </para>
312
313 <para>
314 You use different layers to logically separate information in your
315 build.
316 As an example, you could have BSP, GUI, distro configuration,
317 middleware, or application layers.
318 Putting your entire build into one layer limits and complicates
319 future customization and reuse.
320 Isolating information into layers, on the other hand, helps
321 simplify future customizations and reuse.
322 You might find it tempting to keep everything in one layer when
323 working on a single project.
324 However, the more modular your Metadata, the easier
325 it is to cope with future changes.
326 <note><title>Notes</title>
327 <itemizedlist>
328 <listitem><para>
329 Use Board Support Package (BSP) layers from silicon
330 vendors when possible.
331 </para></listitem>
332 <listitem><para>
333 Familiarize yourself with the
334 <ulink url='https://caffelli-staging.yoctoproject.org/software-overview/layers/'>Yocto Project curated layer index</ulink>
335 or the
336 <ulink url='http://layers.openembedded.org/layerindex/branch/master/layers/'>OpenEmbedded layer index</ulink>.
337 The latter contains more layers but they are less
338 universally validated.
339 </para></listitem>
340 <listitem><para>
341 Layers support the inclusion of technologies, hardware
342 components, and software components.
343 The
344 <ulink url='&YOCTO_DOCS_DEV_URL;#making-sure-your-layer-is-compatible-with-yocto-project'>Yocto Project Compatible</ulink>
345 designation provides a minimum level of standardization
346 that contributes to a strong ecosystem.
347 "YP Compatible" is applied to appropriate products and
348 software components such as BSPs, other OE-compatible
349 layers, and related open-source projects, allowing the
350 producer to use Yocto Project badges and branding
351 assets.
352 </para></listitem>
353 </itemizedlist>
354 </note>
355 </para>
356
357 <para>
358 To illustrate how layers are used to keep things modular, consider
359 machine customizations.
360 These types of customizations typically reside in a special layer,
361 rather than a general layer, called a BSP Layer.
362 Furthermore, the machine customizations should be isolated from
363 recipes and Metadata that support a new GUI environment,
364 for example.
365 This situation gives you a couple of layers: one for the machine
366 configurations, and one for the GUI environment.
367 It is important to understand, however, that the BSP layer can
368 still make machine-specific additions to recipes within the GUI
369 environment layer without polluting the GUI layer itself
370 with those machine-specific changes.
371 You can accomplish this through a recipe that is a BitBake append
372 (<filename>.bbappend</filename>) file, which is described later
373 in this section.
374 <note>
375 For general information on BSP layer structure, see the
376 <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Packages (BSP) Developer's Guide</ulink>.
377 </note>
378 </para>
379
380 <para>
381 The
382 <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
383 contains both general layers and BSP layers right out of the box.
384 You can easily identify layers that ship with a Yocto Project
385 release in the Source Directory by their names.
386 Layers typically have names that begin with the string
387 <filename>meta-</filename>.
388 <note>
389 It is not a requirement that a layer name begin with the
390 prefix <filename>meta-</filename>, but it is a commonly
391 accepted standard in the Yocto Project community.
392 </note>
393 For example, if you were to examine the
394 <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/'>tree view</ulink>
395 of the <filename>poky</filename> repository, you will see several
396 layers: <filename>meta</filename>,
397 <filename>meta-skeleton</filename>,
398 <filename>meta-selftest</filename>,
399 <filename>meta-poky</filename>, and
400 <filename>meta-yocto-bsp</filename>.
401 Each of these repositories represents a distinct layer.
402 </para>
403
404 <para>
405 For procedures on how to create layers, see the
406 "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
407 section in the Yocto Project Development Tasks Manual.
408 </para>
409 </section>
410
411 <section id='components-and-tools'>
412 <title>Components and Tools</title>
413
414 <para>
415 The Yocto Project employs a collection of components and
416 tools used by the project itself, by project developers,
417 and by those using the Yocto Project.
418 These components and tools are open source projects and
419 metadata that are separate from the reference distribution
420 (<ulink url='&YOCTO_DOCS_REF_URL;#poky'>Poky</ulink>)
421 and the
422 <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>.
423 Most of the components and tools are downloaded separately.
424 </para>
425
426 <para>
427 This section provides brief overviews of the components and
428 tools associated with the Yocto Project.
429 </para>
430
431 <section id='gs-development-tools'>
432 <title>Development Tools</title>
433
434 <para>
435 The following list consists of tools that help you develop
436 images and applications using the Yocto Project:
437 <itemizedlist>
438 <listitem><para id='gs-crops-overview'>
439 <emphasis>CROPS:</emphasis>
440 <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink>
441 is an open source, cross-platform development framework
442 that leverages
443 <ulink url='https://www.docker.com/'>Docker Containers</ulink>.
444 CROPS provides an easily managed, extensible environment
445 that allows you to build binaries for a variety of
446 architectures on Windows, Linux and Mac OS X hosts.
447 </para></listitem>
448 <listitem><para>
449 <emphasis><filename>devtool</filename>:</emphasis>
450 This command-line tool is available as part of the
451 extensible SDK (eSDK) and is its cornerstone.
452 You can use <filename>devtool</filename> to help build,
453 test, and package software within the eSDK.
454 You can use the tool to optionally integrate what you
455 build into an image built by the OpenEmbedded build
456 system.</para>
457
458 <para>The <filename>devtool</filename> command employs
459 a number of sub-commands that allow you to add, modify,
460 and upgrade recipes.
461 As with the OpenEmbedded build system, “recipes”
462 represent software packages within
463 <filename>devtool</filename>.
464 When you use <filename>devtool add</filename>, a recipe
465 is automatically created.
466 When you use <filename>devtool modify</filename>, the
467 specified existing recipe is used in order to determine
468 where to get the source code and how to patch it.
469 In both cases, an environment is set up so that when
470 you build the recipe a source tree that is under your
471 control is used in order to allow you to make changes
472 to the source as desired.
473 By default, both new recipes and the source go into
474 a “workspace” directory under the eSDK.
475 The <filename>devtool upgrade</filename> command
476 updates an existing recipe so that you can build it
477 for an updated set of source files.</para>
478
479 <para>You can read about the
480 <filename>devtool</filename> workflow in the Yocto
481 Project Application Development and Extensible
482 Software Development Kit (eSDK) Manual in the
483 "<ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'>Using <filename>devtool</filename> in Your SDK Workflow'</ulink>"
484 section.
485 </para></listitem>
486 <listitem><para>
487 <emphasis>Extensible Software Development Kit (eSDK):</emphasis>
488 The eSDK provides a cross-development toolchain and
489 libraries tailored to the contents of a specific image.
490 The eSDK makes it easy to add new applications and
491 libraries to an image, modify the source for an
492 existing component, test changes on the target
493 hardware, and integrate into the rest of the
494 OpenEmbedded build system.
495 The eSDK gives you a toolchain experience supplemented
496 with the powerful set of <filename>devtool</filename>
497 commands tailored for the Yocto Project environment.
498 </para>
499
500 <para>For information on the eSDK, see the
501 <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
502 Manual.
503 </para></listitem>
504 <listitem><para>
505 <emphasis><trademark class='trade'>Eclipse</trademark> IDE Plug-in:</emphasis>
506 This plug-in enables you to use the popular Eclipse
507 Integrated Development Environment (IDE), which allows
508 for development using the Yocto Project all within the
509 Eclipse IDE.
510 You can work within Eclipse to cross-compile, deploy,
511 and execute your output into a QEMU emulation session
512 as well as onto actual target hardware.</para>
513
514 <para>The environment also supports performance
515 enhancing tools that allow you to perform remote
516 profiling, tracing, collection of power data,
517 collection of latency data, and collection of
518 performance data.</para>
519
520 <para>Once you enable the plug-in, standard Eclipse
521 functions automatically use the cross-toolchain
522 and target system libraries.
523 You can build applications using any of these
524 libraries.</para>
525
526 <para>For more information on the Eclipse plug-in,
527 see the
528 "<ulink url='&YOCTO_DOCS_SDK_URL;#adt-eclipse'>Working Within Eclipse</ulink>"
529 section in the Yocto Project Application Development
530 and the Extensible Software Development Kit (eSDK)
531 manual.
532 </para></listitem>
533 <listitem><para>
534 <emphasis>Toaster:</emphasis>
535 Toaster is a web interface to the Yocto Project
536 OpenEmbedded build system.
537 Toaster allows you to configure, run, and view
538 information about builds.
539 For information on Toaster, see the
540 <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>.
541 </para></listitem>
542 </itemizedlist>
543 </para>
544 </section>
545
546 <section id='gs-production-tools'>
547 <title>Production Tools</title>
548
549 <para>
550 The following list consists of tools that help production
551 related activities using the Yocto Project:
552 <itemizedlist>
553 <listitem><para>
554 <emphasis>Auto Upgrade Helper:</emphasis>
555 This utility when used in conjunction with the
556 <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>
557 (BitBake and OE-Core) automatically generates upgrades
558 for recipes that are based on new versions of the
559 recipes published upstream.
560 </para></listitem>
561 <listitem><para>
562 <emphasis>Recipe Reporting System:</emphasis>
563 The Recipe Reporting System tracks recipe versions
564 available for Yocto Project.
565 The main purpose of the system is to help you
566 manage the recipes you maintain and to offer a dynamic
567 overview of the project.
568 The Recipe Reporting System is built on top of the
569 <ulink url="http://layers.openembedded.org/layerindex/layers/">OpenEmbedded Layer Index</ulink>,
570 which is a website that indexes OpenEmbedded-Core
571 layers.
572 </para></listitem>
573 <listitem><para>
574 <emphasis>Patchwork:</emphasis>
575 <ulink url='http://jk.ozlabs.org/projects/patchwork/'>Patchwork</ulink>
576 is a fork of a project originally started by
577 <ulink url='http://ozlabs.org/'>OzLabs</ulink>.
578 The project is a web-based tracking system designed
579 to streamline the process of bringing contributions
580 into a project.
581 The Yocto Project uses Patchwork as an organizational
582 tool to handle patches, which number in the thousands
583 for every release.
584 </para></listitem>
585 <listitem><para>
586 <emphasis>AutoBuilder:</emphasis>
587 AutoBuilder is a project that automates build tests
588 and quality assurance (QA).
589 By using the public AutoBuilder, anyone can determine
590 the status of the current "master" branch of Poky.
591 <note>
592 AutoBuilder is based on
593 <ulink url='https://buildbot.net/'>buildbot</ulink>.
594 </note></para>
595
596 <para>A goal of the Yocto Project is to lead the
597 open source industry with a project that automates
598 testing and QA procedures.
599 In doing so, the project encourages a development
600 community that publishes QA and test plans, publicly
601 demonstrates QA and test plans, and encourages
602 development of tools that automate and test and QA
603 procedures for the benefit of the development
604 community.</para>
605
606 <para>You can learn more about the AutoBuilder used
607 by the Yocto Project
608 <ulink url='&YOCTO_AB_URL;'>here</ulink>.
609 </para></listitem>
610 <listitem><para>
611 <emphasis>Cross-Prelink:</emphasis>
612 Prelinking is the process of pre-computing the load
613 addresses and link tables generated by the dynamic
614 linker as compared to doing this at runtime.
615 Doing this ahead of time results in performance
616 improvements when the application is launched and
617 reduced memory usage for libraries shared by many
618 applications.</para>
619
620 <para>Historically, cross-prelink is a variant of
621 prelink, which was conceived by
622 <ulink url='http://people.redhat.com/jakub/prelink.pdf'>Jakub Jel&iacute;nek</ulink>
623 a number of years ago.
624 Both prelink and cross-prelink are maintained in the
625 same repository albeit on separate branches.
626 By providing an emulated runtime dynamic linker
627 (i.e. <filename>glibc</filename>-derived
628 <filename>ld.so</filename> emulation), the
629 cross-prelink project extends the prelink software’s
630 ability to prelink a sysroot environment.
631 Additionally, the cross-prelink software enables the
632 ability to work in sysroot style environments.</para>
633
634 <para>The dynamic linker determines standard load
635 address calculations based on a variety of factors
636 such as mapping addresses, library usage, and library
637 function conflicts.
638 The prelink tool uses this information, from the
639 dynamic linker, to determine unique load addresses
640 for executable and linkable format (ELF) binaries
641 that are shared libraries and dynamically linked.
642 The prelink tool modifies these ELF binaries with the
643 pre-computed information.
644 The result is faster loading and often lower memory
645 consumption because more of the library code can
646 be re-used from shared Copy-On-Write (COW) pages.
647 </para>
648
649 <para>The original upstream prelink project only
650 supports running prelink on the end target device
651 due to the reliance on the target device’s dynamic
652 linker.
653 This restriction causes issues when developing a
654 cross-compiled system.
655 The cross-prelink adds a synthesized dynamic loader
656 that runs on the host, thus permitting cross-prelinking
657 without ever having to run on a read-write target
658 filesystem.
659 </para></listitem>
660 <listitem><para>
661 <emphasis>Pseudo:</emphasis>
662 Pseudo is the Yocto Project implementation of
663 <ulink url='http://man.he.net/man1/fakeroot'>fakeroot</ulink>,
664 which is used to run commands in an environment
665 that seemingly has root privileges.</para>
666
667 <para>During a build, it can be necessary to perform
668 operations that require system administrator
669 privileges.
670 For example, file ownership or permissions might need
671 definition.
672 Pseudo is a tool that you can either use directly or
673 through the environment variable
674 <filename>LD_PRELOAD</filename>.
675 Either method allows these operations to succeed as
676 if system administrator privileges exist even
677 when they do not.</para>
678
679 <para>You can read more about Pseudo in the
680 "<link linkend='fakeroot-and-pseudo'>Fakeroot and Pseudo</link>"
681 section.
682 </para></listitem>
683 </itemizedlist>
684 </para>
685 </section>
686
687 <section id='gs-openembedded-build-system'>
688 <title>Open-Embedded Build System Components</title>
689
690 <para>
691 The following list consists of components associated with the
692 <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>:
693 <itemizedlist>
694 <listitem><para>
695 <emphasis>BitBake:</emphasis>
696 BitBake is a core component of the Yocto Project and is
697 used by the OpenEmbedded build system to build images.
698 While BitBake is key to the build system, BitBake
699 is maintained separately from the Yocto Project.</para>
700
701 <para>BitBake is a generic task execution engine that
702 allows shell and Python tasks to be run efficiently
703 and in parallel while working within complex inter-task
704 dependency constraints.
705 In short, BitBake is a build engine that works
706 through recipes written in a specific format in order
707 to perform sets of tasks.</para>
708
709 <para>You can learn more about BitBake in the
710 <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
711 </para></listitem>
712 <listitem><para>
713 <emphasis>OpenEmbedded-Core:</emphasis>
714 OpenEmbedded-Core (OE-Core) is a common layer of
715 metadata (i.e. recipes, classes, and associated files)
716 used by OpenEmbedded-derived systems, which includes
717 the Yocto Project.
718 The Yocto Project and the OpenEmbedded Project both
719 maintain the OpenEmbedded-Core.
720 You can find the OE-Core metadata in the Yocto Project
721 <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta'>Source Repositories</ulink>.
722 </para>
723
724 <para>Historically, the Yocto Project integrated the
725 OE-Core metadata throughout the Yocto Project
726 source repository reference system (Poky).
727 After Yocto Project Version 1.0, the Yocto Project
728 and OpenEmbedded agreed to work together and share a
729 common core set of metadata (OE-Core), which contained
730 much of the functionality previously found in Poky.
731 This collaboration achieved a long-standing
732 OpenEmbedded objective for having a more tightly
733 controlled and quality-assured core.
734 The results also fit well with the Yocto Project
735 objective of achieving a smaller number of fully
736 featured tools as compared to many different ones.
737 </para>
738
739 <para>Sharing a core set of metadata results in Poky
740 as an integration layer on top of OE-Core.
741 You can see that in this
742 <link linkend='yp-key-dev-elements'>figure</link>.
743 The Yocto Project combines various components such as
744 BitBake, OE-Core, script “glue”, and documentation
745 for its build system.
746 </para></listitem>
747 </itemizedlist>
748 </para>
749 </section>
750
751 <section id='gs-reference-distribution-poky'>
752 <title>Reference Distribution (Poky)</title>
753
754 <para>
755 Poky is the Yocto Project reference distribution.
756 It contains the
757 <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink>
758 (BitBake and OE-Core) as well as a set of metadata to get you
759 started building your own distribution.
760 See the
761 <link linkend='what-is-the-yocto-project'>figure</link> in
762 "What is the Yocto Project?" section for an illustration
763 that shows Poky and its relationship with other parts of the
764 Yocto Project.</para>
765
766 <para>To use the Yocto Project tools and components, you
767 can download (<filename>clone</filename>) Poky and use it
768 to bootstrap your own distribution.
769 <note>
770 Poky does not contain binary files.
771 It is a working example of how to build your own custom
772 Linux distribution from source.
773 </note>
774 You can read more about Poky in the
775 "<link linkend='reference-embedded-distribution'>Reference Embedded Distribution (Poky)</link>"
776 section.
777 </para>
778 </section>
779
780 <section id='gs-packages-for-finished-targets'>
781 <title>Packages for Finished Targets</title>
782
783 <para>
784 The following lists components associated with packages
785 for finished targets:
786 <itemizedlist>
787 <listitem><para>
788 <emphasis>Matchbox:</emphasis>
789 Matchbox is an Open Source, base environment for the
790 X Window System running on non-desktop, embedded
791 platforms such as handhelds, set-top boxes, kiosks,
792 and anything else for which screen space, input
793 mechanisms, or system resources are limited.</para>
794
795 <para>Matchbox consists of a number of interchangeable
796 and optional applications that you can tailor to a
797 specific, non-desktop platform to enhance usability
798 in constrained environments.</para>
799
800 <para>You can find the Matchbox source in the Yocto
801 Project
802 <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>.
803 </para></listitem>
804 <listitem><para>
805 <emphasis>Opkg</emphasis>
806 Open PacKaGe management (opkg) is a lightweight
807 package management system based on the itsy package
808 (ipkg) management system.
809 Opkg is written in C and resembles Advanced Package
810 Tool (APT) and Debian Package (dpkg) in operation.
811 </para>
812
813 <para>Opkg is intended for use on embedded Linux
814 devices and is used in this capacity in the
815 <ulink url='http://www.openembedded.org/wiki/Main_Page'>OpenEmbedded</ulink>
816 and
817 <ulink url='https://openwrt.org/'>OpenWrt</ulink>
818 projects, as well as the Yocto Project.
819 <note>
820 As best it can, opkg maintains backwards
821 compatibility with ipkg and conforms to a subset
822 of Debian’s policy manual regarding control files.
823 </note>
824 </para></listitem>
825 </itemizedlist>
826 </para>
827 </section>
828
829 <section id='gs-archived-components'>
830 <title>Archived Components</title>
831
832 <para>
833 The Build Appliance is a virtual machine image that enables
834 you to build and boot a custom embedded Linux image with
835 the Yocto Project using a non-Linux development system.
836 </para>
837
838 <para>
839 Historically, the Build Appliance was the second of three
840 methods by which you could use the Yocto Project on a system
841 that was not native to Linux.
842 <orderedlist>
843 <listitem><para>
844 <emphasis>Hob:</emphasis>
845 Hob, which is now deprecated and is no longer available
846 since the 2.1 release of the Yocto Project provided
847 a rudimentary, GUI-based interface to the Yocto
848 Project.
849 Toaster has fully replaced Hob.
850 </para></listitem>
851 <listitem><para>
852 <emphasis>Build Appliance:</emphasis>
853 Post Hob, the Build Appliance became available.
854 It was never recommended that you use the Build
855 Appliance as a day-to-day production development
856 environment with the Yocto Project.
857 Build Appliance was useful as a way to try out
858 development in the Yocto Project environment.
859 </para></listitem>
860 <listitem><para>
861 <emphasis>CROPS:</emphasis>
862 The final and best solution available now for
863 developing using the Yocto Project on a system
864 not native to Linux is with
865 <link linkend='gs-crops-overview'>CROPS</link>.
866 </para></listitem>
867 </orderedlist>
868 </para>
869 </section>
870 </section>
871
872 <section id='gs-development-methods'>
873 <title>Development Methods</title>
874
875 <para>
876 The Yocto Project development environment usually involves a
877 <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>Build Host</ulink>
878 and target hardware.
879 You use the Build Host to build images and develop applications,
880 while you use the target hardware to test deployed software.
881 </para>
882
883 <para>
884 This section provides an introduction to the choices or
885 development methods you have when setting up your Build Host.
886 Depending on the your particular workflow preference and the
887 type of operating system your Build Host runs, several choices
888 exist that allow you to use the Yocto Project.
889 <note>
890 For additional detail about the Yocto Project development
891 environment, see the
892 "<link linkend='overview-development-environment'>The Yocto Project Development Environment</link>"
893 chapter.
894 </note>
895 <itemizedlist>
896 <listitem><para>
897 <emphasis>Native Linux Host:</emphasis>
898 By far the best option for a Build Host.
899 A system running Linux as its native operating system
900 allows you to develop software by directly using the
901 <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>
902 tool.
903 You can accomplish all aspects of development from a
904 familiar shell of a supported Linux distribution.</para>
905
906 <para>For information on how to set up a Build Host on
907 a system running Linux as its native operating system,
908 see the
909 "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-a-native-linux-host'>Setting Up a Native Linux Host</ulink>"
910 section in the Yocto Project Development Tasks Manual.
911 </para></listitem>
912 <listitem><para>
913 <emphasis>CROss PlatformS (CROPS):</emphasis>
914 Typically, you use
915 <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink>,
916 which leverages
917 <ulink url='https://www.docker.com/'>Docker Containers</ulink>,
918 to set up a Build Host that is not running Linux (e.g.
919 <trademark class='registered'>Microsoft</trademark>
920 <trademark class='trademark'>Windows</trademark>
921 or
922 <trademark class='registered'>macOS</trademark>).
923 <note>
924 You can, however, use CROPS on a Linux-based system.
925 </note>
926 CROPS is an open source, cross-platform development
927 framework that provides an easily managed, extensible
928 environment for building binaries targeted for a variety
929 of architectures on Windows, macOS, or Linux hosts.
930 Once the Build Host is set up using CROPS, you can prepare
931 a shell environment to mimic that of a shell being used
932 on a system natively running Linux.</para>
933
934 <para>For information on how to set up a Build Host with
935 CROPS, see the
936 "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-crops'>Setting Up to Use CROss PlatformS (CROPS)</ulink>"
937 section in the Yocto Project Development Tasks Manual.
938 </para></listitem>
939 <listitem><para>
940 <emphasis>Toaster:</emphasis>
941 Regardless of what your Build Host is running, you can
942 use Toaster to develop software using the Yocto Project.
943 Toaster is a web interface to the Yocto Project's
944 <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink>.
945 The interface enables you to configure and run your
946 builds.
947 Information about builds is collected and stored in a
948 database.
949 You can use Toaster to configure and start builds on
950 multiple remote build servers.</para>
951
952 <para>For information about and how to use Toaster,
953 see the
954 <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>.
955 </para></listitem>
956 <listitem><para>
957 <emphasis><trademark class='trade'>Eclipse</trademark> IDE:</emphasis>
958 If your Build Host supports and runs the popular
959 Eclipse IDE, you can install the Yocto Project Eclipse
960 plug-in and use the Yocto Project to develop software.
961 The plug-in integrates the Yocto Project functionality
962 into Eclipse development practices.</para>
963
964 <para>For information about how to install and use the
965 Yocto Project Eclipse plug-in, see the
966 "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-eclipse-project'>Developing Applications Using Eclipse</ulink>"
967 chapter in the Yocto Project Application Development and
968 the Extensible Software Development Kit (eSDK) Manual.
969 </para></listitem>
970 </itemizedlist>
971 </para>
972 </section>
973
974 <section id='reference-embedded-distribution'>
975 <title>Reference Embedded Distribution (Poky)</title>
976
977 <para>
978 "Poky", which is pronounced <emphasis>Pock</emphasis>-ee, is the
979 name of the Yocto Project's reference distribution or Reference OS
980 Kit.
981 Poky contains the
982 <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded Build System</ulink>
983 (<ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink> and
984 <ulink url='&YOCTO_DOCS_REF_URL;#oe-core'>OpenEmbedded-Core</ulink>)
985 as well as a set of
986 <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>metadata</ulink> to get
987 you started building your own distro.
988 In other words, Poky is a base specification of the functionality
989 needed for a typical embedded system as well as the components
990 from the Yocto Project that allow you to build a distribution into
991 a usable binary image.
992 </para>
993
994 <para>
995 Poky is a combined repository of BitBake, OpenEmbedded-Core
996 (which is found in <filename>meta</filename>),
997 <filename>meta-poky</filename>,
998 <filename>meta-yocto-bsp</filename>, and documentation provided
999 all together and known to work well together.
1000 You can view these items that make up the Poky repository in the
1001 <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/'>Source Repositories</ulink>.
1002 <note>
1003 If you are interested in all the contents of the
1004 <filename>poky</filename> Git repository, see the
1005 "<ulink url='&YOCTO_DOCS_REF_URL;#structure-core'>Top-Level Core Components</ulink>"
1006 section in the Yocto Project Reference Manual.
1007 </note>
1008 </para>
1009
1010 <para id='gs-poky-reference-distribution'>
1011 The following figure illustrates what generally comprises Poky:
1012 <imagedata fileref="figures/poky-reference-distribution.png" format="PNG" align='center' width="8in"/>
1013 <itemizedlist>
1014 <listitem><para>
1015 BitBake is a task executor and scheduler that is the heart of
1016 the OpenEmbedded build system.
1017 </para></listitem>
1018 <listitem><para>
1019 <filename>meta-poky</filename>, which is Poky-specific
1020 metadata.
1021 </para></listitem>
1022 <listitem><para>
1023 <filename>meta-yocto-bsp</filename>, which are Yocto
1024 Project-specific Board Support Packages (BSPs).
1025 </para></listitem>
1026 <listitem><para>
1027 OpenEmbedded-Core (OE-Core) metadata, which includes
1028 shared configurations, global variable definitions,
1029 shared classes, packaging, and recipes.
1030 Classes define the encapsulation and inheritance of build
1031 logic.
1032 Recipes are the logical units of software and images
1033 to be built.
1034 </para></listitem>
1035 <listitem><para>
1036 Documentation, which contains the Yocto Project source
1037 files used to make the set of user manuals.
1038 </para></listitem>
1039 </itemizedlist>
1040 <note>
1041 While Poky is a "complete" distribution specification and is
1042 tested and put through QA, you cannot use it as a product
1043 "out of the box" in its current form.
1044 </note>
1045 </para>
1046
1047 <para>
1048 To use the Yocto Project tools, you can use Git to clone (download)
1049 the Poky repository then use your local copy of the reference
1050 distribution to bootstrap your own distribution.
1051 <note>
1052 Poky does not contain binary files.
1053 It is a working example of how to build your own custom Linux distribution
1054 from source.
1055 </note>
1056 </para>
1057
1058 <para>
1059 Poky has a regular, well established, six-month release cycle
1060 under its own version.
1061 Major releases occur at the same time major releases (point
1062 releases) occur for the Yocto Project, which are typically in the
1063 Spring and Fall.
1064 For more information on the Yocto Project release schedule and
1065 cadence, see the
1066 "<ulink url='&YOCTO_DOCS_REF_URL;#ref-release-process'>Yocto Project Releases and the Stable Release Process</ulink>"
1067 chapter in the Yocto Project Reference Manual.
1068 </para>
1069
1070 <para>
1071 Much has been said about Poky being a "default configuration."
1072 A default configuration provides a starting image footprint.
1073 You can use Poky out of the box to create an image ranging from a
1074 shell-accessible minimal image all the way up to a Linux
1075 Standard Base-compliant image that uses a GNOME Mobile and
1076 Embedded (GMAE) based reference user interface called Sato.
1077 </para>
1078
1079 <para>
1080 One of the most powerful properties of Poky is that every aspect
1081 of a build is controlled by the metadata.
1082 You can use metadata to augment these base image types by
1083 adding metadata
1084 <link linkend='the-yocto-project-layer-model'>layers</link>
1085 that extend functionality.
1086 These layers can provide, for example, an additional software
1087 stack for an image type, add a board support package (BSP) for
1088 additional hardware, or even create a new image type.
1089 </para>
1090
1091 <para>
1092 Metadata is loosely grouped into configuration files or package
1093 recipes.
1094 A recipe is a collection of non-executable metadata used by
1095 BitBake to set variables or define additional build-time tasks.
1096 A recipe contains fields such as the recipe description, the recipe
1097 version, the license of the package and the upstream source
1098 repository.
1099 A recipe might also indicate that the build process uses autotools,
1100 make, distutils or any other build process, in which case the basic
1101 functionality can be defined by the classes it inherits from
1102 the OE-Core layer's class definitions in
1103 <filename>./meta/classes</filename>.
1104 Within a recipe you can also define additional tasks as well as
1105 task prerequisites.
1106 Recipe syntax through BitBake also supports both
1107 <filename>_prepend</filename> and <filename>_append</filename>
1108 operators as a method of extending task functionality.
1109 These operators inject code into the beginning or end of a task.
1110 For information on these BitBake operators, see the
1111 "<ulink url='&YOCTO_DOCS_BB_URL;#appending-and-prepending-override-style-syntax'>Appending and Prepending (Override Style Syntax)</ulink>"
1112 section in the BitBake User's Manual.
1113 </para>
1114 </section>
1115
1116 <section id='openembedded-build-system-workflow'>
1117 <title>The OpenEmbedded Build System Workflow</title>
1118
1119 <para>
1120 The
1121 <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>
1122 uses a "workflow" to accomplish image and SDK generation.
1123 The following figure overviews that workflow:
1124 <imagedata fileref="figures/YP-flow-diagram.png"
1125 format="PNG" align='center' width="8in"/>
1126 Following is a brief summary of the "workflow":
1127 <orderedlist>
1128 <listitem><para>
1129 Developers specify architecture, policies, patches and
1130 configuration details.
1131 </para></listitem>
1132 <listitem><para>
1133 The build system fetches and downloads the source code
1134 from the specified location.
1135 The build system supports standard methods such as tarballs
1136 or source code repositories systems such as Git.
1137 </para></listitem>
1138 <listitem><para>
1139 Once source code is downloaded, the build system extracts
1140 the sources into a local work area where patches are
1141 applied and common steps for configuring and compiling
1142 the software are run.
1143 </para></listitem>
1144 <listitem><para>
1145 The build system then installs the software into a
1146 temporary staging area where the binary package format you
1147 select (DEB, RPM, or IPK) is used to roll up the software.
1148 </para></listitem>
1149 <listitem><para>
1150 Different QA and sanity checks run throughout entire
1151 build process.
1152 </para></listitem>
1153 <listitem><para>
1154 After the binaries are created, the build system
1155 generates a binary package feed that is used to create
1156 the final root file image.
1157 </para></listitem>
1158 <listitem><para>
1159 The build system generates the file system image and a
1160 customized Extensible SDK (eSDSK) for application
1161 development in parallel.
1162 </para></listitem>
1163 </orderedlist>
1164 </para>
1165
1166 <para>
1167 For a very detailed look at this workflow, see the
1168 "<link linkend='openembedded-build-system-build-concepts'>OpenEmbedded Build System Concepts</link>"
1169 section.
1170 </para>
1171 </section>
1172
1173
1174 <section id='some-basic-terms'>
1175 <title>Some Basic Terms</title>
1176
1177 <para>
1178 It helps to understand some basic fundamental terms when
1179 learning the Yocto Project.
1180 Although a list of terms exists in the
1181 "<ulink url='&YOCTO_DOCS_REF_URL;#ref-terms'>Yocto Project Terms</ulink>"
1182 section of the Yocto Project Reference Manual, this section
1183 provides the definitions of some terms helpful for getting started:
1184 <itemizedlist>
1185 <listitem><para>
1186 <emphasis>Configuration Files:</emphasis>
1187 Files that hold global definitions of variables,
1188 user-defined variables, and hardware configuration
1189 information.
1190 These files tell the
1191 <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>Open-Embedded build system</ulink>
1192 what to build and what to put into the image to support a
1193 particular platform.
1194 </para></listitem>
1195 <listitem><para>
1196 <emphasis>Extensible Software Development Kit (eSDK):</emphasis>
1197 A custom SDK for application developers.
1198 This eSDK allows developers to incorporate their library
1199 and programming changes back into the image to make
1200 their code available to other application developers.
1201 For information on the eSDK, see the
1202 <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
1203 manual.
1204 </para></listitem>
1205 <listitem><para>
1206 <emphasis>Layer:</emphasis>
1207 A collection of related recipes.
1208 Layers allow you to consolidate related metadata to
1209 customize your build.
1210 Layers also isolate information used when building
1211 for multiple architectures.
1212 Layers are hierarchical in their ability to override
1213 previous specifications.
1214 You can include any number of available layers from the
1215 Yocto Project and customize the build by adding your
1216 layers after them.
1217 You can search the Layer Index for layers used within
1218 Yocto Project.</para>
1219
1220 <para>For more detailed information on layers, see the
1221 "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
1222 section in the Yocto Project Development Tasks Manual.
1223 For a discussion specifically on BSP Layers, see the
1224 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
1225 section in the Yocto Project Board Support Packages (BSP)
1226 Developer's Guide.
1227 </para></listitem>
1228 <listitem><para>
1229 <emphasis>Metadata:</emphasis>
1230 A key element of the Yocto Project is the Metadata that
1231 is used to construct a Linux distribution and is contained
1232 in the files that the OpenEmbedded build system parses
1233 when building an image.
1234 In general, Metadata includes recipes, configuration
1235 files, and other information that refers to the build
1236 instructions themselves, as well as the data used to
1237 control what things get built and the effects of the
1238 build.
1239 Metadata also includes commands and data used to
1240 indicate what versions of software are used, from
1241 where they are obtained, and changes or additions to the
1242 software itself (patches or auxiliary files) that
1243 are used to fix bugs or customize the software for use
1244 in a particular situation.
1245 OpenEmbedded-Core is an important set of validated
1246 metadata.
1247 </para></listitem>
1248 <listitem><para id='gs-term-openembedded-build-system'>
1249 <emphasis>OpenEmbedded Build System:</emphasis>
1250 The terms "BitBake" and "build system" are sometimes
1251 used for the OpenEmbedded Build System.</para>
1252
1253 <para>BitBake is a task scheduler and execution engine
1254 that parses instructions (i.e. recipes) and configuration
1255 data.
1256 After a parsing phase, BitBake creates a dependency tree
1257 to order the compilation, schedules the compilation of
1258 the included code, and finally executes the building
1259 of the specified custom Linux image (distribution).
1260 BitBake is similar to the <filename>make</filename>
1261 tool.</para>
1262
1263 <para>During a build process, the build system tracks
1264 dependencies and performs a native or cross-compilation
1265 of the package.
1266 As a first step in a cross-build setup, the framework
1267 attempts to create a cross-compiler toolchain
1268 (i.e. Extensible SDK) suited for the target platform.
1269 </para></listitem>
1270 <listitem><para>
1271 <emphasis>OpenEmbedded-Core (OE-Core):</emphasis>
1272 OE-Core is metadata comprised of foundation recipes,
1273 classes, and associated files that are meant to be
1274 common among many different OpenEmbedded-derived systems,
1275 including the Yocto Project.
1276 OE-Core is a curated subset of an original repository
1277 developed by the OpenEmbedded community that has been
1278 pared down into a smaller, core set of continuously
1279 validated recipes.
1280 The result is a tightly controlled and quality-assured
1281 core set of recipes.</para>
1282
1283 <para>You can see the Metadata in the
1284 <filename>meta</filename> directory of the Yocto Project
1285 <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Source Repositories</ulink>.
1286 </para></listitem>
1287 <listitem><para>
1288 <emphasis>Packages:</emphasis>
1289 In the context of the Yocto Project, this term refers to a
1290 recipe's packaged output produced by BitBake (i.e. a
1291 "baked recipe").
1292 A package is generally the compiled binaries produced from the
1293 recipe's sources.
1294 You "bake" something by running it through BitBake.</para>
1295
1296 <para>It is worth noting that the term "package" can,
1297 in general, have subtle meanings.
1298 For example, the packages referred to in the
1299 "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>"
1300 section in the Yocto Project Reference Manual are compiled
1301 binaries that, when installed, add functionality to your
1302 Linux distribution.</para>
1303
1304 <para>Another point worth noting is that historically within
1305 the Yocto Project, recipes were referred to as packages - thus,
1306 the existence of several BitBake variables that are seemingly
1307 mis-named,
1308 (e.g. <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>,
1309 <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>,
1310 and
1311 <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>).
1312 </para></listitem>
1313 <listitem><para>
1314 <emphasis>Poky:</emphasis>
1315 Poky is a reference embedded distribution and a reference
1316 test configuration.
1317 Poky provides the following:
1318 <itemizedlist>
1319 <listitem><para>
1320 A base-level functional distro used to illustrate
1321 how to customize a distribution.
1322 </para></listitem>
1323 <listitem><para>
1324 A means by which to test the Yocto Project
1325 components (i.e. Poky is used to validate
1326 the Yocto Project).
1327 </para></listitem>
1328 <listitem><para>
1329 A vehicle through which you can download
1330 the Yocto Project.
1331 </para></listitem>
1332 </itemizedlist>
1333 Poky is not a product level distro.
1334 Rather, it is a good starting point for customization.
1335 <note>
1336 Poky is an integration layer on top of OE-Core.
1337 </note>
1338 </para></listitem>
1339 <listitem><para>
1340 <emphasis>Recipe:</emphasis>
1341 The most common form of metadata.
1342 A recipe contains a list of settings and tasks
1343 (i.e. instructions) for building packages that are then
1344 used to build the binary image.
1345 A recipe describes where you get source code and which
1346 patches to apply.
1347 Recipes describe dependencies for libraries or for other
1348 recipes as well as configuration and compilation options.
1349 Related recipes are consolidated into a layer.
1350 </para></listitem>
1351 </itemizedlist>
1352 </para>
1353 </section>
1354</chapter>
1355<!--
1356vim: expandtab tw=80 ts=4
1357-->