Background

CDT's Core Build System, including CMake projects, uses the Launch Bar to select the launch mode, launch configuration/descriptor and Launch Target.
This provides considerably more flexibility than the traditional Managed Build System (MBS), but the workflow is less obvious to users who are familiar with the classic CDT model of:
select a project then Build / Run / Debug
In particular:

• the project selected in Project Explorer can differ from the project selected in the Launch Bar;
• the relationship between project selection, launch configuration, launch mode and Launch Target is not always obvious;
• a single CMake project may contain multiple executable targets, whereas the current Launch Bar workflow largely assumes a project-level launch descriptor;
• some Core Build configuration is stored in workspace state, making import into a new workspace less self-contained than MBS projects;
• configuration and error reporting can be difficult for users to understand when the required Launch Bar/Core Build state is incomplete.

Goal

Improve the usability of Launch Bar / Core Build workflows, particularly for CMake projects, so that users coming from MBS can build, run and debug projects more naturally while retaining the flexibility and portability benefits of Core Build.
The intention is to improve the existing Launch Bar model rather than recreate MBS semantics or replace the Launch Bar.

Proposed areas of work

This is an umbrella issue. The work should be split into smaller independently implementable issues.
Initial areas include:

Project Explorer to Launch Bar linking

Provide an optional mechanism (eg, a new button on the Launch Bar) for keeping the Launch Bar project selection in sync with Project Explorer, reducing the possibility that the user is working with one project while Build/Run/Debug is configured for another.
This should be investigated as a general Launch Bar usability improvement rather than being unnecessarily restricted to CMake.

Support CMake projects containing multiple executable targets

Use CMake model information to support projects containing multiple add_executable() targets and allow the user to clearly select which executable is used for Run/Debug.
This work is expected to require CMake File API support and needs to define the relationship between:

• Eclipse project;
• CMake build configuration/build directory;
• executable target;
• Launch Bar descriptor/configuration;
• Launch Mode;
• Launch Target;
• build settings and launch-specific settings.
  The first implementation should preferably support multiple executables from a shared CMake configuration/build tree, with more complex layouts considered separately.

Related / future areas

Other improvements identified during this investigation may be handled by separate issues, including:

• better Core Build diagnostics and first-run guidance;
• improved visibility of CMake configuration/model information in the Launch Configuration UI;
• interaction with automatic CMake Configure (see Added API to manually run CMake #1483, Make sure Launch Bar Manager sends event at a correct time #1486);
• CMake File API support;
• portability of workspace-specific build/launch configuration;
• possible use of project-supplied Launch Target hints/prototypes;
• improved handling of toolchain selection;
• Support for CMake Presets is currently out of scope because they are not compatible with Renesas e2 studio's toolchain model.

Approach

The work should be incremental. In particular, project-selection/Launch Bar usability improvements should not be blocked by the more substantial CMake File API and multiple-executable work.
The attached requirements/design document contains the investigation, background, current UX analysis and proposals that led to this umbrella issue.
attachment: tbc