Chapter 2. Package Organization

Table of Contents
Packages and the Component Repository
Package Versioning
Package Contents and Layout
Making a Package Distribution

For a package to be usable in the eCos component framework it must conform to certain rules imposed by that framework. Packages must be distributed in a form that is understood by the component repository administration tool. There must be a top-level CDL script which describes the package to the component framework. There are certain limitations related to how a package gets built, so that the package can still be used in a variety of host environments. In addition to these rules, the component framework provides a number of guidelines. Packages do not have to conform to the guidelines, but sticking to them can simplify certain operations.

This chapter deals with the general organization of a package, for example how to distinguish between private and exported header files. Chapter 3 describes the CDL language. Chapter 4 details the build process.

Packages and the Component Repository

All eCos installations include a component repository. This is a directory structure for all installed packages. The component framework comes with an administration tool that allows new packages or new versions of a package to be installed, old packages to be removed, and so on. The component repository includes a simple database, maintained by the administration tool, which contains details of the various packages.

Each package has its own little directory hierarchy within the component repository. Keeping several packages in a single directory is illegal. The error, infra and kernel packages all live at the top-level of the repository. For other types of packages there are some pre-defined directories: compat is used for compatibility packages, which implement other interfaces such as µITRON or POSIX using native eCos calls; hal is used for packages that port eCos to different architectures or platforms, and this directory is further organized on a per-architecture basis; io is intended for device drivers; language is used for language support libraries, for example the C library. There are no strict rules defining where new packages should get installed. Obviously if an existing top-level directory such as compat is applicable then the new package should go in there. If a new category is desirable then it is possible to create a new sub-directory in the component repository. For example, an organization planning to release a number of eCos packages may want them all to appear below a sub-directory corresponding to the organization's name — in the hope that the name will not change too often. It is possible to add new packages directly to the top-level of the component repository, but this should be avoided.

The ecos.db file holds the component repository database and is managed by the administration tool. The various configuration tools read in this file when they start-up to obtain information about the various packages that have been installed. When developing a new package it is necessary to add some information to the file, as described in the Section called Updating the ecos.db database in Chapter 3. The templates directory holds various configuration templates.

Note: Earlier releases of eCos came with two separate files, targets and packages. The ecos.db database replaces both of these.

Caution

The current ecos.db database does not yet provide all of the information needed by the component framework. Its format is subject to change in future releases, and the file may be replaced completely if necessary. There are a number of other likely future developments related to the component repository and the database. The way targets are described is subject to change. Sometimes it is desirable for component writers to do their initial development in a directory outside the component repository, but there is no specific support in the framework for that yet.