CDT/Obsolete/BuildModel61

The CDT Build System Take 2

This is an attempt at taking a step back and mapping out what the CDT build system should be given all the requirements of the day and in an effort to simplify the existing system.

The Model

These are the core classes that define the CDT build model.

Target Platform

The target platform describes the execution environment that the build output is intended to run on. Different target platforms use different tool chains and produce different kinds of build targets. They may also used different builder.

Tool

A tool is a process that takes input targets and produces output targets. The targets can be resources or pseudo targets. Build Targets are selected from the collection of output targets. Pseudo input targets must also be output targets somewhere in the build. The targets are used to build up a dependency graph that is used to decide which tools to run in what order.

Tools have properties that control options in the behavior of the tool. Tools may be external utilities and the properties serve to generate command lines. Tools may also be internal utilities, although these can not be called from external builders (and probably should be discouraged or this ability dropped).

Tools have error parsers that are used to create markers from the output at build time to highlight warnings and errors in the code found by the tools.

Tool Chain

Is the collection of tools used for a given build. A tool chain supports a given Target Platform. Predefined tool chains can be reused at project creation time. Tools can be added by the user, or automatically based on the resources in the project (e.g. a code generator for model files).

Builder

The builder is the component responsible for doing the build when Eclipse calls for one. The builder could call an external utility or utilities to do the build, or could be an internal builder that calls tools directly. The builder may also wish to generate files to the filesystem to manage the build as changes are made to the resources or the build settings.

Builders may or may not support different capabilities of tools. For example, external builders that take care of which tools to call and with what options would not use the tool properties. The build UI need to be able to adapt to that and hide the capability to set tool options. Also the build setting storage should not store unnecessary information in these scenarios either.

Build Target

This is the end result of the build. Generally there is only one, but there could be more if the builder supports that. The build target can be a resource or a pseudo target. It should be possible to model 'make' targets with this class.

Configuration

A configuration is a mapping of Builder, Build Target, and Tool Chain. Tools option settings are per configuration. Also files and folders can be excluded from the build in a given configuration of the builder supports that. Predefined configurations can be reused at project creation time.

Templates

Templates are used to prepopulate the build settings and generate initial files for different kinds of project.

Examples

Here are examples of how the build model would be used in real life.

Windows MinGW (Wascana)

We would like to limit external dependencies in this environment so the internal builder would be used.

The tool chain selects the MinGW gcc compilers and binutils.

Build targets include "Executable", "DLL", and "Library".

Predefined configurations for "Debug" and "Release" would be reused at project creation time.

Templates would be defined for Executables that use the various libraries shipped as part of Wascana. The template may even prompt the users to install the libraries.