Overview

The ChorusOS operating system is made up of components that you can build separately and combine in a ChorusOS system image, containing exactly what you need. The source delivery of ChorusOS offers default profiles that can be customized to build the system that fits your requirements.

The following table describes the content of the standard components. You may add components to these when you add functionality to the ChorusOS operating system with the source delivery.

Table 2-1 ChorusOS operating system Components

Component Identifier	Location after Installation	Description
BSP	source_dir/nucleus/bsp/family/target	Board support files
CVM	source_dir/cvm	JavaTM compliant virtual machine
DRV	source_dir/nucleus/bsp	Drivers
EXAMPLES	source_dir/opt/examples	Example applications
OS	source_dir/os	POSIX compatible system; file system, networking support
NUCLEUS	source_dir/nucleus	Microkernel and related files, target family profiles
X11	source_dir/opt/X11	X support

When you build a ChorusOS system, it is never built within the source tree. You must configure a build tree in a separate build_dir. In addition, the system components do not necessarily correspond to directories in source file tree. Each component you build will have its own directory structure contained in a build-component its own directory structure contained in a build-component directory in build_dir.

The structure in these build-component/ directories differs according to the component and the build method used to construct them. When building a ChorusOS system there are two different build methods. Each applies to a specific set of the standard components:

• A proprietary build method is used to build the NUCLEUS and OS components. This method uses the tools mkmerge, mkmk and make to build the component in a merged tree.

• The imake build method is used for the BSP, DRV and EXAMPLES components, which builds them in a "projected tree".

Building with the Proprietary Method (mkmk, mkmerge, make)

When you build a component using the proprietor method, the main difference is that the build directory merges the source files from different directories in the source tree to a merged build directory. These files are present in the build-component tree via symbolic links. The merged tree is created by the mkmerge tool.

All built files are in the directory in the build-component tree in the same location as the source link. This enables you to mix generic and specific source code, from different source tree directories, in the same component directory.

To recapitulate, the main tasks performed by a mkmk build are the following:

• The "all" makefile target in the Makefile.src of the component invokes mkmerge to build the merged tree

• The makefiles are built in the merged tree with the mkmk tool

• Finally, make is invoked to generate the object files, libraries and binaries

Building With Imake

When you build a component with imake, the structure of your component source is reproduced in your build-component directory. This is called a projected tree. This means that the build directory will contain a directory hierarchy that mirrors the source file tree.

Each directory contains a makefile that enables the component to be built from the component root. These makefiles are generated automatically from the Imake files contained in the component directory in the source. They are generated when you make your build environment.

In the build_dir component, source files are referenced in their original location in the source file tree. However, the built .o files are stored in the equivalent directory in the build-component tree.

To recapitulate, the main tasks performed by an Imake build are the following:

• The "all" makefile target of the Makefile.src file invokes ChorusOS MkMf, a wrapper over imake, to generate the root Makefile.

• The build tree is built recursively by the makefile target (standard imake profile)

• The "all" makefile target of the root Makefile performs a recursive build of objects (.o), libraries and binaries

For more information on these two build methods see "Build Management".