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.

Scanner Discovery

Scanner discovery is a service provided by the CDT to parse build output and extract tool options. Essentially, the build output parser works with the collection of tools defined in the tool chain to parse the build output.

The builder for a given configuration decides whether to use the service or not. If it does, the build output parser runs while the build output is incoming (not after) and adjusts the tool option settings on the fly.

Due to the amount of settings that could be gathered, care is taken to ensure the size of the information gathered is minimized. This is true whether you are using scanner discovery or not, but it is good to highlight here. Much of the complexity of the existing scanner discovery was a result of the effort to highly optimize size and to undo that complexity will require some of that optimization to be undone.

The existing scanner discovery also takes care of built-in calculations to provide complete scanner info. In this proposal, handling of built-ins is passed off to Tools, which may or may not use the existing capability.

The scanner info provider moves through the build system eventually to the Tools themselves to provide the scanner info for a given resource. Scanner discovery no longer stores info directly into the project descriptors and is no longer an automous system that can respond to these queries. It is simply a service used by the builders.

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. The system is searched at known locations for the tool chain and sets the environment for the build to include them (as is done today).

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

Predefined configurations for "Debug" and "Release" would be reused at project creation time. (Note these are selected to be familiar for VisualStudio users).

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.

Linux Managed Make

To enable a cleaner integration with the library set on Linux (e.g. pkg-config based dependencies), we would use 'make' as the external build utility. We would generate Makefiles as resources are added/deleted and as build settings change. This allows the Makefiles to be checked into source control and reused by external build systems.

The tool chain selects the built-in gcc compilers and binutils, i.e. they are expected to already be on the path.

Alternative tool chains my be defined, e.g. the Intel or IBM compilers.

Build targets are "Executable", "Shared Library", and "Static Library".

Predefined configurations for "Debug" and "Optimize". ("Optimize" is more familiar to gcc users).

Templates defined as with Wascana (some of them would be the same since it's a subset of the Linux libraries).

Autotools

Autotools would have it's own builder that would invoke the autotools and configure when necessary and finally 'make' on all builds.

Configurations would be defined for each build target generated by the configure script.

Templates could be defined to prepopulate the autotools conf files.

External Builder

In this scenario, the external builder to be used is a build setting. Nothing is known by the CDT on how this builder actually performs the build. This is the Standard Make system, currently Makefile Projects, that we've had all along. Despite the name, these actually had little to do with 'make' itself.

Configurations are defined to manage the environment and the external build command. Each different combination of these is a different configuration.

Scanner discovery is used to capture build settings. To satisfy scanner discovery, a tool chain must be defined for the current configuration.

Android NDK (Native)

This scenario is an extension of the External Builder scenario. A specialized wizard is used to add CDT support to an Android Java project.

The Android NDK would be defined as a target platform that is used both for the Android Java projects and straight CDT projects for creating libraries that are used by the Android projects.

A template is defined that sets up the source and output folders and generated the Makefile. The template would also associate the Android tool chain with the Configuration to support scanner discovery.