The Linux Target Image Builder (LTIB) user interface is much like the kernel configuration tool, which, although familiar to systems-level engineers, can be confusing if you're new to Linux. LTIB is accommodating in that it does its best to verify the environment before starting a build and lets you know about corrective actions before starting a 3-hour build process. One of the complaints about LTIB is that the first time it runs, it downloads the entire set of packages that it could use in a distribution. This is a mixed blessing in that after the packages are on the system, the host doesn't need to be attached to the network in order to get a build running. Another advantage of the big download is that you can put the entire directory into a code librarian and check it out on a build machine for easy platform scripting. The second complaint is that the software doesn't build toolchains but downloads the binaries and installs them on the system. This is also somewhat advantageous in that building a toolchain requires at least an hour on a very fast computer and, due to the patches and configuration dependencies, is an operation that frequently fails.
LTIB provides the sources for the toolchain it downloads; it just doesn't build the toolchain during the build process running on the host machine. One great advantage of LTIB is that it builds a JFFS2 image containing the root file system, ready to be burned on to a flash partition, as part of the build. Along with the self-contained nature of the project, LTIB is a great tool if you want or need to automate your platform build. LTIB is an RPM-based system. This means it uses source RPM files to do the build, and integrating a package into LTIB means learning how to create RPM packages. Creating a source RPM build for an application isn't difficult; but for some reason, it scares some users away from fully taking advantage of LTIB. Instead of having the software build your application from an RPM as part of the LTIB build, you can post-process the file system, adding the application and making any final changes.
Buildroot is a project that helps you create root file systems and toolchains that use uClibc and BusyBox, a small C Library, and basic set of root file system tools. Buildroot grew out of the BusyBox and uClibc projects, two of the most commonly used pieces of software for embedded projects. Because this tool integrated both of these projects, it serves as a great starting point for creating a Linux distribution for a project. Like LTIB, Buildroot uses an interface that's similar the tool used to configure the kernel. Although this is comforting for a system-level engineer, the tool can be confusing if you're a new engineer. The primary problem with this tool is that you have to keep track of where you are; after you use the software for a few minutes, nearly every page looks the same, and picking the correct options becomes tedious. Buildroot configures an entire development environment—kernel, root file system, and toolchain— which means you need to configure the options for these complex projects before starting a build. There are literally hundreds of options to configure, and the sheer number of items makes the process mildly tedious. For some boards, default configuration files configure the build with the right settings. Unfortunately, there aren't many of these default configuration files, so the chances of one matching the board you're using are fairly low. Buildroot uses tar files as its package system and uses a collection of make files to configure the software before building.
This implementation is easy to understand if you've used make in the past for moderately complex projects. Each package has a .mk file containing the make rules necessary to download, configure, build, and clean the package and a Config.in that is used by the configuration tool. After you select the configuration options, you invoke make, and the build process starts running.
The OpenEmbedded project got started as the build infrastructure for the Sharp Zaurus hand-held computer that ran Linux. The OpenEmbedded system uses the BitBake (more on that later) system for describing packages patches and their interrelationships. Formally, the project views the BitBake system as the build infrastructure for metadata supplied by the OpenEmbedded project. OpenEmbedded, like the other distribution builders, builds a kernel, toolchain, and root file system. The BitBake software has the notion of recipes that it uses to download and cross-build packages; you can use this software to build other software as well. Unlike many project, OpenEmbedded recommends that you check out the project from a source code repository. To get updates, refresh the project's files from source control. You may find this disorienting; or it may leave you with the impression that the software isn't “done.” Because of the rapid changes to OpenEmbedded and the fact that it's implemented in Python plus shell scripts (meaning there's no separate compilation step for you to perform), this model works well. The BitBake model requires an earnest learning commitment. The software ships with an example configuration file that you can use to create a simple build. However, the software doesn't have a UI, so figuring out what it can do requires that you read the documentation. The OpenEmbedded site contains quite a bit of information, but it seems to operate under the assumption that you're already familiar with the technology. The OpenEmbedded software models the software build into the following parts:
• Distribution: This distribution contains a list of packages for the root file system and the kernel to use for the build. It also contains the settings for the root file system type.
• Machine: The machine data describes the hardwarethe distribution will be running on: for example, the size of the flash partitions or the name device for the serial console. The machine also has an associated set of packages that address features specific to that machine.
• Package recipe: The metadata part of the OpenEmbedded project is a library of BitBake recipes. A recipe specifies where to download a package, what patches to apply, and when and how to install the package in the target machine's root file system.
OpenEmbedded is very different from other build systems since it's object-oriented in nature. At its core, BitBake uses the recipe to instantiate the appropriate class necessary to build a package. The object-oriented approach makes sense when you're building packages because the overall steps are the same for every package, but the particulars for any step for a given package may be unique. By using classes intelligently, the authors don't repeat code when a group of packages all have the same processing for certain steps in the process. The notion of inheritance is also writ large on the configuration files used by OpenEmbedded. A file for a distribution likely includes many other files shared by other distributions. This structure has benefits in that one change can be easily applied to many distributions, but it also means the details are hidden if you're a novice user. If you've slogged through other class libraries, you'll have the same feeling when learning the ins and outs of OpenEmbedded's data files.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Setty J. at 01242010
1. The resemblance between the GCC compiler and the kernel in Linux
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.