Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CDT/LaunchBar"

< CDT
(Things to think about)
(Things to think about)
Line 24: Line 24:
  
 
Allow enabling/disabling the tool control per perspective.
 
Allow enabling/disabling the tool control per perspective.
 +
 +
There is a pretty big architectural problem with the launchbar and CDT launches. CDT requires that we know the following things in the launch configuration:
 +
- The IBinary we are launching
 +
- The Build Configuration to build (which we need to do before we can find the IBinary)
 +
- The Debugger we're going to use to debug (and start mode, why isn't that based on LC type and mode?)
 +
 +
When all you have is the IProject, how can we figure all that out properly.

Revision as of 12:07, 24 June 2014

Overview

Bug is here. https://bugs.eclipse.org/bugs/show_bug.cgi?id=437392

The LaunchBar is a Tool Control that's inserted into the top trim bar of all workbench windows. It allows the user to select an active launch configuration, an active launch mode, and an active launch target, then use the Build and Launch buttons to built for that launch and the execute the launch.

The launch configurations are provided by providers. They don't have to be launch configurations directly. The providers provide launch configuration descriptors that represent the potential for launch configurations but the configs are only created when needed. This allows us to provide automated launch configuration creation without actually having to create them if they aren't going to be used.

As an example, CDT will provide descriptors for each project that builds to an executable. It will automatically appear in the launch configurations selector when the project is created. When the user clicks build or launch, it will create the launch configuration with reasonable defaults for the given active launch mode and target. This way the user never has to go the the launch configuration dialog. If the user does already have a launch configuration for that project, for example - one checked in with the project, it will be used instead. The provider will get notified of the launch config and can decide what to do with it.

There is a default launch configuration descriptor provided as a default if no providers are interested in a given launch configuration. This provides support for legacy launch configs so the launch bar is immediately useful without any providers.

Launch modes become the preferred way of running tools. These are defined by plug-ins and can be provided for things like code coverage, and the various valgrind tools, etc.

Launch targets are the devices you launch to. One is provided automatically for the Local Machine target. It's the one that default launch configs, for example, use.

The CDT will provide CDT launch targets that allow us to determine which build configurations and which binaries are valid for the given target type. A Local CDT Machine (although likely also called Local Machine) will be provided to represent the host. CDT plug-ins can provide additional ones for the platforms they support.

I expect Android targets to also be supported to allow launching of Android projects to those targets using the toolbar.

Things to think about

If we have no launch targets types defined other than the built-in Local, we probably shouldn't show the launch targets at all since it eats up toolbar space for no reason.

Allow enabling/disabling the tool control per perspective.

There is a pretty big architectural problem with the launchbar and CDT launches. CDT requires that we know the following things in the launch configuration: - The IBinary we are launching - The Build Configuration to build (which we need to do before we can find the IBinary) - The Debugger we're going to use to debug (and start mode, why isn't that based on LC type and mode?)

When all you have is the IProject, how can we figure all that out properly.

Back to the top