Integration overview

This section describes the build process for ARM platforms.

Configuration

Platform builds are done using the Matrix tool using configuration files to control the build process. The configuration files enable:

• Selection of components
  • The idea is to only select and build components which are needed
  • It is possible to specify exact versions of individual components
• Specifying the target board
  • Default GCC options, etc.
• Configuration of the location of the remote repositories
  • Builds are normally using several repository locations, e.g. one for general components and another for custom UI applications
• Specifying global build options
  • E.g. Debug build

Example project structure

Many config files come from auxiliary Git repositories. generic provides software components which form the contents of the project; the project selects the parts it wants: in the case of example-project, all component suites and miscellaneous components are selected. sb1-support integrates the build process with Scratchbox 1 and provides the C/C++ runtime environment for the platform.

When building the project for a specific hardware platform, the necessary configuration is read from an optional repository. Hardware support repositories are called variant repositories; it makes sense to enable only one at a time. A variant usually defines a board configuration and additional components which enable hardware features at runtime. The components are implicitly picked up by the project because they are provided in the "essential" suite.

See the Kaze project structure for comparison and Configuration reference for more information.

Component repositories

The build system uses GIT to pull sources of each components. GIT was chosen because its ability to synchronize with separate source repositories. Repositories can reside anywhere, so long as they can be accessed.

Repositories can contain source code or binaries. When integrating source code, the build system fetches the sources and builds the images which then get installed in the target file-system under Scratchbox. Binaries in the repositories are just copied to the appropriate places.

Each component needs to have one repository containing the source code and another repository containing the meta-data required to build the component. The meta and source repositories can reside in different locations. The meta data should not contain patches for the source of the components. If fixes are needed by a component, these should be submitted to the original project maintainer to be integrated upstream. In some cases, components may need to be replicated in new repositories:

• if the original component is not maintained in a GIT repository
• as a temporary solution before getting changes back into the original project
• for changes which may never be integrated in the origin project

See Matrix documentation for more information.

Root images

Results of the build process include:

• Device rootfs tar file
  • A tar package containing the target binaries
  • Can be installed as is (e.g. a memory stick, a memory card or on a NFS server)

• Developer rootfs tar file (rootstrap)
  • A tar package containing the development files
  • It is intended for the platform developers

• Device flash image
  • E.g. a JFFS2 image