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.
It seems that the core builder is the future for cdt building.
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:
- 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
- Allow multiple ICommandLaunchers to be used (one-per-project at a time) for a given toolchain
- Allow new ICommandLaunchers to use or extend existing ICommandLauncher impls
- Allow new types of ICommandLaunchers to be used without modifying the toolchain, the cbuild configuration, or the project