|
Thanks Marc, you’ve responded to a number of things that I didn’t say, so I’m a bit confused.
Everything starts at the launch bar. I am adding a launch descriptor, the middle selector, for each Qt project. You then select a launch target, either local or some remote system, and Launch Mode, run or debug, and then click Launch. For Qt projects,
that is all the interaction the user needs to do. We should be able to figure out everything else.
What I’m suggesting is that launch configurations are per project in this case, not per binary. The launch delegate or the launch itself can find the binary based on the mode and the target which together select the build configuration. It can also find
the debugger to run based on the toolchain used by that build configuration. Almost all toolchains I’ve seen include a debugger.
My plan is to do this for Qt projects, I.e. Create Qt specific launch configurations that will do this so we can see how it turns out.
Again, this won’t work if we can’t map build configurations to executable to launch so will only work for constrained project types, which Qt projects and our existing managed projects are.
BTW, the launch bar already handles creating launch configurations when needed. They don’t need to be done at project creation time. And, at least for the local case, users don’t really need to know they exist unless they try to customize the build (i.e.
The qmake command) and launch (program args, files to download, etc.).
HTH,
Doug
Hi,
I would love to see us move towards a simplification of the launch. I don't fully understand what you are suggesting though and I might be confused in the different toolchain details. Right now, you can righ-click on a project and say "Run as..." or "Debug
as..." and it will launch automatically. So I'm confused about what can be simplified.
First, to clarify, you describe reducing the number of 'launch configurations' meaning the instances, not 'launch configuration types' (attach, remote, local, hardware), right?
Currently, a user only needs to create a single launch configuration for each binary. It is only if different launch preferences need to be tweaked, that a different configuration for the same binary is needed. Also, we already use the same configuration
instance for the different modes (debug, run, profile), it is the delegate and tabs that (optionally) change.
I don't see how you can avoid storing at least the project in a configuration? How would you know what to run/debug? We could base ourselves on the currently selected project but that will not be obvious when in the Debug view. Maybe the launchbar could
allow you to choose a project instead of a configuration, which would then automatically select a single configuration and imply a binary; that might be limiting though. Or we could prompt the user after the launch, which seems annoying. There may be other
ways, but my guess is that none of them are perfect. Therefore, I sounds like we at least need to store the project in the configuration, which seems to be the same as storing the binary, which is where we stand today.
I like Dmitry's suggestion of automatically creating the default launch configuration at project creation.
Using IRemoteConnection for all launches sounds good even for the local case. But this should stay an implementation detail and not shown in the UI.
I think I'll stop now as I feel I didn't understand what you meant properly.
Marc
On 09/21/2015 10:39 PM, Doug Schaefer wrote:
Hey gang, we’ve talked about this recently and I’ve finally run into it head on with Qt. And it’s really the launch bar that ties the entire edit/build/debug cycle into a single workflow that’s got me here.
CDT launch configurations are really about launching binaries. You have to specify the binary in the configuration and you have to have a different configuration for each binary. In the general case, it’s really hard to find binaries that are related and
get it right 100% of the time without asking the user.
For Qt, as with other project types we have, the source in a project produces a single executable but with different build configurations for launch target and launch mode. In theory, I should be able to figure out where the executable is at launch time,
I.e. In the launch delegate, and not have to store it in the configuration.
Ideally, I have one configuration and it uses the IRemoteConnection API to start the processes, including on the Local machine.
For debug, I should be able to find the debugger based on the toolchain I used for the build. The interface to start up the debugger, the launch configuration can ask the toolchain where the debugger is and start it up.
I imagine there is a lot different between remote and local that may warrant two launch configs. For Remote, you may want to specify a list of files that you want to download aside from the obvious executable. For Qt, I’d want to download the Qt libraries
I’m using. I may also want to sync QML and other files that can be reloaded on the fly.
Hi Doug,
We come up to nearly the same idea working on our latest customized CDT-based IDE, we use heavily rewritten launch bar with only one launch config per project and this launch config contains all necessary information for running run, debug or even profile.
Moreover this launch config is created during project creation and able to discover binary to launch without asking user. I don't want to discuss local vs remote since we have too much specific things there, but from our practice using launchbar as a primary
UI tool, having one launch configuration for project provides more solid UX.
Dmitry
|
