For many users, controlling the packages and
manipulating the available configuration options will be
sufficient to create an embedded operating system that meets
the application's requirements. However, since eCos is
shipped entirely in source form, it is possible to go
further when necessary: you can edit the eCos sources themselves. This requires some
understanding of the way the eCos build system works.
The most obvious place to edit the source code is directly
in the component repository. For example, you could
edit the file kernel/<version>/src/sync/mutex.cxx
to change the way kernel mutexes work, or possibly just to add some
extra diagnostics or assertions. Once the file has been edited,
it is possible to invoke make at
the top level of the build tree and the target library will be rebuilt
as required. A small optimization is possible: the build tree is
largely a mirror of the component repository, so it too will contain
a subdirectory kernel/<version>;
if make is invoked in this directory
then it will only check for changes to the kernel sources, which
is a bit more efficient than checking for changes throughout the component
repository.
Editing a file in the component repository is fine if this
tree is used for only one eCos configuration. If the repository
is used for several different configurations, however, and especially
if it is shared by multiple users, then making what may be experimental
changes to the master sources would be a bad idea. The build system provides
an alternative. It is possible to make a copy of the file in the
build tree, in other words copy mutex.cxx from
the kernel/<version>/src/sync directory
in the component repository to kernel/<version>/src/sync in
the build tree, and edit the file in the build tree. When make is
invoked it will pick up local copies of any of the sources in preference
to the master versions in the component repository. Once you have
finished modifying the eCos sources you can install the final version
back in the component repository. If the changes were temporary
in nature and only served to aid the debugging process, then you
can discard the modified version of the sources.
The situation is slightly more complicated for the header
files that a package may export, such as the C library’s stdio.h header
file, which can be found in the directory language/c/libc/<version>/include.
If such a header file is changed, either directly in the component
repository or after copying it to the build tree, then make must
be invoked at the top level of the build tree. In cases like this
it is not safe to rebuild just the C library because other packages
may depend on the contents of stdio.h.