CDT/Obsolete/BuildModel61

Latest Thoughts

I'll start with how the new project wizard should look like. In many ways, that wizard drives what the build model should look like.

To create new projects you need to define the following for build:

• Target Platform. Are we Windows mingw or cygwin, Linux, Linux Cross, or some ISV provided target
• Build system. Is it make, managed make, autoconf, user defined, or some ISV provided build system
• Toolchain. Is it gcc, Intel, IBM, Wind River, gcc cross.
• Build Target. Depending on what the above supports. e.g. Exec, shared lib, kernel module.
• Template. Precanned starter code for different project types. Can also customize build files.
• Option Set. debug, profiling, optimized

For each option set selected, a build configuration is created. Additional ones can be created at any time after the project is created.

Older Stuff

Hi, Doug here. I'm going to document the vision I have for CDT's build model. My hope is that we can discuss this, finalize on the vision, and start working towards it.

A full build model would be all encompassing. It would serve the following clients:

• Builders, to generate build files for an external builder, or to feed the internal builder
• Parser, the scanner info falls into the build model
• Debugger, to figure out how which debugger to run given the target of the build.

The build has to support host toolchains, cross toolchains, and remote toolchains. We need the concept of "target" in the build system to determine what platform the build is targeting.

The fundamental concept of the build model is that of a Tool with options. Tools translate input files to output files. It is very similar to a pattern rule in Make. The build system determines which tools to run to produce a given build output. External builders generally do that for you. The internal builder can emulate that.

We've had numerous requests to support multiple build outputs per build run. We'll need to have that flexibility in the build model.

Configurations specify the target platform, build outputs, and the tools and option settings for a build. Multiple configurations are allowed per project, i.e., a project has a number of build configurations.

We need to separate the auto-generated UI from the build model. We need to do the same for command-line generation.

We also need to separate the concept of toolchain. Toolchains are more a starting collection of tools that feed into configuration building. You can add tools, like parser generators, to the list of tools to run during a configuration build.

We need to define a minimum build model required for all the clients. In particular, a minimal build system to allow vendors to build their own builders, while still satisfying the needs of the other clients.

Interfaces will be defined for clients. Abstract classes that implement those interfaces will be defined for ISVs to provide default behavior.

For the external Make builder, we need to support Makefiles that can be checked into source control. As such, they should only change when their contents change, e.g. when a resource is added or deleted, or when a build setting is changed. The Makefile would not be marked derived. In fact, in theory, it should be possible to store the build settings in it, but that may be a stretch.