![](https://csdnimg.cn/release/download_crawler_static/2266629/bg13.jpg)
Chapter 2. Package Organization
1. The component repository. This is where all the package source code is held, along with CDL scripts,
documentation, and so on. For build purposes a component repository is read-only. Application developers
will only modify the component repository when installing or removing packages, via the administration
tool. Component writers will typically work on just one package in the component repository.
2. The build tree. Each configuration has its own build tree, which can be regenerated at any time using the
configuration’s ecos.ecc savefile. The build tree contains only intermediate files, primarily object files.
Once a build is complete the build tree contains no information that is useful for application development
and can be wiped, although this would slow down any rebuilds following changes to the configuration.
3. The install tree. This is populated during a build, and contains all the files relevant to application devel-
opment. There will be a lib sub-directory which typically contains libtarget.a, a linker script, start-up
code, and so on. There will also be an include sub-directory containing all the header files exported by
the various packages. There will also be a include/pkgconf sub-directory containing various configura-
tion header files with #define’s for the options. Typically the install tree is created within the build tree,
but this is not a requirement.
The build process involves the following steps:
1. Given a configuration, the component framework is responsible for creating all the directories in the build
and install trees. If these trees already exist then the component framework is responsible for any clean-ups
that may be necessary, for example if a package has been removed then all related files should be expunged
from the build and install trees. The configuration header files will be generated at this time. Depending
on the host environment, the component framework will also generate makefiles or some other way of
building the various packages. Every time the configuration is modified this step needs to be repeated,
to ensure that all option consequences take effect. Care is taken that this will not result in unnecessary
rebuilds.
Note: At present this step needs to be invoked manually. In a future version the generated makefile
may if desired perform this step automatically, using a dependency on the ecos.ecc savefile.
2. The first step in an actual build is to make sure that the install tree contains all exported header files. All
compilations will use the install tree’s include directory as one of the places to search for header files.
3. All source files relevant to the current configuration get compiled. This involves a set of compiler flags
initialized on a per-target basis, with each package being able to modify these flags, and with the ability for
the user to override the flags as well. Care has to be taken here to avoid inappropriate target-dependencies
in packages that are intended to be portable. The component framework has built-in knowledge of how
to handle C, C++ and assembler source files — other languages may be added in future, as and when
necessary. The compile property is used to list the files that should get compiled. All object files end up in
the build tree.
4. Once all the object files have been built they are collected into a library, typically libtarget.a, which
can then be linked with application code. The library is generated in the install tree.
5. The component framework provides support for custom build steps, using the make_object and make
properties. The results of these custom build steps can either be object files that should end up in a library,
or other files such as a linker script. It is possible to control the order in which these custom build steps
take place, for example it is possible to run a particular build step before any of the compilations happen.
13