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/v1.1/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/v1.1/src; 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/v1.1/src/sync directory in the component repository to kernel/v1.1/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 it is possible to 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 the modified version of the sources can be discarded completely.
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/v1.1/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.
Configuration header files, for example kernel/v1.1/include/pkgconf/kernel.h, are a bit more complicated still. These files are intended to be edited by users so generally it is not possible for the build system to just copy across the modified version in the component repository. For a temporary change to such a header file there is no need to edit the master version in the component repository: there is already a copy of the header file in the build tree's pkgconf directory, and this copy exists specifically so that users can edit it. If you want to make permanent changes to such a header file you are responsible for manually updating the version in the build tree's pkgconf directory. The update will not happen automatically because any such update runs the risk of discarding your edits.
The final files located in the component repository are package makefiles that define the files which make up that package. In the component repository, these files have the name PKGconf.mak. When a build tree is generated pkgconf.tcl will copy these files from the component repository to the build tree and rename them to makefile. Since some users may edit the makefiles in the build tree, it is not possible for the build system to update these files automatically if the master version in the component repository changes. Instead, any such changes will have to be manually propagated into the build tree.
It should be noted that future releases of eCos are likely to involve major changes to the way that configuration header files and package makefiles are handled. Therefore, any changes made to these files may not carry across to the next release of the system.