eCos is a component architecture. The system comes as a number of packages which can be enabled or disabled as required, and new packages can be added as they become available. Unfortunately, the packages are not completely independent: for example the µITRON compatibility package relies almost entirely on functionality provided by the kernel package, and it would not make sense to try to build µITRON if the kernel was disabled. The C library has fewer dependencies: some parts of the C library rely on kernel functionality, but it is possible to disable these parts and thus build a system that has the C library but no kernel. The Configuration Tool has the capability of checking that all the dependencies are satisfied, but the command line tools do not currently have these capabilities, so it is possible to produce configurations that will not build or (conceivably) that will build but not run. Developers should be aware of this and take appropriate care.
By default, pkgconf.tcl will enable all packages that are appropriate for the target architecture and platform, and it will list these packages when it generates the build tree:
$ tclsh BASE_DIR/pkgconf.tcl --target=mn10300 --platform=stdeval1 Generating build tree. Component repository is /usr/local/ecos-1.2.1/packages Build tree is /home/ecos_user/ecos-work Install directory is /home/ecos_user/ecos-work/install Architecture mn10300, platform stdeval1, startup ram. Processing package hal/common/v1_2_1 Processing package infra/v1_2_1 Processing package kernel/v1_2_1 Processing package compat/uitron/v1_2_1 Processing package language/c/libc/v1_2_1 Processing package language/c/libm/v1_2_1 Processing package error/v1_2_1 Processing package io/common/v1_2_1 Processing package io/serial/v1_2_1 Processing package hal/mn10300/arch/v1_2_1 Processing package hal/mn10300/stdeval1/v1_2_1 Processing package devs/wallclock/v1_2_1 Processing package devs/watchdog/v1_2_1 Generating install directory /home/ecos_user/ecos-work/install Generating miscellaneous files. Generating toplevel makefile. Generating save file. The Build tree is ready. |
The common HAL package and the eCos infrastructure must be present in every configuration. In addition, it is always necessary to have one architectural HAL package and one platform HAL package: in the above example these are hal/mn10300/arch/v1_2_1 and hal/mn10300/stdeval1/v1_2_1 respectively. The remaining packages are optional, and can be disabled as required.
Some packages are inappropriate for a given target. For example, the package hal/mips/arch/v1_2_1 contains the HAL code for the MIPS CPU family. This package is clearly inappropriate if the target hardware does not have a MIPS processor, and it will not be in the configuration.
The application may not require all of the packages; for example, it might not need the µITRON compatibility package, or the floating point support provided by the math library. There is a slight overhead when eCos is built because the packages will get compiled, and there is also a small disk space penalty. However, any unused facilities will get stripped out at link-time, so having redundant packages will not affect the final executable.
If it is necessary to disable a package anyway, this should be done on the pkgconf.tcl command line with the --disable argument. For example, to generate a build tree with the µITRON package disabled, use the following command line:
$ tclsh BASE_DIR/pkgconf.tcl --target=mn10300 --disable-uitron |
The word following --disable- should be the name of the package or one of its aliases. To get details of all of the packages that are available the --packages argument can be passed to pkgconf.tcl.
$ tclsh BASE_DIR/pkgconf.tcl --packages |
The output includes the full name of the µITRON package, CYGPKG_UITRON, and two aliases. Any of these can be used, so the following commands are equivalent:
$ tclsh BASE_DIR/pkgconf.tcl -target=TARGET --disable-CYGPKG_UITRON $ tclsh BASE_DIR/pkgconf.tcl -target=TARGET "--disable-uITRON compatibility" $ tclsh BASE_DIR/pkgconf.tcl -target=TARGET --disable-uitron |
Most users will probably pick the last of these commands, because it’s the simplest.
If a package is disabled by default but should still be part of the configuration then it can be enabled explicitly using the --enable argument, for example:
$ tclsh BASE_DIR/pkgconf.tcl --target=mn10300 --enable-hal_mips |
A more rational use for the --enable argument would be to reenable a package in an existing configuration. This is discussed in more detail in the next section.
The output of pkgconf.tcl --packages will also list the versions of each package that are available. The eCos component repository has been designed so that multiple versions of a package can co-exist in one directory hierarchy. For example, it is possible to have versions of the kernel corresponding to the last release, the current release, and an experimental snapshot, all in the same tree. This means that it is relatively straightforward to switch between the experimental snapshot and the stable release version. It is also possible to use the same component repository for different projects: if a product is close to being released then it is usually a good idea to stick with the same versions of all the packages that have been used throughout the development, rather than updating to the latest release. Developers should be aware that this versioning scheme also has disadvantages, and should consult Chapter 8 for more details.
By default, when pkgconf.tcl is used to generate a build tree it will select the latest versions of all the packages. Details of the versions will be shown as part of the pkgconf.tcl output — the final directory listed for each package that gets processed corresponds to the version that has been selected. It is possible to override this on the command line on a per-package basis. For example, the following command would specify a particular version of the kernel:
$ tclsh BASE_DIR/pkgconf.tcl --target=mn10300 --kernel-version=ss19981130 |
There is no support for selecting a particular version that should be applied to all packages. In the long term such a facility would not make sense since different packages will be supplied by different vendors and they will have very different release cycles.