 | build 3.0.0.201402161939 |
| build 3.0.0.201402161939 |
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.
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.
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.
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.
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.
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.