Hi Marc,
On 09/22/2015 04:32 PM, Marc Khouzam wrote:
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.
Exactly, we have added project selector to launchbar and bound it to
project explorer, hence we have got current project every time, user
is able to switch it and launchbar debug/run buttons operate on it.
Sorry that I didn't explain this from start.
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
_______________________________________________
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
|