CDT/NewBuild/Standard

The New Build system provides uber flexibility by pruning down the build model to it's bare essentials required for the CDT features to work. One of the key focuses of the framework is to provide scanner info so that the CDT's parsers can properly parse the code when populating the index, providing content assist, semantic and syntactic colouring, etc.

Since it's simpler, we should be able to do a pretty good job of Standard build. It was a huge mistake to move standard build on top of the massive managed build framework. But it did teach us one thing. In order to enable CDT features when working with Standard Build, you need to know the ToolChain. Without it, scanner info is a big guess. With it, we can do a pretty good job of figure it all out.

The other important feature of Standard build that we too often forget about is the Make Targets feature. It facilitates running a build command with a set of arguments in a given directory of the project. This is very typical of how developers work when on the command line with large projects. Such projects often implement a recursive make system that lets them build at any point of the directory structure and do a scoped build.

One of the big issues with the current Make Targets View is that it's pretty hidden. It also replicates the directory hierarchy in the Project Explorer. You end up having to navigate two trees to get the job done. I guess this made sense at the time as the Make Targets view predates using the Common Navigator for the projects view. In theory we should be able to merge the two adding virtual nodes to the project hierarchy and menu items to create, delete, edit, and invoke Build Targets. (The other problem is assuming it only does Make Targets when they can run any command).

To integrate with scanner info, build targets need to have an associated toolchain. A default toolchain can be set at the project and preference levels.

One of the build targets can be pinned as the source of scanner info for a file in a project and/or the default action when the build project command is issued.

How do we support Standard Builds with the Launch Bar? It's not easy. Projects that use such freeform build systems do not allow for a reproducible pattern that we can use to derive the binary for a given Launch. And most such projects have multiple unrelated binaries. Here are some options:

- Use the existing paradigm of per binary launch configurations. Need to specify a Build Target for a given launch config. That gives us a toolchain that we can use to select Launch Targets that the toolchain supports. Problem, though is that we can't create the launch config until a build is done. But having said that, we do know what the last Build Target was before creating the executable and we can use that as a default.