docs: unbreak "make html" by adding missing xsl files
[openembedded.git] / docs / usermanual / embworld-oe.dbk
1 <BASE HREF="/home/vollmann/winuser/conferences/embworld/embworld-oe.dbk">
2
3 <?xml version="1.0"?>
4 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
5           "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
6
7 <!-- $Id$ -->
8
9 <article lang="en">
10   <articleinfo>
11     <date>First version January 3, 2006</date>
12     <title>OpenEmbedded for Deep Embedded Systems</title>
13
14     <author>
15       <firstname>Detlef</firstname>
16       <surname>Vollmann</surname>
17         <affiliation>
18           <orgname>vollmann engineering gmbh</orgname>
19           <address>
20 <pob>P.O. Box 5423</pob>
21 <city>6000 Luzern 5</city>
22 <country>Switzerland</country>
23 <email>dv@vollmann.ch</email>
24           </address>
25         </affiliation>
26     </author>
27
28     <copyright>
29       <year>2006</year>
30       <holder>Detlef Vollmann</holder>
31     </copyright>
32   </articleinfo>
33
34 <abstract>
35 <title>Abstract</title>
36  <para>
37 OpenEmbedded has won the TuxMobil GNU/Linux
38 Award 2005 that honors Free Software projects, which improve Linux
39 for mobile computers.  OpenEmbedded is a Linux distribution similar
40 to Debian that has its roots in the PDA domain.  It is today pretty
41 popular among Linux fans who own Zaurus', iPAQs or similar PDAs.
42 But OpenEmbedded is targeted at all kinds of embedded Linux systems.
43 It features a unique cross build environment that generally allows
44 pretty easy adaption of OpenSource software for cross compilation even
45 if the original software authors didn't think about cross builds.
46 That build environment also allows for easy definition and builds of
47 complete distributions for embedded systems.
48  </para>
49
50  <para>
51 OpenEmbedded also provides a lightweight and fine-grained package
52 system that enables easy installation of new software packages into
53 a running system as well as updates of existing software.
54 These features makes OpenEmbedded a first choice for the creation
55 of embedded Linux systems.
56  </para>
57 </abstract>
58
59
60 <sect1 label="1" id="introduction">
61 <title>Introduction</title>
62  <para>
63 When Sharp launched its Zaurus PDA, it came with a Linux based PDA system.
64 But not all users were happy with the original Sharp configuration and
65 so the OpenZaurus project was created to share the modifications.
66 Later, OpenZaurus moved from modifications to the original Sharp image
67 to a complete distribution based on Debian.
68  </para>
69
70  <para>
71 But the build system for Debian was not really suited for small embedded
72 systems and so OpenEmbedded was founded with a build system inspired
73 from Gentoo's <command>portage</command>.  As package system iPKG was used, which is
74 closely related to Debian's <command>dpkg</command>, but more tuned for small embedded
75 devices.
76 Later, distributions for other PDAs like Compaq's iPAQs or the Siemens
77 SimPad moved to the OpenEmbedded build and package system.
78 A very interesting distribution based on OpenEmbedded is OpenSLUG
79 for LinkSys' NSLU device.  The NSLU is not a PDA but originally
80 an NAS storage system.
81  </para>
82
83  <para>
84 Today, OpenEmbedded describes itself as a "set of recipes and metadata
85 to build Linux distributions for embedded devices with the BitBake
86 build system".
87  </para>
88
89  <para>
90 OpenEmbedded provides three major benefits for building a distribution
91 for an embedded system:
92  <itemizedlist mark='bullet'>
93 <listitem>
94  <para>
95  a build system that builds everything
96  </para>
97 </listitem>
98 <listitem>
99  <para>
100  recipes and metadata to build more that 1000 different programs
101    and libraries
102  </para>
103 </listitem>
104 <listitem>
105  <para>
106  a binary package system that provides simple configuration and update
107    mechanisms
108  </para>
109 </listitem>
110  </itemizedlist>
111  </para>
112
113  <para>
114 The remainder of this article focuses on the use of OpenEmbedded
115 for deep embedded systems like the NSLU opposed to PDA like systems
116 like the SimPad.
117  </para>
118
119 </sect1>
120
121 <sect1 id="overview">
122 <title>Overview</title>
123  <sect2>
124  <title>Build System</title>
125    <para>
126 Like any build tool (make, ant, jam), the OpenEmbedded build tool
127 BitBake controls how to build things and the build dependencies.
128 But unlike single project tools like <command>make</command> it is not based on one makefile
129 or a closed set of inter-dependent makefiles, but collects and manages
130 an open set of largely independent build descriptions (package recipes) and
131 builds them in proper order.
132  </para>
133
134  <para>
135 The OpenEmbedded set of package recipes include not only recipes for
136 target packages, but also recipes for tools on the host required to build
137 those target packages.  So, OpenEmbedded builds a complete toolchain
138 for cross-building before building the target packages and image.
139    </para>
140  </sect2>
141
142  <sect2>
143  <title>Metadata</title>
144    <para>
145 The metadata from which an OpenEmbedded distribution is built comes in
146 three different forms:
147    <itemizedlist mark='bullet'>
148     <listitem>
149       <para>
150  configuration files
151       </para>
152     </listitem>
153     <listitem>
154       <para>
155  class descriptions
156       </para>
157     </listitem>
158     <listitem>
159       <para>
160  package recipes
161       </para>
162     </listitem>
163    </itemizedlist>
164    </para>
165
166    <para>
167 The configuration files provide general variable definitions to control
168 the behaviour of BitBake and how things are generally built in
169 OpenEmbedded.  This includes the build system's directory structure,
170 version preferences, source code mirror sites as well as specific build
171 options (e.g. the default optimizing level).
172    </para>
173
174    <para>
175 The class descriptions define common procedures to build things, like
176 applying the auto-tools for configuration, collecting runtime library
177 dependencies or building native build tools for the host.
178 These class descriptions are sometimes quite specific, e.g. there exists a
179 class to remove NLS parts of a package if NLS support is not wanted.
180    </para>
181
182    <para>
183 The package recipes provide the information how to build a specific
184 piece of software &dash; a build tool for the host, a library or a
185 target application.  Such recipes provide the information how to get
186 and how to build a package and dependencies on other packages.
187    </para>
188
189    <para>
190 Meta package recipes don't build a specific package, but mainly consist
191 of dependency descriptions to build a complete set of packages, often
192 a base image for a specific distribution.
193    </para>
194  </sect2>
195
196  <sect2>
197  <title>Package System</title>
198    <para>
199 The iPKG package system is (deliberately) very similar to Debian's <command>dpkg</command>,
200 but is tuned for small systems.  It contains the package data that is
201 simply copied to the target system, metadata and optionally
202 installation scripts.  The metadata includes the (run-time) dependencies
203 of the package.
204    </para>
205
206    <para>
207 Package systems are mainly for the benefit of users of computer-like
208 devices who want to install their own specific set of software.
209 Such package systems provide two major benefits:
210    <itemizedlist mark='bullet'>
211      <listitem>
212       <para>
213  easy definition of an initial image, often called 'base system'
214       </para>
215      </listitem>
216      <listitem>
217       <para>
218  controlled installation, upgrade and de-installation of packages
219    on the running system
220       </para>
221      </listitem>
222    </itemizedlist>
223    </para>
224
225    <para>
226 These benefits also apply to (deep) embedded systems.
227 Different configurations are just different sets of packages.  They can
228 even share the already built packages from existing configurations.
229    </para>
230
231    <para>
232 In traditional embedded systems for an update first a new
233 complete image is built that then requires on the target a shutdown,
234 a complete re-flash of the image and finally a restart of the system.
235 Contrasting to that image-based process, a package system allows easy
236 updates on a live, running system that
237 even allows to have some processes running the old version (though it
238 is already de-installed) while other processes already run the new version.
239    </para>
240  </sect2>
241 </sect1>
242
243 <sect1>
244  <title>Working with OpenEmbedded</title>
245    <para>
246 To build a system based on OpenEmbedded, normally a small set of
247 configuration files is needed:
248    <itemizedlist mark='bullet'>
249      <listitem>
250       <para>
251  <filename>local.conf</filename> to define what to build and where to get and put it
252       </para>
253      </listitem>
254      <listitem>
255       <para>
256  a machine configuration to describe the hardware
257       </para>
258      </listitem>
259      <listitem>
260       <para>
261  a distribution configuration to define global properties of the system
262       </para>
263      </listitem>
264    </itemizedlist>
265    </para>
266
267
268    <para>
269 Apart from that, typically a meta package for the base image is required.
270 And then of course the recipes for specific packages, e.g. a kernel
271 package, packages for additional Open Source applications and
272 packages for project specific software.
273    </para>
274
275  <sect2>
276       <title><filename>local.conf</filename></title>
277    <para>
278 The local configuration file <filename>local.conf</filename> defines the local directory
279 structure, the local build environment, some project specific preferences
280 and other properties specific to the build system.
281    </para>
282    <para>
283 A very simple and short <filename>local.conf</filename> could look like this:
284 <programlisting>
285 # DL_DIR specifies the download target directory
286 DL_DIR = "${PROJECT}/oesrc"
287
288 # BBFILES specifies the full set of package recipes to be parsed by BitBake
289 BBFILES = "${PROJECT}/org.openembedded.dev/packages/*/*.bb"
290
291 # BBMASK specifies which package recipes to ignore from the full set above
292 BBMASK = ""
293
294 # ASSUME_PROVIDED defines what local host build tools should
295 # not be built by BitBake but should be used from the local
296 # build host's installation
297 ASSUME_PROVIDED = "flex-native"
298
299 # For some tools exist different alternative implementations,
300 # e.g. for the C runtime library there exist glibc and uClibc.
301 # PREFERRED_PROVIDERS defines which specific package to build
302 PREFERRED_PROVIDERS = "virtual/kernel:mymach24"
303 PREFERRED_PROVIDERS += " virtual/libc:glibc"
304
305 # For many packages exist several different recipes.
306 # PREFERRED_VERSION defines which specific recipe to use
307 PREFERRED_VERSION_gcc-cross = "3.3.2"
308
309 # MACHINE defines for which hardware to build
310 MACHINE = "mymach"
311
312 # DISTRO defines which distribution to build
313 DISTRO = "mymini"
314
315 # IMAGE_FSTYPES defines which kind of images to create
316 IMAGE_FSTYPES = "jffs2 tar"
317
318 # For a number of package recipe versions the source code is fetched directly
319 # from the original CVS repository head.  To make sure that for separate
320 # builds this fetches the same source, use CVSDATE.
321 CVSDATE = "20051122"
322
323 # For some packages specific CVS versions are provided as tarballs.
324 # CVS_TARBALL_STASH defines where to find them.
325 CVS_TARBALL_STASH = "http://www.oesources.org/source/current/"
326
327 # For a number of software sets it is possible to specify local
328 # mirror sites where to get the software.
329 export GNU_MIRROR = "http://mirror.switch.ch/ftp/mirror/gnu"
330
331 # URL for own stuff
332 MY_URL = "http://myserver/projects/oe"
333
334 </programlisting>
335
336    </para>
337  </sect2>
338
339  <sect2>
340  <title>Machine Configuration</title>
341    <para>
342 The machine configuration file <filename>conf/machine/mymach.conf</filename> specifies
343 the hardware for which a distribution is built.  This includes mainly
344 the CPU architecture, specific hardware kernel modules and some size
345 specifications.
346    </para>
347    <para>
348 A simple example could look like this:
349 <programlisting>
350 #@TYPE: Machine
351 #@NAME: My own hardware
352 #@DESCRIPTION: Machine configuration for my system XYZ
353
354 # the target CPU architecture
355 TARGET_ARCH = "arm"
356
357 # all compatible binary architectures
358 IPKG_ARCHS = "all arm armv4 armv4t armv5e armv5te ipaqpxa mymach"
359
360 # some packages for which we know they work best for our hardware
361 PREFERRED_PROVIDER_xserver ?= "xserver-kdrive"
362 PREFERRED_PROVIDER_virtual/kernel ?= "mykernel24"
363
364 # some packages we always need for this hardware
365 BOOTSTRAP_EXTRA_DEPENDS = "virtual/kernel sdmmc-support altboot"
366 BOOTSTRAP_EXTRA_RDEPENDS = "kernel sdmmc-support altboot"
367 BOOTSTRAP_EXTRA_RDEPENDS += " kernel-module-usbdcore kernel-module-usbdmonitor"
368
369 # autoload on boot
370 module_autoload_mydriver = "mydriver"
371
372 # compile with XScale optimization
373 include conf/machine/tune-xscale.conf
374
375 # some specific settings
376 SERIAL_CONSOLE = "115200 ttyS0"
377 ROOT_FLASH_SIZE = "16"
378 GUI_MACHINE_CLASS = "smallscreen"
379
380 </programlisting>
381
382    </para>
383  </sect2>
384
385  <sect2>
386  <title>Distribution Configuration</title>
387    <para>
388 The distribution configuration file <filename>conf/distro/mymini.conf</filename> specifies
389 global configuration parameters for the whole software system on the
390 target.  The main definition here is the OS setting, but included here are
391 also internationalization settings or a specific target filesystem layout.
392    </para>
393    <para>
394 A simple example could look like this:
395 <programlisting>
396 #@TYPE: Distribution
397 #@NAME: MyMini
398 #@DESCRIPTION: A minimal base system for my system
399
400 # some general descriptions
401 DISTRO = "MyMini"
402 DISTRO_NAME = "My Minimal Embedded Linux"
403 DISTRO_VERSION = "1.0"
404 DISTRO_TYPE = "release"
405
406 # feed definitions for ipkg
407 FEED_URIS += " \
408      base##${MY_URL}/${DISTRO_VERSION}/feed/base \
409      updates##${MY_URL}/${DISTRO_VERSION}/feed/updates"
410
411 # base system
412 TARGET_FPU = "soft"
413 TARGET_OS = "linux-uclibc"
414
415 # specific software versions
416 PREFERRED_PROVIDER_xserver ?= "xserver-kdrive"
417 PREFERRED_VERSION_xserver-kdrive ?= "20050207"
418
419 # i18n
420 USE_NLS = "yes"
421
422 # distro is based on udev
423 UDEV_DEVFS_RULES = "1"
424
425 # distro is ipkg based
426 INHERIT += " package_ipk"
427
428 </programlisting>
429 <!-- note MY_URL here -->
430
431    </para>
432  </sect2>
433
434  <sect2>
435  <title>An Image Package</title>
436    <para>
437 The image package recipe <filename>packages/meta/my-image.bb</filename>
438 builds the base system
439 for the root filesystem image.  It mainly defines the packages that
440 are included in the base image.
441    </para>
442    <para>
443 A simple example could look like this:
444 <programlisting>
445 # general description data
446 DESCRIPTION = "Core packages for a minimal installation for My"
447 MAINTAINER = "Me &lt;me@myname.org>"
448 LICENSE = "GPL"
449 PR = "r0"
450
451 MY_PACKAGES = "base-files-my \
452         busybox-my initscripts-colibri netbase \
453         sysvinit usbutils modutils-initscripts \
454         my-modules24 e2fsprogs-mke2fs diffutils ipkg"
455
456 # binary architecture for ipkg
457 PACKAGE_ARCH = "${MACHINE_ARCH}"
458
459 # name
460 export IMAGE_BASENAME = "my"
461
462 # which languages to include
463 export IMAGE_LINGUAS = ""
464
465 # which packages to include
466 export IPKG_INSTALL = ${MY_PACKAGES}
467
468 # give the packages again so the build systems knows they must be built
469 DEPENDS = ${MY_PACKAGES}
470
471 # inherit the class that finally builds the image
472 inherit image_ipk
473
474 </programlisting>
475
476    </para>
477  </sect2>
478
479  <sect2>
480  <title>A Kernel Package</title>
481    <para>
482 The kernel is typically specific to a hardware, so usually an own kernel
483 package is required.
484    </para>
485    <para>
486 A simple example <filename>packages/linux/mymach24_2.4.29-mymach</filename>
487 could look like this:
488 <programlisting>
489 DESCRIPTION = "Linux kernel 2.4 for My hardware"
490 MAINTAINER = "Me &lt;me@myname.org>"
491 SECTION = "kernel"
492 LICENSE = "GPL"
493 PR = "r0"
494
495 # compute the kernel version strings
496 KV = "${@bb.data.getVar('PV',d,True).split('-')[0]}"
497 MYV = "${@bb.data.getVar('PV',d,True).split('-')[1]}"
498
499 # object suffix dependent on kernel version
500 KERNEL_OBJECT_SUFFIX = ".o"
501
502 # where to get the base kernel
503 SRC_URI = "${KERNEL_MIRROR}/v2./linux-${KV}.tar.bz2"
504
505 # where to get my specific patches
506 SRC_URI_append = " ${MY_URL}/patches/linux-${KV}-${MYV}.patch.gz;patch=1"
507
508 # specify the source directory
509 # (only necessary where it differs from the package name)
510 S = "${WORKDIR}/linux-${KV}"
511
512 # inherit the class that actually does the work building kernels
513 inherit kernel
514
515 # this not only builds the kernel itself but also the modules
516 PROVIDES += " my-modules24"
517 PACKAGES += " my-modules24"
518
519 # tell the packager where the files for the modules package are found
520 FILES_my-modules24 = "/lib/modules"
521
522 # which machines are supported by this kernel
523 COMPATIBLE_HOST = "arm.*-linux"
524
525 # nothing special is required to build the kernel, as it comes with
526 # full support for cross compilation
527 EXTRA_OEMAKE = ""
528
529 # the actual configure command
530 # oe_runmake just runs make
531 do_configure() {
532         oe_runmake mymach_defconfig
533 }
534
535 # clean up after module installation
536 do_install_append() {
537     rm -f ${D}/lib/modules/*/build
538     rm -f ${D}/lib/modules/*/source
539 }
540
541 </programlisting>
542 Some details for this package recipe are explained in the next section.
543    </para>
544  </sect2>
545
546  <sect2>
547  <title>A Package for an Open Source Project</title>
548    <para>
549 Though OpenEmbedded comes with recipes for many Open Source projects,
550 sometimes a package is required for which no recipe exists yet.
551 But providing a recipe for that project is generally quite easy.
552
553 Most Open Source projects are based on the configure mechanism to build.
554 <command>configure</command> is a script to collect information about
555 the build environment
556 and creates makefiles based on that information.
557    </para>
558    <para>
559 But the configure script itself is normally generated through the auto-tools.
560 The normal OpenEmbedded build process for such a project is to rebuild the
561 configure script based on the ultimate source <filename>Makefile.am</filename>
562 and <filename>configure.ac</filename>.
563    </para>
564    <para>
565 So, a simple package file for the <command>at</command> tool looks like this:
566 <programlisting>
567 DESCRIPTION = "Delayed job execution and batch processing."
568 SECTION = "base"
569 LICENSE="BSD"
570
571 PR = "r1"
572
573 DEPENDS = "flex-native"
574
575 SRC_URI = "${DEBIAN_MIRROR}/main/a/at/at_${PV}-11.tar.gz \
576            file://configure.patch;patch=1 \
577            file://nonrootinstall.patch;patch=1"
578
579 inherit autotools
580
581 </programlisting>
582    </para>
583    <para>
584 That's all.  Here a walkthrough for this recipe:
585 The first three lines in this package file are just general information
586 (that are included into the resulting binary package).
587    </para>
588    <para>
589 <varname>PR</varname> defines the revision and should be incremented
590 on each change to the package recipe.
591    </para>
592    <para>
593 The <varname>DEPENDS</varname> definition states that the building of
594 this package depends
595 on an existing flex installation on the host (therefore the
596 <filename>-native</filename>).
597    </para>
598    <para>
599 The <varname>SRC_URI</varname> defines the place of the source files
600 to be downloaded:
601 the main distribution tarball with the URL where to find it, and two
602 specific patches to build this package with OpenEmbedded.
603 These patches are located together with the package file.
604 The <varname>patch=1</varname> specifies that this file is to be
605 applied as patch with <option>-p1</option>.
606 The <varname>${PV}</varname> in the tarball URL is expanded from the
607 recipe version
608 number.  And the recipe version number is taken from the file name
609 of the recipe.  So, if this recipe is provided as
610 <filename>packages/at/at_3.1.8.bb</filename>,
611 <varname>${PV}</varname> is expanded to <varname>3.1.8</varname>.
612    </para>
613    <para>
614 The next line essentially does all the work: it inherits the
615 <classname>autotools</classname>
616 class that adds the necessary step (task) to rebuild the configure script.
617    </para>
618    <para>
619 And that's all.  The <classname>base</classname> class that is inherited
620 by all packages
621 defines all the other tasks to build the binary package:
622    <itemizedlist mark='bullet'>
623      <listitem>
624       <para>
625  <function>do_fetch()</function>, which does the download
626       </para>
627      </listitem>
628      <listitem>
629       <para>
630  <function>do_unpack()</function>, which builds the working directory
631    and unpacks all files
632       </para>
633      </listitem>
634      <listitem>
635       <para>
636  <function>do_patch()</function>, which applies the patches
637       </para>
638      </listitem>
639      <listitem>
640       <para>
641  <function>do_configure()</function>, which runs the configure script
642       </para>
643      </listitem>
644      <listitem>
645       <para>
646  <function>do_compile()</function>, which basically calls make
647       </para>
648      </listitem>
649      <listitem>
650       <para>
651  <function>do_stage()</function>, which installs library and header
652    files in the cross build environment for subsequent builds
653       </para>
654      </listitem>
655      <listitem>
656       <para>
657  <function>do_install()</function>, which installs the built files
658    into a special packaging area
659       </para>
660      </listitem>
661      <listitem>
662       <para>
663  <function>do_package()</function>, which collects the files from
664    the packaging area and creates (possibly several) packages
665       </para>
666      </listitem>
667    </itemizedlist>
668    </para>
669    <para>
670 All these tasks can be overwritten: in the kernel package example above
671 the <function>do_configure()</function> is redefined to run make with
672 a special target, and in the inherited <classname>autotools</classname> class
673 for this example the <function>do_configure()</function> is redefined to
674 add a <command>autoreconfig</command>
675 run to rebuild the configure script before the actual configure.
676    </para>
677  </sect2>
678
679  <sect2>
680  <title>Own Software</title>
681    <para>
682 For own software projects it is possible also to use the
683 <command>auto</command>-tools and <command>configure</command> to create
684 the makefiles.  But this requires some familiarity
685 with those tools and is not really necessary.  A standard makefile will
686 suffice, if some simple rules are observed:
687    <itemizedlist mark='bullet'>
688      <listitem>
689       <para>
690  don't use fix pathnames for include, library and install directories,
691    use variables for those directories.
692       </para>
693      </listitem>
694      <listitem>
695       <para>
696  use variables for all building commands (including <command>ar</command>
697 and <command>nm</command>, if used).
698       </para>
699      </listitem>
700      <listitem>
701       <para>
702  provide an <varname>install</varname> target.
703       </para>
704      </listitem>
705    </itemizedlist>
706    </para>
707    <para>
708 So, a makefile for the standard "Hello, World" example would look like this:
709 <programlisting>
710 CC = arm-linux-gcc
711 LD = arm-linux-ld
712 CXX = arm-linux-g++
713 INSTALL = install
714
715 prefix = ""
716 bindir = $(prefix)/usr/bin
717
718 TARGETS = hello
719
720 all: $(TARGETS)
721
722 hello: hello.cxx
723         $(CXX) $(CXXFLAGS) -o $@ $<
724
725 clean:
726         rm -f *.o $(TARGETS) *~
727
728 install:
729         $(INSTALL) hello $(bindir)
730
731 </programlisting>
732    </para>
733    <para>
734 The next decision to make is how to provide the source code:
735 it might either be available through some download mechanism, possibly
736 from a local CVS server, or it might be added as a local tarball to the
737 package file.
738    </para>
739    <para>
740 Based on that, the actual package recipe file is pretty simple:
741 <programlisting>
742 DESCRIPTION = "Hello world example"
743 SECTION = "base"
744 LICENSE="BSD"
745 MAINTAINER = "Me &lt;me@myname.org>"
746
747 PR = "r0"
748
749 SRC_URI = "file://hello-${PV}.tar.gz"
750
751 # just don't do any configuring
752 do_configure() {
753 }
754 </programlisting>
755    </para>
756    <para>
757 The recipes shown here are all pretty simple.  But actually 90% of
758 the recipes in OpenEmbedded are not much more complex.  And for
759 more complex packages normally some recipes already exist, if not
760 for exactly the wanted package then for a similar one.
761    </para>
762    <para>
763 And for the really complicated cases the OpenEmbedded developers
764 on the mailing list are always helpful.
765    </para>
766  </sect2>
767 </sect1>
768
769
770 <sect1 id="conclusion">
771 <title>Conclusion</title>
772  <para>
773 Most embedded Linux systems currently follow the full image approach:
774 if something changes, the complete image is rebuilt and deployed.
775  </para>
776
777  <para>
778 An embedded Linux distribution that provides a package system
779 follows a different approach: the original image provides only
780 a base system that is augmented incrementally by separate packages.
781  </para>
782
783  <para>
784 OpenEmbedded provides not only such a package system, but also the
785 tools to build these packages, i.e. the BitBake build tools
786 and all the metadata in form of predefined classes for most
787 common tasks for building an embedded Linux distribution.
788  </para>
789
790  <para>
791 And OpenEmbedded comes with lots of ready-to-use package recipes
792 for Open Source tools, libraries and applications.
793  </para>
794
795  <para>
796 But OpenEmbedded has also drawbacks:
797 It is quite complex and though this complexity is often hidden
798 in the provided classes, it is sometimes necessary to understand
799 that complexity.  And though most package recipes are quite simple,
800 even these simple things must be learned, and documentation is a bit scarce.
801 But the OpenEmbedded developers on the mailing list are generally
802 friendly and willingly provide some pointers to solve simple
803 and complex tasks.
804  </para>
805
806  <para>
807 Another drawback is the amounts of resources required to build
808 OpenEmbedded: to build a basic distribution including a GUI
809 takes several hours; to build everything takes nearly two
810 days on a Pentium M @ 2GHz.  And it takes about 30GHz disk space.
811  </para>
812
813  <para>
814 A last drawback is the SCM monotone used by OpenEmbedded:
815 pulling and updating is quite slow.
816  </para>
817
818  <para>
819 Some of these drawbacks are just due to the fact that OpenEmbedded
820 now provides a huge repository of recipes: to build one package
821 and its dependencies, OpenEmbedded must parse all recipes to know
822 which recipe provides what, and with more than 3000 recipes this
823 takes some time.  But the OpenEmbedded developers are aware especially
824 of the performance problems (they are bitten themselves most by them)
825 and try to solve at least some of them.
826  </para>
827 </sect1>
828
829  <bibliography>
830   <title>References</title>
831   <biblioentry id="OpenEmbeddedBib">
832    <title>OpenEmbedded Homepage</title>
833    <bibliomisc>
834     <ulink url="http://www.openembedded.org/">
835 http://www.openembedded.org/
836     </ulink>
837    </bibliomisc>
838   </biblioentry>
839
840   <biblioentry>
841    <title>Developer Documentation</title>
842    <bibliomisc>
843     <ulink url="http://oe.handhelds.org/cgi-bin/moin.cgi">
844 http://oe.handhelds.org/cgi-bin/moin.cgi
845     </ulink>
846    </bibliomisc>
847   </biblioentry>
848
849   <biblioentry>
850    <title>OpenEmbedded recipe hints</title>
851    <bibliomisc>
852     <ulink url="http://oe.handhelds.org/cgi-bin/moin.cgi/bb_20file">
853 http://oe.handhelds.org/cgi-bin/moin.cgi/bb_20file
854     </ulink>
855    </bibliomisc>
856   </biblioentry>
857
858   <biblioentry>
859    <title>BitBake manual</title>
860    <bibliomisc>
861     <ulink url="http://bitbake.berlios.de/manual/">
862 http://bitbake.berlios.de/manual/
863     </ulink>
864    </bibliomisc>
865   </biblioentry>
866
867   <biblioentry>
868    <title>iPKG</title>
869    <bibliomisc>
870     <ulink url="http://www.handhelds.org/moin/moin.cgi/Ipkg">
871 http://www.handhelds.org/moin/moin.cgi/Ipkg
872     </ulink>
873    </bibliomisc>
874   </biblioentry>
875
876   <biblioentry>
877    <title>OpenEmbedded monotone hints</title>
878    <bibliomisc>
879     <ulink url="http://oe.handhelds.org/cgi-bin/moin.cgi/MonotonePhraseBook">
880 http://oe.handhelds.org/cgi-bin/moin.cgi/MonotonePhraseBook
881     </ulink>
882    </bibliomisc>
883   </biblioentry>
884
885 </bibliography>
886
887 </article>
888