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.