Hi Doug and all,
I would like to discuss these questions in person, but alas I'm not going to make it to Ludwigsburg this year, so I'll have to ask them via mailing list.
I've been looking over the code you changed with this update and here are a few questions for my clarification
1) It looks like CoreBuildLaunchConfigDelegate.buildForLaunch(ILaunchConfiguration configuration, String mode, ILaunchTarget target, IProgressMonitor monitor) is the entry point for the launch-bar-based build.
2) When I step through things from 1 it looks like the following sequence is followed:
a) Get project from configuration
b) With project, mode, target call getBuildConfiguration(project, mode, target). The current impl of this uses the toolChainManager.getToolChainsMatching(targetProperties) to return a Collection<IToolChain>
c) Only the first IToolChain from the resulting Collection is used (currently).
[Doug] The current implementation of this allows for the launch config to pick a preferred toolchain. I will also be adding UI to reorder the toolchains so that the first one represents the default preferred
toolchain.
d) The ICBuildConfigurationProvider is got from the project and used to call ICBuildConfigurationProvider.createBuildConfiguration(project, toolchain, launchMode, monitor)
Question 1: It looks like the only way that the selected ILaunchTarget wrt the ICBuildConfiguration creation is to lookup the Collection<IToolChain> tcs by using the target properties in CoreBuildLaunchConfigDelegate.getBuildConfiguration(). If this is right,
do you expect that for (e.g.) Docker-based build or run launches via launchbar that the ILaunchTarget will be a 'DockerContainerLaunchTarget' (or some other name)? That is, do you expect that the launchbar UI will expose the Docker (or other ICommandLauncher)
in the launchbar 'on' combo box (or rather in the New Launch Target... dialog)?
[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.
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.
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”. 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…
[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.
[Doug] Hope that helps! And keep the questions coming as you need.
Thanks for info,
Scott
On 10/12/2017 1:42 PM, Doug Schaefer wrote:
Hey Core Build and CMake fans!
I’ve submitted my latest update. You can see it here:
https://git.eclipse.org/r/#/c/109948/
The key feature I’ve added it the ability to specify a toolchain to use for a given build for launch. This is especially necessary when you have multiple toolchains available for a given target like we do with Windows, or when you have
multiple versions of toolchains available to you.
I also move storage of build settings out of the launch config, which was a pretty bad idea anyway, and they are now stored in preference store associated with the build config. That should open the door to build configs independent of
the Launch Bar if someone wants to pursue that.
And now that we can manually specify toolchains for build configs, I’ve changed CMake so that the toolchain files are matched up with toolchains, instead of target properties. This makes more sense especially if you have multiple toolchains
with different CMake setups.
Feel free to ask me anything or any other feedback,
Doug.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
