summaryrefslogtreecommitdiffstats
path: root/documentation/ref-manual/closer-look.xml
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/ref-manual/closer-look.xml')
-rw-r--r--documentation/ref-manual/closer-look.xml1304
1 files changed, 1304 insertions, 0 deletions
diff --git a/documentation/ref-manual/closer-look.xml b/documentation/ref-manual/closer-look.xml
new file mode 100644
index 0000000000..c0c0d619a4
--- /dev/null
+++ b/documentation/ref-manual/closer-look.xml
@@ -0,0 +1,1304 @@
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
5<chapter id='closer-look'>
6<title>A Closer Look at the Yocto Project Development Environment</title>
7
8 <para>
9 This chapter takes a more detailed look at the Yocto Project
10 development environment.
11 The following diagram represents the development environment at a
12 high level.
13 The remainder of this chapter expands on the fundamental input, output,
14 process, and
15 <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>) blocks
16 in the Yocto Project development environment.
17 </para>
18
19 <para id='general-yocto-environment-figure'>
20 <imagedata fileref="figures/yocto-environment-ref.png" align="center" width="8in" depth="4.25in" />
21 </para>
22
23 <para>
24 The generalized Yocto Project Development Environment consists of
25 several functional areas:
26 <itemizedlist>
27 <listitem><para><emphasis>User Configuration:</emphasis>
28 Metadata you can use to control the build process.
29 </para></listitem>
30 <listitem><para><emphasis>Metadata Layers:</emphasis>
31 Various layers that provide software, machine, and
32 distro Metadata.</para></listitem>
33 <listitem><para><emphasis>Source Files:</emphasis>
34 Upstream releases, local projects, and SCMs.</para></listitem>
35 <listitem><para><emphasis>Build System:</emphasis>
36 Processes under the control of
37 <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>.
38 This block expands on how BitBake fetches source, applies
39 patches, completes compilation, analyzes output for package
40 generation, creates and tests packages, generates images, and
41 generates cross-development tools.</para></listitem>
42 <listitem><para><emphasis>Package Feeds:</emphasis>
43 Directories containing output packages (RPM, DEB or IPK),
44 which are subsequently used in the construction of an image or
45 SDK, produced by the build system.
46 These feeds can also be copied and shared using a web server or
47 other means to facilitate extending or updating existing
48 images on devices at runtime if runtime package management is
49 enabled.</para></listitem>
50 <listitem><para><emphasis>Images:</emphasis>
51 Images produced by the development process.
52 </para></listitem>
53 <listitem><para><emphasis>Application Development SDK:</emphasis>
54 Cross-development tools that are produced along with an image
55 or separately with BitBake.</para></listitem>
56 </itemizedlist>
57 </para>
58
59 <section id="user-configuration">
60 <title>User Configuration</title>
61
62 <para>
63 User configuration helps define the build.
64 Through user configuration, you can tell BitBake the
65 target architecture for which you are building the image,
66 where to store downloaded source, and other build properties.
67 </para>
68
69 <para>
70 The following figure shows an expanded representation of the
71 "User Configuration" box of the
72 <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>:
73 </para>
74
75 <para>
76 <imagedata fileref="figures/user-configuration.png" align="center" width="5.5in" depth="3.5in" />
77 </para>
78
79 <para>
80 BitBake needs some basic configuration files in order to complete
81 a build.
82 These files are <filename>*.conf</filename> files.
83 The minimally necessary ones reside as example files in the
84 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
85 For simplicity, this section refers to the Source Directory as
86 the "Poky Directory."
87 </para>
88
89 <para>
90 When you clone the <filename>poky</filename> Git repository or you
91 download and unpack a Yocto Project release, you can set up the
92 Source Directory to be named anything you want.
93 For this discussion, the cloned repository uses the default
94 name <filename>poky</filename>.
95 <note>
96 The Poky repository is primarily an aggregation of existing
97 repositories.
98 It is not a canonical upstream source.
99 </note>
100 </para>
101
102 <para>
103 The <filename>meta-yocto</filename> layer inside Poky contains
104 a <filename>conf</filename> directory that has example
105 configuration files.
106 These example files are used as a basis for creating actual
107 configuration files when you source the build environment
108 script
109 (i.e.
110 <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
111 or
112 <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
113 </para>
114
115 <para>
116 Sourcing the build environment script creates a
117 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
118 if one does not already exist.
119 BitBake uses the Build Directory for all its work during builds.
120 The Build Directory has a <filename>conf</filename> directory that
121 contains default versions of your <filename>local.conf</filename>
122 and <filename>bblayers.conf</filename> configuration files.
123 These default configuration files are created only if versions
124 do not already exist in the Build Directory at the time you
125 source the build environment setup script.
126 </para>
127
128 <para>
129 Because the Poky repository is fundamentally an aggregation of
130 existing repositories, some users might be familiar with running
131 the <filename>&OE_INIT_FILE;</filename> or
132 <filename>oe-init-build-env-memres</filename> script in the context
133 of separate OpenEmbedded-Core and BitBake repositories rather than a
134 single Poky repository.
135 This discussion assumes the script is executed from within a cloned
136 or unpacked version of Poky.
137 </para>
138
139 <para>
140 Depending on where the script is sourced, different sub-scripts
141 are called to set up the Build Directory (Yocto or OpenEmbedded).
142 Specifically, the script
143 <filename>scripts/oe-setup-builddir</filename> inside the
144 poky directory sets up the Build Directory and seeds the directory
145 (if necessary) with configuration files appropriate for the
146 Yocto Project development environment.
147 <note>
148 The <filename>scripts/oe-setup-builddir</filename> script
149 uses the <filename>$TEMPLATECONF</filename> variable to
150 determine which sample configuration files to locate.
151 </note>
152 </para>
153
154 <para>
155 The <filename>local.conf</filename> file provides many
156 basic variables that define a build environment.
157 Here is a list of a few.
158 To see the default configurations in a <filename>local.conf</filename>
159 file created by the build environment script, see the
160 <filename>local.conf.sample</filename> in the
161 <filename>meta-yocto</filename> layer:
162 <itemizedlist>
163 <listitem><para><emphasis>Parallelism Options:</emphasis>
164 Controlled by the
165 <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
166 and
167 <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
168 variables.</para></listitem>
169 <listitem><para><emphasis>Target Machine Selection:</emphasis>
170 Controlled by the
171 <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
172 variable.</para></listitem>
173 <listitem><para><emphasis>Download Directory:</emphasis>
174 Controlled by the
175 <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
176 variable.</para></listitem>
177 <listitem><para><emphasis>Shared State Directory:</emphasis>
178 Controlled by the
179 <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>
180 variable.</para></listitem>
181 <listitem><para><emphasis>Build Output:</emphasis>
182 Controlled by the
183 <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
184 variable.</para></listitem>
185 </itemizedlist>
186 <note>
187 Configurations set in the <filename>conf/local.conf</filename>
188 file can also be set in the
189 <filename>conf/site.conf</filename> and
190 <filename>conf/auto.conf</filename> configuration files.
191 </note>
192 </para>
193
194 <para>
195 The <filename>bblayers.conf</filename> file tells BitBake what
196 layers you want considered during the build.
197 By default, the layers listed in this file include layers
198 minimally needed by the build system.
199 However, you must manually add any custom layers you have created.
200 You can find more information on working with the
201 <filename>bblayers.conf</filename> file in the
202 "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-your-layer'>Enabling Your Layer</ulink>"
203 section in the Yocto Project Development Manual.
204 </para>
205
206 <para>
207 The files <filename>site.conf</filename> and
208 <filename>auto.conf</filename> are not created by the environment
209 initialization script.
210 If you want these configuration files, you must create them
211 yourself:
212 <itemizedlist>
213 <listitem><para><emphasis><filename>site.conf</filename>:</emphasis>
214 You can use the <filename>conf/site.conf</filename>
215 configuration file to configure multiple build directories.
216 For example, suppose you had several build environments and
217 they shared some common features.
218 You can set these default build properties here.
219 A good example is perhaps the level of parallelism you want
220 to use through the
221 <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
222 and
223 <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
224 variables.</para>
225 <para>One useful scenario for using the
226 <filename>conf/site.conf</filename> file is to extend your
227 <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
228 variable to include the path to a
229 <filename>conf/site.conf</filename>.
230 Then, when BitBake looks for Metadata using
231 <filename>BBPATH</filename>, it finds the
232 <filename>conf/site.conf</filename> file and applies your
233 common configurations found in the file.
234 To override configurations in a particular build directory,
235 alter the similar configurations within that build
236 directory's <filename>conf/local.conf</filename> file.
237 </para></listitem>
238 <listitem><para><emphasis><filename>auto.conf</filename>:</emphasis>
239 This file is not hand-created.
240 Rather, the file is usually created and written to by
241 an autobuilder.
242 The settings put into the file are typically the same as
243 you would find in the <filename>conf/local.conf</filename>
244 or the <filename>conf/site.conf</filename> files.
245 </para></listitem>
246 </itemizedlist>
247 </para>
248
249 <para>
250 You can edit all configuration files to further define
251 any particular build environment.
252 This process is represented by the "User Configuration Edits"
253 box in the figure.
254 </para>
255
256 <para>
257 When you launch your build with the
258 <filename>bitbake <replaceable>target</replaceable></filename> command, BitBake
259 sorts out the configurations to ultimately define your build
260 environment.
261 </para>
262 </section>
263
264 <section id="metadata-machine-configuration-and-policy-configuration">
265 <title>Metadata, Machine Configuration, and Policy Configuration</title>
266
267 <para>
268 The previous section described the user configurations that
269 define BitBake's global behavior.
270 This section takes a closer look at the layers the build system
271 uses to further control the build.
272 These layers provide Metadata for the software, machine, and
273 policy.
274 </para>
275
276 <para>
277 In general, three types of layer input exist:
278 <itemizedlist>
279 <listitem><para><emphasis>Policy Configuration:</emphasis>
280 Distribution Layers provide top-level or general
281 policies for the image or SDK being built.
282 For example, this layer would dictate whether BitBake
283 produces RPM or IPK packages.</para></listitem>
284 <listitem><para><emphasis>Machine Configuration:</emphasis>
285 Board Support Package (BSP) layers provide machine
286 configurations.
287 This type of information is specific to a particular
288 target architecture.</para></listitem>
289 <listitem><para><emphasis>Metadata:</emphasis>
290 Software layers contain user-supplied recipe files,
291 patches, and append files.
292 </para></listitem>
293 </itemizedlist>
294 </para>
295
296 <para>
297 The following figure shows an expanded representation of the
298 Metadata, Machine Configuration, and Policy Configuration input
299 (layers) boxes of the
300 <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>:
301 </para>
302
303 <para>
304 <imagedata fileref="figures/layer-input.png" align="center" width="8in" depth="7.5in" />
305 </para>
306
307 <para>
308 In general, all layers have a similar structure.
309 They all contain a licensing file
310 (e.g. <filename>COPYING</filename>) if the layer is to be
311 distributed, a <filename>README</filename> file as good practice
312 and especially if the layer is to be distributed, a
313 configuration directory, and recipe directories.
314 </para>
315
316 <para>
317 The Yocto Project has many layers that can be used.
318 You can see a web-interface listing of them on the
319 <ulink url="http://git.yoctoproject.org/">Source Repositories</ulink>
320 page.
321 The layers are shown at the bottom categorized under
322 "Yocto Metadata Layers."
323 These layers are fundamentally a subset of the
324 <ulink url="http://layers.openembedded.org/layerindex/layers/">OpenEmbedded Metadata Index</ulink>,
325 which lists all layers provided by the OpenEmbedded community.
326 <note>
327 Layers exist in the Yocto Project Source Repositories that
328 cannot be found in the OpenEmbedded Metadata Index.
329 These layers are either deprecated or experimental in nature.
330 </note>
331 </para>
332
333 <para>
334 BitBake uses the <filename>conf/bblayers.conf</filename> file,
335 which is part of the user configuration, to find what layers it
336 should be using as part of the build.
337 </para>
338
339 <para>
340 For more information on layers, see the
341 "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
342 section in the Yocto Project Development Manual.
343 </para>
344
345 <section id="distro-layer">
346 <title>Distro Layer</title>
347
348 <para>
349 The distribution layer provides policy configurations for your
350 distribution.
351 Best practices dictate that you isolate these types of
352 configurations into their own layer.
353 Settings you provide in
354 <filename>conf/distro/<replaceable>distro</replaceable>.conf</filename> override
355 similar
356 settings that BitBake finds in your
357 <filename>conf/local.conf</filename> file in the Build
358 Directory.
359 </para>
360
361 <para>
362 The following list provides some explanation and references
363 for what you typically find in the distribution layer:
364 <itemizedlist>
365 <listitem><para><emphasis>classes:</emphasis>
366 Class files (<filename>.bbclass</filename>) hold
367 common functionality that can be shared among
368 recipes in the distribution.
369 When your recipes inherit a class, they take on the
370 settings and functions for that class.
371 You can read more about class files in the
372 "<link linkend='ref-classes'>Classes</link>" section.
373 </para></listitem>
374 <listitem><para><emphasis>conf:</emphasis>
375 This area holds configuration files for the
376 layer (<filename>conf/layer.conf</filename>),
377 the distribution
378 (<filename>conf/distro/<replaceable>distro</replaceable>.conf</filename>),
379 and any distribution-wide include files.
380 </para></listitem>
381 <listitem><para><emphasis>recipes-*:</emphasis>
382 Recipes and append files that affect common
383 functionality across the distribution.
384 This area could include recipes and append files
385 to add distribution-specific configuration,
386 initialization scripts, custom image recipes,
387 and so forth.</para></listitem>
388 </itemizedlist>
389 </para>
390 </section>
391
392 <section id="bsp-layer">
393 <title>BSP Layer</title>
394
395 <para>
396 The BSP Layer provides machine configurations.
397 Everything in this layer is specific to the machine for which
398 you are building the image or the SDK.
399 A common structure or form is defined for BSP layers.
400 You can learn more about this structure in the
401 <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
402 <note>
403 In order for a BSP layer to be considered compliant with the
404 Yocto Project, it must meet some structural requirements.
405 </note>
406 </para>
407
408 <para>
409 The BSP Layer's configuration directory contains
410 configuration files for the machine
411 (<filename>conf/machine/<replaceable>machine</replaceable>.conf</filename>) and,
412 of course, the layer (<filename>conf/layer.conf</filename>).
413 </para>
414
415 <para>
416 The remainder of the layer is dedicated to specific recipes
417 by function: <filename>recipes-bsp</filename>,
418 <filename>recipes-core</filename>,
419 <filename>recipes-graphics</filename>, and
420 <filename>recipes-kernel</filename>.
421 Metadata can exist for multiple formfactors, graphics
422 support systems, and so forth.
423 <note>
424 While the figure shows several <filename>recipes-*</filename>
425 directories, not all these directories appear in all
426 BSP layers.
427 </note>
428 </para>
429 </section>
430
431 <section id="software-layer">
432 <title>Software Layer</title>
433
434 <para>
435 The software layer provides the Metadata for additional
436 software packages used during the build.
437 This layer does not include Metadata that is specific to the
438 distribution or the machine, which are found in their
439 respective layers.
440 </para>
441
442 <para>
443 This layer contains any new recipes that your project needs
444 in the form of recipe files.
445 </para>
446 </section>
447 </section>
448
449 <section id="sources-dev-environment">
450 <title>Sources</title>
451
452 <para>
453 In order for the OpenEmbedded build system to create an image or
454 any target, it must be able to access source files.
455 The
456 <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
457 represents source files using the "Upstream Project Releases",
458 "Local Projects", and "SCMs (optional)" boxes.
459 The figure represents mirrors, which also play a role in locating
460 source files, with the "Source Mirror(s)" box.
461 </para>
462
463 <para>
464 The method by which source files are ultimately organized is
465 a function of the project.
466 For example, for released software, projects tend to use tarballs
467 or other archived files that can capture the state of a release
468 guaranteeing that it is statically represented.
469 On the other hand, for a project that is more dynamic or
470 experimental in nature, a project might keep source files in a
471 repository controlled by a Source Control Manager (SCM) such as
472 Git.
473 Pulling source from a repository allows you to control
474 the point in the repository (the revision) from which you want to
475 build software.
476 Finally, a combination of the two might exist, which would give the
477 consumer a choice when deciding where to get source files.
478 </para>
479
480 <para>
481 BitBake uses the
482 <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
483 variable to point to source files regardless of their location.
484 Each recipe must have a <filename>SRC_URI</filename> variable
485 that points to the source.
486 </para>
487
488 <para>
489 Another area that plays a significant role in where source files
490 come from is pointed to by the
491 <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
492 variable.
493 This area is a cache that can hold previously downloaded source.
494 You can also instruct the OpenEmbedded build system to create
495 tarballs from Git repositories, which is not the default behavior,
496 and store them in the <filename>DL_DIR</filename> by using the
497 <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
498 variable.
499 </para>
500
501 <para>
502 Judicious use of a <filename>DL_DIR</filename> directory can
503 save the build system a trip across the Internet when looking
504 for files.
505 A good method for using a download directory is to have
506 <filename>DL_DIR</filename> point to an area outside of your
507 Build Directory.
508 Doing so allows you to safely delete the Build Directory
509 if needed without fear of removing any downloaded source file.
510 </para>
511
512 <para>
513 The remainder of this section provides a deeper look into the
514 source files and the mirrors.
515 Here is a more detailed look at the source file area of the
516 base figure:
517 <imagedata fileref="figures/source-input.png" align="center" width="7in" depth="7.5in" />
518 </para>
519
520 <section id='upstream-project-releases'>
521 <title>Upstream Project Releases</title>
522
523 <para>
524 Upstream project releases exist anywhere in the form of an
525 archived file (e.g. tarball or zip file).
526 These files correspond to individual recipes.
527 For example, the figure uses specific releases each for
528 BusyBox, Qt, and Dbus.
529 An archive file can be for any released product that can be
530 built using a recipe.
531 </para>
532 </section>
533
534 <section id='local-projects'>
535 <title>Local Projects</title>
536
537 <para>
538 Local projects are custom bits of software the user provides.
539 These bits reside somewhere local to a project - perhaps
540 a directory into which the user checks in items (e.g.
541 a local directory containing a development source tree
542 used by the group).
543 </para>
544
545 <para>
546 The canonical method through which to include a local project
547 is to use the
548 <link linkend='ref-classes-externalsrc'><filename>externalsrc</filename></link>
549 class to include that local project.
550 You use either the <filename>local.conf</filename> or a
551 recipe's append file to override or set the
552 recipe to point to the local directory on your disk to pull
553 in the whole source tree.
554 </para>
555
556 <para>
557 For information on how to use the
558 <filename>externalsrc</filename> class, see the
559 "<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
560 section.
561 </para>
562 </section>
563
564 <section id='scms'>
565 <title>Source Control Managers (Optional)</title>
566
567 <para>
568 Another place the build system can get source files from is
569 through an SCM such as Git or Subversion.
570 In this case, a repository is cloned or checked out.
571 The
572 <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>
573 task inside BitBake uses
574 the <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
575 variable and the argument's prefix to determine the correct
576 fetcher module.
577 </para>
578
579 <note>
580 For information on how to have the OpenEmbedded build system
581 generate tarballs for Git repositories and place them in the
582 <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
583 directory, see the
584 <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
585 variable.
586 </note>
587
588 <para>
589 When fetching a repository, BitBake uses the
590 <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
591 variable to determine the specific revision from which to
592 build.
593 </para>
594 </section>
595
596 <section id='source-mirrors'>
597 <title>Source Mirror(s)</title>
598
599 <para>
600 Two kinds of mirrors exist: pre-mirrors and regular mirrors.
601 The <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
602 and
603 <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
604 variables point to these, respectively.
605 BitBake checks pre-mirrors before looking upstream for any
606 source files.
607 Pre-mirrors are appropriate when you have a shared directory
608 that is not a directory defined by the
609 <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
610 variable.
611 A Pre-mirror typically points to a shared directory that is
612 local to your organization.
613 </para>
614
615 <para>
616 Regular mirrors can be any site across the Internet that is
617 used as an alternative location for source code should the
618 primary site not be functioning for some reason or another.
619 </para>
620 </section>
621 </section>
622
623 <section id="package-feeds-dev-environment">
624 <title>Package Feeds</title>
625
626 <para>
627 When the OpenEmbedded build system generates an image or an SDK,
628 it gets the packages from a package feed area located in the
629 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
630 The
631 <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
632 shows this package feeds area in the upper-right corner.
633 </para>
634
635 <para>
636 This section looks a little closer into the package feeds area used
637 by the build system.
638 Here is a more detailed look at the area:
639 <imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" />
640 </para>
641
642 <para>
643 Package feeds are an intermediary step in the build process.
644 BitBake generates packages whose types are defined by the
645 <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
646 variable.
647 Before placing the packages into package feeds,
648 the build process validates them with generated output quality
649 assurance checks through the
650 <link linkend='ref-classes-insane'><filename>insane</filename></link>
651 class.
652 </para>
653
654 <para>
655 The package feed area resides in
656 <filename>tmp/deploy</filename> of the Build Directory.
657 Folders are created that correspond to the package type
658 (IPK, DEB, or RPM) created.
659 Further organization is derived through the value of the
660 <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
661 variable for each package.
662 For example, packages can exist for the i586 or qemux86
663 architectures.
664 The package files themselves reside within the appropriate
665 architecture folder.
666 </para>
667
668 <para>
669 BitBake uses the <filename>do_package_write_*</filename> tasks to
670 place generated packages into the package holding area (e.g.
671 <filename>do_package_write_ipk</filename> for IPK packages).
672 See the
673 "<link linkend='ref-tasks-package_write_deb'><filename>do_package_write_deb</filename></link>",
674 "<link linkend='ref-tasks-package_write_ipk'><filename>do_package_write_ipk</filename></link>",
675 "<link linkend='ref-tasks-package_write_rpm'><filename>do_package_write_rpm</filename></link>",
676 and
677 "<link linkend='ref-tasks-package_write_tar'><filename>do_package_write_tar</filename></link>"
678 sections for additional information.
679 </para>
680 </section>
681
682 <section id='bitbake-dev-environment'>
683 <title>BitBake</title>
684
685 <para>
686 The OpenEmbedded build system uses
687 <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
688 to produce images.
689 You can see from the
690 <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
691 the BitBake area consists of several functional areas.
692 This section takes a closer look at each of those areas.
693 </para>
694
695 <para>
696 Separate documentation exists for the BitBake tool.
697 See the
698 <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>
699 for reference material on BitBake.
700 </para>
701
702 <section id='source-fetching-dev-environment'>
703 <title>Source Fetching</title>
704
705 <para>
706 The first stages of building a recipe are to fetch and unpack
707 the source code:
708 <imagedata fileref="figures/source-fetching.png" align="center" width="6.5in" depth="5in" />
709 </para>
710
711 <para>
712 The
713 <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>
714 and
715 <link linkend='ref-tasks-unpack'><filename>do_unpack</filename></link>
716 tasks fetch the source files and unpack them into the work
717 directory.
718 <note>
719 For every local file (e.g. <filename>file://</filename>)
720 that is part of a recipe's
721 <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
722 statement, the OpenEmbedded build system takes a checksum
723 of the file for the recipe and inserts the checksum into
724 the signature for the <filename>do_fetch</filename>.
725 If any local file has been modified, the
726 <filename>do_fetch</filename> task and all tasks that
727 depend on it are re-executed.
728 </note>
729 By default, everything is accomplished in the
730 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
731 which has a defined structure.
732 For additional general information on the Build Directory,
733 see the
734 "<link linkend='structure-core-build'><filename>build/</filename></link>"
735 section.
736 </para>
737
738 <para>
739 Unpacked source files are pointed to by the
740 <link linkend='var-S'><filename>S</filename></link> variable.
741 Each recipe has an area in the Build Directory where the
742 unpacked source code resides.
743 The name of that directory for any given recipe is defined from
744 several different variables.
745 You can see the variables that define these directories
746 by looking at the figure:
747 <itemizedlist>
748 <listitem><para><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> -
749 The base directory where the OpenEmbedded build system
750 performs all its work during the build.
751 </para></listitem>
752 <listitem><para><link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link> -
753 The architecture of the built package or packages.
754 </para></listitem>
755 <listitem><para><link linkend='var-TARGET_OS'><filename>TARGET_OS</filename></link> -
756 The operating system of the target device.
757 </para></listitem>
758 <listitem><para><link linkend='var-PN'><filename>PN</filename></link> -
759 The name of the built package.
760 </para></listitem>
761 <listitem><para><link linkend='var-PV'><filename>PV</filename></link> -
762 The version of the recipe used to build the package.
763 </para></listitem>
764 <listitem><para><link linkend='var-PR'><filename>PR</filename></link> -
765 The revision of the recipe used to build the package.
766 </para></listitem>
767 <listitem><para><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link> -
768 The location within <filename>TMPDIR</filename> where
769 a specific package is built.
770 </para></listitem>
771 <listitem><para><link linkend='var-S'><filename>S</filename></link> -
772 Contains the unpacked source files for a given recipe.
773 </para></listitem>
774 </itemizedlist>
775 </para>
776 </section>
777
778 <section id='patching-dev-environment'>
779 <title>Patching</title>
780
781 <para>
782 Once source code is fetched and unpacked, BitBake locates
783 patch files and applies them to the source files:
784 <imagedata fileref="figures/patching.png" align="center" width="6in" depth="5in" />
785 </para>
786
787 <para>
788 The
789 <link linkend='ref-tasks-patch'><filename>do_patch</filename></link>
790 task processes recipes by
791 using the
792 <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
793 variable to locate applicable patch files, which by default
794 are <filename>*.patch</filename> or
795 <filename>*.diff</filename> files, or any file if
796 "apply=yes" is specified for the file in
797 <filename>SRC_URI</filename>.
798 </para>
799
800 <para>
801 BitBake finds and applies multiple patches for a single recipe
802 in the order in which it finds the patches.
803 Patches are applied to the recipe's source files located in the
804 <link linkend='var-S'><filename>S</filename></link> directory.
805 </para>
806
807 <para>
808 For more information on how the source directories are
809 created, see the
810 "<link linkend='source-fetching-dev-environment'>Source Fetching</link>"
811 section.
812 </para>
813 </section>
814
815 <section id='configuration-and-compilation-dev-environment'>
816 <title>Configuration and Compilation</title>
817
818 <para>
819 After source code is patched, BitBake executes tasks that
820 configure and compile the source code:
821 <imagedata fileref="figures/configuration-compile-autoreconf.png" align="center" width="7in" depth="5in" />
822 </para>
823
824 <para>
825 This step in the build process consists of three tasks:
826 <itemizedlist>
827 <listitem><para><emphasis><filename>do_configure</filename>:</emphasis>
828 This task configures the source by enabling and
829 disabling any build-time and configuration options for
830 the software being built.
831 Configurations can come from the recipe itself as well
832 as from an inherited class.
833 Additionally, the software itself might configure itself
834 depending on the target for which it is being built.
835 </para>
836
837 <para>The configurations handled by the
838 <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
839 task are specific
840 to source code configuration for the source code
841 being built by the recipe.</para>
842
843 <para>If you are using the
844 <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
845 class,
846 you can add additional configuration options by using
847 the <link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>
848 variable.
849 For information on how this variable works within
850 that class, see the
851 <filename>meta/classes/autotools.bbclass</filename> file.
852 </para></listitem>
853 <listitem><para><emphasis><filename>do_compile</filename>:</emphasis>
854 Once a configuration task has been satisfied, BitBake
855 compiles the source using the
856 <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
857 task.
858 Compilation occurs in the directory pointed to by the
859 <link linkend='var-B'><filename>B</filename></link>
860 variable.
861 Realize that the <filename>B</filename> directory is, by
862 default, the same as the
863 <link linkend='var-S'><filename>S</filename></link>
864 directory.</para></listitem>
865 <listitem><para><emphasis><filename>do_install</filename>:</emphasis>
866 Once compilation is done, BitBake executes the
867 <link linkend='ref-tasks-install'><filename>do_install</filename></link>
868 task.
869 This task copies files from the <filename>B</filename>
870 directory and places them in a holding area pointed to
871 by the
872 <link linkend='var-D'><filename>D</filename></link>
873 variable.</para></listitem>
874 </itemizedlist>
875 </para>
876 </section>
877
878 <section id='package-splitting-dev-environment'>
879 <title>Package Splitting</title>
880
881 <para>
882 After source code is configured and compiled, the
883 OpenEmbedded build system analyzes
884 the results and splits the output into packages:
885 <imagedata fileref="figures/analysis-for-package-splitting.png" align="center" width="7in" depth="7in" />
886 </para>
887
888 <para>
889 The
890 <link linkend='ref-tasks-package'><filename>do_package</filename></link>
891 and
892 <link linkend='ref-tasks-packagedata'><filename>do_packagedata</filename></link>
893 tasks combine to analyze
894 the files found in the
895 <link linkend='var-D'><filename>D</filename></link> directory
896 and split them into subsets based on available packages and
897 files.
898 The analyzing process involves the following as well as other
899 items: splitting out debugging symbols,
900 looking at shared library dependencies between packages,
901 and looking at package relationships.
902 The <filename>do_packagedata</filename> task creates package
903 metadata based on the analysis such that the
904 OpenEmbedded build system can generate the final packages.
905 Working, staged, and intermediate results of the analysis
906 and package splitting process use these areas:
907 <itemizedlist>
908 <listitem><para><link linkend='var-PKGD'><filename>PKGD</filename></link> -
909 The destination directory for packages before they are
910 split.
911 </para></listitem>
912 <listitem><para><link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link> -
913 A shared, global-state directory that holds data
914 generated during the packaging process.
915 </para></listitem>
916 <listitem><para><link linkend='var-PKGDESTWORK'><filename>PKGDESTWORK</filename></link> -
917 A temporary work area used by the
918 <filename>do_package</filename> task.
919 </para></listitem>
920 <listitem><para><link linkend='var-PKGDEST'><filename>PKGDEST</filename></link> -
921 The parent directory for packages after they have
922 been split.
923 </para></listitem>
924 </itemizedlist>
925 The <link linkend='var-FILES'><filename>FILES</filename></link>
926 variable defines the files that go into each package in
927 <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>.
928 If you want details on how this is accomplished, you can
929 look at the
930 <link linkend='ref-classes-package'><filename>package</filename></link>
931 class.
932 </para>
933
934 <para>
935 Depending on the type of packages being created (RPM, DEB, or
936 IPK), the <filename>do_package_write_*</filename> task
937 creates the actual packages and places them in the
938 Package Feed area, which is
939 <filename>${TMPDIR}/deploy</filename>.
940 You can see the
941 "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
942 section for more detail on that part of the build process.
943 <note>
944 Support for creating feeds directly from the
945 <filename>deploy/*</filename> directories does not exist.
946 Creating such feeds usually requires some kind of feed
947 maintenance mechanism that would upload the new packages
948 into an official package feed (e.g. the
949 Ångström distribution).
950 This functionality is highly distribution-specific
951 and thus is not provided out of the box.
952 </note>
953 </para>
954 </section>
955
956 <section id='image-generation-dev-environment'>
957 <title>Image Generation</title>
958
959 <para>
960 Once packages are split and stored in the Package Feeds area,
961 the OpenEmbedded build system uses BitBake to generate the
962 root filesystem image:
963 <imagedata fileref="figures/image-generation.png" align="center" width="6in" depth="7in" />
964 </para>
965
966 <para>
967 The image generation process consists of several stages and
968 depends on many variables.
969 The
970 <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
971 task uses these key variables
972 to help create the list of packages to actually install:
973 <itemizedlist>
974 <listitem><para><link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>:
975 Lists out the base set of packages to install from
976 the Package Feeds area.</para></listitem>
977 <listitem><para><link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>:
978 Specifies packages that should not be installed.
979 </para></listitem>
980 <listitem><para><link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>:
981 Specifies features to include in the image.
982 Most of these features map to additional packages for
983 installation.</para></listitem>
984 <listitem><para><link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>:
985 Specifies the package backend to use and consequently
986 helps determine where to locate packages within the
987 Package Feeds area.</para></listitem>
988 <listitem><para><link linkend='var-IMAGE_LINGUAS'><filename>IMAGE_LINGUAS</filename></link>:
989 Determines the language(s) for which additional
990 language support packages are installed.
991 </para></listitem>
992 </itemizedlist>
993 </para>
994
995 <para>
996 Package installation is under control of the package manager
997 (e.g. smart/rpm, opkg, or apt/dpkg) regardless of whether or
998 not package management is enabled for the target.
999 At the end of the process, if package management is not
1000 enabled for the target, the package manager's data files
1001 are deleted from the root filesystem.
1002 </para>
1003
1004 <para>
1005 During image generation, the build system attempts to run
1006 all post-installation scripts.
1007 Any that fail to run on the build host are run on the
1008 target when the target system is first booted.
1009 If you are using a
1010 <ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>read-only root filesystem</ulink>,
1011 all the post installation scripts must succeed during the
1012 package installation phase since the root filesystem is
1013 read-only.
1014 </para>
1015
1016 <para>
1017 During Optimization, optimizing processes are run across
1018 the image.
1019 These processes include <filename>mklibs</filename> and
1020 <filename>prelink</filename>.
1021 The <filename>mklibs</filename> process optimizes the size
1022 of the libraries.
1023 A <filename>prelink</filename> process optimizes the dynamic
1024 linking of shared libraries to reduce start up time of
1025 executables.
1026 </para>
1027
1028 <para>
1029 Along with writing out the root filesystem image, the
1030 <filename>do_rootfs</filename> task creates a manifest file
1031 (<filename>.manifest</filename>) in the same directory as
1032 the root filesystem image that lists out, line-by-line, the
1033 installed packages.
1034 This manifest file is useful for the
1035 <link linkend='ref-classes-testimage'><filename>testimage</filename></link>
1036 class, for example, to determine whether or not to run
1037 specific tests.
1038 See the
1039 <link linkend='var-IMAGE_MANIFEST'><filename>IMAGE_MANIFEST</filename></link>
1040 variable for additional information.
1041 </para>
1042
1043 <para>
1044 Part of the image generation process includes compressing the
1045 root filesystem image.
1046 Compression is accomplished through several optimization
1047 routines designed to reduce the overall size of the image.
1048 </para>
1049
1050 <para>
1051 After the root filesystem has been constructed, the image
1052 generation process turns everything into an image file or
1053 a set of image files.
1054 The formats used for the root filesystem depend on the
1055 <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
1056 variable.
1057 </para>
1058
1059 <note>
1060 The entire image generation process is run under Pseudo.
1061 Running under Pseudo ensures that the files in the root
1062 filesystem have correct ownership.
1063 </note>
1064 </section>
1065
1066 <section id='sdk-generation-dev-environment'>
1067 <title>SDK Generation</title>
1068
1069 <para>
1070 The OpenEmbedded build system uses BitBake to generate the
1071 Software Development Kit (SDK) installer script:
1072 <imagedata fileref="figures/sdk-generation.png" align="center" width="6in" depth="7in" />
1073 </para>
1074
1075 <note>
1076 For more information on the cross-development toolchain
1077 generation, see the
1078 "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
1079 section.
1080 For information on advantages gained when building a
1081 cross-development toolchain using the
1082 <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
1083 task, see the
1084 "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
1085 section in the Yocto Project Application Developer's Guide.
1086 </note>
1087
1088 <para>
1089 Like image generation, the SDK script process consists of
1090 several stages and depends on many variables.
1091 The <filename>do_populate_sdk</filename> task uses these
1092 key variables to help create the list of packages to actually
1093 install.
1094 For information on the variables listed in the figure, see the
1095 "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
1096 section.
1097 </para>
1098
1099 <para>
1100 The <filename>do_populate_sdk</filename> task handles two
1101 parts: a target part and a host part.
1102 The target part is the part built for the target hardware and
1103 includes libraries and headers.
1104 The host part is the part of the SDK that runs on the
1105 <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>.
1106 </para>
1107
1108 <para>
1109 Once both parts are constructed, the
1110 <filename>do_populate_sdk</filename> task performs some cleanup
1111 on both parts.
1112 After the cleanup, the task creates a cross-development
1113 environment setup script and any configuration files that
1114 might be needed.
1115 </para>
1116
1117 <para>
1118 The final output of the task is the Cross-development
1119 toolchain installation script (<filename>.sh</filename> file),
1120 which includes the environment setup script.
1121 </para>
1122 </section>
1123 </section>
1124
1125 <section id='images-dev-environment'>
1126 <title>Images</title>
1127
1128 <para>
1129 The images produced by the OpenEmbedded build system
1130 are compressed forms of the
1131 root filesystem that are ready to boot on a target device.
1132 You can see from the
1133 <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
1134 that BitBake output, in part, consists of images.
1135 This section is going to look more closely at this output:
1136 <imagedata fileref="figures/images.png" align="center" width="5.5in" depth="5.5in" />
1137 </para>
1138
1139 <para>
1140 For a list of example images that the Yocto Project provides,
1141 see the
1142 "<link linkend='ref-images'>Images</link>" chapter.
1143 </para>
1144
1145 <para>
1146 Images are written out to the
1147 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
1148 inside the <filename>tmp/deploy/images/<replaceable>machine</replaceable>/</filename>
1149 folder as shown in the figure.
1150 This folder contains any files expected to be loaded on the
1151 target device.
1152 The
1153 <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
1154 variable points to the <filename>deploy</filename> directory,
1155 while the
1156 <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
1157 variable points to the appropriate directory containing images for
1158 the current configuration.
1159 <itemizedlist>
1160 <listitem><para><filename><replaceable>kernel-image</replaceable></filename>:
1161 A kernel binary file.
1162 The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
1163 variable setting determines the naming scheme for the
1164 kernel image file.
1165 Depending on that variable, the file could begin with
1166 a variety of naming strings.
1167 The <filename>deploy/images/<replaceable>machine</replaceable></filename>
1168 directory can contain multiple image files for the
1169 machine.</para></listitem>
1170 <listitem><para><filename><replaceable>root-filesystem-image</replaceable></filename>:
1171 Root filesystems for the target device (e.g.
1172 <filename>*.ext3</filename> or <filename>*.bz2</filename>
1173 files).
1174 The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
1175 variable setting determines the root filesystem image
1176 type.
1177 The <filename>deploy/images/<replaceable>machine</replaceable></filename>
1178 directory can contain multiple root filesystems for the
1179 machine.</para></listitem>
1180 <listitem><para><filename><replaceable>kernel-modules</replaceable></filename>:
1181 Tarballs that contain all the modules built for the kernel.
1182 Kernel module tarballs exist for legacy purposes and
1183 can be suppressed by setting the
1184 <link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link>
1185 variable to "0".
1186 The <filename>deploy/images/<replaceable>machine</replaceable></filename>
1187 directory can contain multiple kernel module tarballs
1188 for the machine.</para></listitem>
1189 <listitem><para><filename><replaceable>bootloaders</replaceable></filename>:
1190 Bootloaders supporting the image, if applicable to the
1191 target machine.
1192 The <filename>deploy/images/<replaceable>machine</replaceable></filename>
1193 directory can contain multiple bootloaders for the
1194 machine.</para></listitem>
1195 <listitem><para><filename><replaceable>symlinks</replaceable></filename>:
1196 The <filename>deploy/images/<replaceable>machine</replaceable></filename>
1197 folder contains
1198 a symbolic link that points to the most recently built file
1199 for each machine.
1200 These links might be useful for external scripts that
1201 need to obtain the latest version of each file.
1202 </para></listitem>
1203 </itemizedlist>
1204 </para>
1205 </section>
1206
1207 <section id='sdk-dev-environment'>
1208 <title>Application Development SDK</title>
1209
1210 <para>
1211 In the
1212 <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
1213 the output labeled "Application Development SDK" represents an
1214 SDK.
1215 This section is going to take a closer look at this output:
1216 <imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" />
1217 </para>
1218
1219 <para>
1220 The specific form of this output is a self-extracting
1221 SDK installer (<filename>*.sh</filename>) that, when run,
1222 installs the SDK, which consists of a cross-development
1223 toolchain, a set of libraries and headers, and an SDK
1224 environment setup script.
1225 Running this installer essentially sets up your
1226 cross-development environment.
1227 You can think of the cross-toolchain as the "host"
1228 part because it runs on the SDK machine.
1229 You can think of the libraries and headers as the "target"
1230 part because they are built for the target hardware.
1231 The setup script is added so that you can initialize the
1232 environment before using the tools.
1233 </para>
1234
1235 <note>
1236 <para>
1237 The Yocto Project supports several methods by which you can
1238 set up this cross-development environment.
1239 These methods include downloading pre-built SDK installers,
1240 building and installing your own SDK installer, or running
1241 an Application Development Toolkit (ADT) installer to
1242 install not just cross-development toolchains
1243 but also additional tools to help in this type of
1244 development.
1245 </para>
1246
1247 <para>
1248 For background information on cross-development toolchains
1249 in the Yocto Project development environment, see the
1250 "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
1251 section.
1252 For information on setting up a cross-development
1253 environment, see the
1254 "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
1255 section in the Yocto Project Application Developer's Guide.
1256 </para>
1257 </note>
1258
1259 <para>
1260 Once built, the SDK installers are written out to the
1261 <filename>deploy/sdk</filename> folder inside the
1262 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
1263 as shown in the figure at the beginning of this section.
1264 Several variables exist that help configure these files:
1265 <itemizedlist>
1266 <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
1267 Points to the <filename>deploy</filename>
1268 directory.</para></listitem>
1269 <listitem><para><link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>:
1270 Specifies the architecture of the machine
1271 on which the cross-development tools are run to
1272 create packages for the target hardware.
1273 </para></listitem>
1274 <listitem><para><link linkend='var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></link>:
1275 Lists the features to include in the "target" part
1276 of the SDK.
1277 </para></listitem>
1278 <listitem><para><link linkend='var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></link>:
1279 Lists packages that make up the host
1280 part of the SDK (i.e. the part that runs on
1281 the <filename>SDKMACHINE</filename>).
1282 When you use
1283 <filename>bitbake -c populate_sdk <replaceable>imagename</replaceable></filename>
1284 to create the SDK, a set of default packages
1285 apply.
1286 This variable allows you to add more packages.
1287 </para></listitem>
1288 <listitem><para><link linkend='var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></link>:
1289 Lists packages that make up the target part
1290 of the SDK (i.e. the part built for the
1291 target hardware).
1292 </para></listitem>
1293 <listitem><para><link linkend='var-SDKPATH'><filename>SDKPATH</filename></link>:
1294 Defines the default SDK installation path offered by the
1295 installation script.
1296 </para></listitem>
1297 </itemizedlist>
1298 </para>
1299 </section>
1300
1301</chapter>
1302<!--
1303vim: expandtab tw=80 ts=4
1304-->
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-04-20 02:50:03 +0000