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.
Open Embedded uses two different source-control systems, which are sometimes called code librarians: Subversion (SVN) and Git (no known aliases). Both of these systems provide the same sort of functionality, keeping track of code changes from developers over time, but in very different ways. OpenEmbedded is actually two projects that work together, and each project is selected a different source-control system; that's OK, but it may be a little disorienting to new users.
Source of Information : Pro Linux Embedded Systems
No comments:
Post a Comment