Re: [cdt-dev] Core Build/CMake update

[Scott Lewis <scottslewis@xxxxxxxxx>]

Howdy,

On 10/16/2017 5:15 PM, Doug Schaefer wrote:

<stuff deleted>

    
[Doug] The launch target is where the built application will run. If it’s going to run in the Docker container, then yes, the target should be some sort of target that represents the Docker container. That also implies you’d have launch configurations and delegates that know how to launch the binary in the docker container.

Are launch configs and delegates required then?   (for example:  no 'build but not run in docker container').   Or would it possible to have build in one container and launch in another?

e) Once the ICBuildConfiguration is created, the ICBuildConfiguration.build is called for the project being built...by the LaunchConfigurationDelegate superclass.

[Doug] No, once the config is created, we set it as active for the project. Then the superclass calls the build method on the project. This invokes the CBuilder which takes the active build configuration, adapts it to the ICBuildConfiguration and calls the build method on it.

Question 2:   Is this flow for build/clean different than the one currently invoked via the project context menu->Build Project (which is what is invoked via Project menu/Build).   If so is it your desire or intention to unify them with a single code path for both?   Or does that matter?

[Doug] As per my comment above, it is the same since this menu item also calls the build method on the project. The tricky part if you don’t use the Launch Bar, is how do you set the active build configuration? Right now, they are hidden from the user. If we reveal them, we need to make sure the user experience is clean and simple to understand.

Yeah I see that.

Question 3:   WRT the ILaunchTarget and it's possible relationship to (e.g.) ICommandLauncher and impls (like DockerContainerCommandLauncher).    Would you expect that the IToolChainManager.getToolChainsMatching(targetProperties) would some how return both 'remoted' toolchains as well as 'local' toolchains (hidden behind IToolChainManager service), or would the IToolChain that it returned be somehow used in ICBuildConfigurationManager.getBuildConfiguration(project, toolChain, mode, monitor) call to get/return a build configuration that is 'remote enabled'?   Would the latter break the managed builder (?).   So the question is:   Where do you see hooking into ICommandLauncher?...or some other way to get a remote-enabled ICBuildConfiguration.build?

[Doug] I would expect the Docker launch target to have a property that specifies it as a Docker launch. I would then expect toolchains that support building in docker to have the same property so that only they “match”.

What I don't understand about this is how to handle the following case:   Some tooling/plugin developer creates a local toolchain and releases it.  Someone *else* comes along and would like to create a command launcher that can works for that toolchain, ideally without modifying the original toolchain code or setting up new properties required to match.

I would then expect all toolchains to return a command launcher and the build configurations’ build and clean methods would use that instead of the current ProcessBuilder. The default would be to return the local command launcher, docker toolchains would return your docker one. Other than that, the CDT Core never needs to know about remoting. So goes the theory…

Ok, sounds good.   Are you thinking that IToolChain interface would get a new method:   ICommandLauncher getCommandLauncher() to implement what you describe above...or some other mechanism?

 

[Doug] Note also, the docker toolchains would know the magic incantation to get the header files copied over and their implementations of getScannerInfo would do the right thing. I assume that the container ids and such would also be properties on the docker target and can get passed onto the toolchain so that it sets up the docker command launcher to point at it, assuming that’s how that works. I’m not totally sure we have a way to pass that info from the target to the toolchain. Work might be needed there.

The part about this that currently confuses me is avoiding having to rewrite a toolchain impl in order to use an ICommandLauncher (whether local or remote).   I think it could be difficult if for every toolchain it had to be reimplemented/rewritten/redeployed to support each new kind of ICommandLauncher (e.g. docker container).

Thanks,

Scott