A source distribution of eCos consists of a number of packages, such as the kernel, the C library, and the µ ITRON subsystems. These are individually versioned in the tree structure of the source code, to support distribution on a per-package basis and to support third party packages whose versioning systems might be different. The eCos Package Administration Tool is used to manage the installation and removal of packages from a variety of sources with potentially multiple versions.
The presence of the version information in the source tree structure might be a hindrance to the use of a separate source control system such as CVS or SourceSafe ™. To work in this way, you can rename all the version components to some common name (such as "current") thus unifying the structure of source trees from distinct eCos releases.
The eCos build system will treat any such name as just another version of the package(s), and support building in exactly the same way. However, performing this rename invalidates any existing build trees that referred to the versioned source tree, so do the rename first, before any other work, and do a complete rebuild afterwards.
Package installation and removal is performed using the eCos Package Adminstration Tool. This tool is a Tcl script named ecosadmin.tcl which allows the user to add new eCos packages and new versions of existing packages to an eCos repository. Such packages must be distributed as a single file in the eCos package distribution format. Unwanted packages may also be removed from the repository using this tool. A graphical version of the tool is provided as part of the eCos Developer's Kit.
The graphical version of the eCos Package Administration Tool, provided as part of the eCos Developer's Kit, provides functions equivalent to the command-line version for those who prefer a Windows-based interface.
It may be invoked in one of two ways:
ProgramsRed Hat eCosPackage Administration Tool
)Administration
menu item
The main window of the tool displays the packages which are currently installed in the form of a tree. The installed versions of each package may be examined by expanding the tree.
Packages may be added to the eCos repository by clicking on the Add button. The eCos package distribution file to be added is then selected via a File Open dialog box.
Packages may be removed by selecting a package in the tree and then clicking on the Remove button. If a package node is selected, all versions of the selected package will be removed. If a package version node is selected, only the selected version of the package will be removed.
The ecosadmin.tcl script is located in the base of the eCos repository. Use a command of the following form under versions of UNIX:
$ tclsh ecosadmin.tcl <command>
Under Windows, a command of the following form may be used at the Cygwin command line prompt:
$ cygtclsh80 ecosadmin.tcl <command>
The following commands are available:
Adds the packages contained with the specified package distribution file to the eCos repository and updates the package database accordingly. By convention, eCos package distribution files are given the .epk suffix.
remove <package> [ --version=<version> ]
Removes the specified package from the eCos repository and updates the package database accordingly. Where the optional version qualifier is used, only the specified version of the package is removed.
Produces a list of the packages which are currently installed and their versions. The available templates and hardware targets are also listed.
Note that is is possible to remove critical packages such as the common HAL package using this tool. Users should take care to avoid such errors since core eCos packages may only be re-installed in the context of a complete re-installation of eCos.
The files in an installed eCos source tree are organized in a natural tree structure, grouping together files which work together into Packages. For example, the kernel files are all together in:
BASE_DIR /kernel/ v1_3_x /include/ BASE_DIR /kernel/ v1_3_x /src/ BASE_DIR /kernel/ v1_3_x /tests/
and µ ITRON compatibility layer files are in:
BASE_DIR /compat/uitron/ v1_3_x /include/ BASE_DIR /compat/uitron/ v1_3_x /src/ BASE_DIR /compat/uitron/ v1_3_x /tests/
The feature of these names which is of interest here is the v1_3_x near the end. If you start using eCos after the Version 1.2 release, you might see a different name here, e.g. v1_4 for version 1.4; if you received pre-release Beta versions you might have seen v0_2 or v0_3 for versions 0.2 and 0.3.
It may seem odd to place a version number deep in the path, rather than having something like BASE_DIR / v1_3_x /...everything...
or leaving it up to you to choose a different install-place when a new release of the system arrives.
There is a rationale for this organization: as indicated, the kernel and the µ ITRON compatibility subsystem are examples of software packages. For the first few releases of eCos, all the Red Hat packages will move along in step, i.e. Release 1.3.x will feature Version 1.3.x of every package, and so forth. But in future, especially when third party packages become available, it is intended that the package be the unit of software distribution, so it will be possible to build a system from a selection of packages with different version numbers, and even differing versioning schemes. A Tcl script ecosadmin.tcl is provided in the eCos repository to manage the installation and removal of packages in this way.
Many users will have their own source code control system, version control system or equivalent, and will want to use it with eCos sources. In that case, since a new release of eCos comes with different pathnames for all the source files, a bit of work is necessary to import a new release into your source repository.
One way of handling the import is to rename all the version parts to some common name, for example "current", and continue to work. "current" is suggested because ecosconfig recognizes it and places it first in any list of versions. In the future, Red Hat may provide a tool to help with this, or an option in the install wizard. Alternatively, in a POSIX shell environment (Linux or Cygwin on Windows) use the following command:
find . -name v1_3_x -type d -printf 'mv %p %h/current\n' | sh
Having carried out such a renaming operation, your source tree will now look like this:
BASE_DIR /kernel/current/include/ BASE_DIR /kernel/current/src/ BASE_DIR /kernel/current/tests/ ... BASE_DIR /compat/uitron/current/include/ BASE_DIR /compat/uitron/current/src/ BASE_DIR /compat/uitron/current/tests/
which is a suitable format for import into your own source code control system. When you get a subsequent release of eCos, do the same thing and use your own source code control system to manage the new source base, by importing the new version from
NEW_BASE_DIR /kernel/current/include/
The eCos build tool will now offer only the "current" version of each package; select this for the packages you wish to use.
Making such a change has implications for any build trees you already have in use. A configured build tree contains information about the selected packages and their selected versions. Changing the name of the "versioning" folder in the source tree invalidates this information, and in consequence it also invalidates any local configuration options you have set up in this build tree. So if you want to change the version information in the source tree, do it first, before investing any serious time in configuring and building your system. When you create a new build tree to deal with the new source layout, it will contain default settings for all the configuration options, just like the old build tree did before you configured it. You will need to redo that configuration work in the new tree.
Moving source code around also invalidates debugging information in any programs or libraries built from the old tree; these will need to be rebuilt.
Managing the Package Repository | ||
|---|---|---|