|
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).
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)?
e) Once the ICBuildConfiguration is created, the
ICBuildConfiguration.build is called for the project being
built...by the LaunchConfigurationDelegate superclass.
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?
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?
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
|
