The eCos Component Writer's Guide
Prev | Chapter 3. The CDL Language | Next

# Updating the ecos.db database

The current implementation of the component framework requires that all packages be present in a single component repository and listed in that repository's ecos.db database. This is not generally a problem for application developers who can consider the component repository a read-only resource, except when adding or removing packages via the administration tool. However it means that component writers need to do their development work inside a component repository as well, and update the database with details of their new package or packages. Future enhancements to the component framework may allow new components to be developed outside a repository.

Like most files related to the component framework, the ecos.db database is actually a Tcl script. Typical package entries would look like this:

    package CYGPKG_LIBC {
    	alias		{ "C library" libc clib clibrary }
    	directory	language/c/libc
    	script		libc.cdl
            description  "
    This package enables compatibility with the ISO C standard - ISO/IEC
    9899:1990. This allows the user application to use well known standard
    C library functions, and in eCos starts a thread to invoke the user
    function main()"
    }

    package CYGPKG_IO_PCI	{
    	alias		{ "PCI configuration library" io_pci }
    	directory	io/pci
    	script		io_pci.cdl
    	hardware
            description "
               This package contains the PCI configuration library."
    }

The `package` command takes two arguments, a name and a body. The name must be the same as in the `cdl_package` command in the package's top-level CDL script. The body can contain the following five commands: `alias`, `directory`, `script`, `hardware` and `description`.

`alias`

  Each package should have one or more aliases. The first alias is typically used when listing the known packages, because a string like `C library` is a bit easier to read and understand than `CYGPKG_LIBC`. The other aliases are not used for output, but are accepted on input. For example the ecosconfig command-line tool will accept `add libc` as an option, as well as `add CYGPKG_LIBC`.

`directory`

  This is used to specify the location of the package relative to the root of the component repository. It should be noted that in the current component framework this location cannot be changed in subsequent releases of the package: if for some reason it is desirable to install a new release elsewhere in the repository, all the old versions must first be uninstalled; the database cannot hold two separate locations for one package.

`script`

  The `script` command specifies the location of the package's top-level CDL script, in other words the one containing the `cdl_package` definition. If the package follows the directory layout conventions then this script will be in the `cdl` sub-directory, otherwise it will be relative to the package's top-level directory. Again once a release has been made this file should not change in later releases. In practice the top-level script is generally named after the package itself, so changing its name is unlikely to be useful.

`hardware`

  Packages which are tied to specific hardware, for example device drivers and HAL packages, should indicate this in both the `cdl_package` command of the CDL script and in the database entry.

`description`

  This should give a brief description of the package. Typically the text for the description property in the `cdl_package` command will be re-used.

> Note: Most of the information in the ecos.db file could be obtained by a relatively simple utility. This would be passed a single argument identifying a package's top-level CDL script. The directory path relative to the component repository root could be determined from the filename. The name, `description` and `hardware` fields could be obtained from the script's `cdl_package` command. The display property would supply the first alias, additional aliases could be obtained by extending the syntax of that property or by other means. Something along these lines may be provided by a future release of the component framework.

Currently the ecos.db database also holds information about the various targets. When porting to a new target it will be necessary to add information about the target to the database, as well as the details of the new platform HAL package and any related packages.

Prev | Home | Next
Interfaces | Up | The Build Process