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/Obsolete/CoreBuildCommandLauncher"

< CDT‎ | Obsolete
 
(No difference)

Latest revision as of 21:44, 16 January 2020

Warning2.png
Note: The contents of this page is obsolete, but it may still contain some interesting tid-bits.

What Is The Issue?

bug513589 was introduced to support the use of docker containers for doing CDT builds. Jeff Johnston has implemented org.eclipse.cdt.docker.launcher, which depends upon linuxtools project's docker APIs for the managed builder. It does this by creating a ContainerCommandLauncher class implementing ICommandLauncher which delegates any build/clean commands to an underlying docker container. Impls of ICommandLauncher like ContainerCommandLauncher are introduced in managed builder via the ICommandLauncherFactory extension point.

Core Builder

It seems that the core builder is the future for cdt building.

IToolChain

The core build has the concept of an IToolChain, which is an extension point that allows new tool chains to be introduced via additional plugins and existing toolchains to be reused across project types and their associated ICBuildConfiguration impls. An IToolChain is associated with a ICBuildConfiguration typically upon construction by the cbuild configuration provider. There is also a method: IToolChain getToolChain() on ICBuildConfiguration to get the associated tool chain for that core build configuration instance.

New Thoughts (10/16/2017)

The IToolChain instance seems the right place to attach one or more ICommandLauncher implscmak, or perhaps multiple ICommandLaunchers. One important question is how this association can be expressed so as to:

  1. Separate the implementation of IToolChain (e.g. GCCToolChain) from the implementation of ICommandLauncher (e.g. DockerContainer). It would be best to have the toolchain implementation author not have to be concerned with remoting the toolchain
  2. Allow multiple ICommandLaunchers to be used (one-per-project at a time) for a given toolchain
  3. Allow new ICommandLaunchers to use or extend existing ICommandLauncher impls
  4. Allow new types of ICommandLaunchers to be used without modifying the toolchain, the cbuild configuration, or the project

Back to the top