This simplifies code and reduces the number of conversions between
QString and Utils::FileName.
Change-Id: I47bd86b9ae09b1da37b4e5e604761367ac1ab26b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
As all Runnables are known to be StandardRunnables, this here
essentially replaces all .is<StandardRunnable> by 'true'.
.as<StandardRunnable> by no-op, and fixes the fallout.
Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is/will be optionally available independent of the concrete
run configuration type, so use it.
Change-Id: Ife0e906ff47e916d2f7a9df73af8cdd83635cd65
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Combine host, port, username and password into a 'url' member and
add some convenience accessors.
Change-Id: Iddc26ff00dad1285c96aa56f196dbc4febe8e974
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to provide a set of urls indicating usable connection
points for 'server-using' tools (typically one, like gdbserver
and the Qml tooling, but two for mixed debugging).
Urls can describe local or tcp servers that are directly
accessible to the host tools, if needed port forwarding
could be set up when needed.
Use it as new base for GdbServerPortsGatherer for starters.
Note: Since none of the customization points for actual port
forwarding are currently provided by device implementations
only non-forwarding cases are working right now. Incidentally
this does not affect existing setups, as the only case where
it would be needed (Android/adb) have a complete custom
implementation. The medium-term plan there is of course to use
this new setup here and have the AndroidDevice implementation
only provide the forwarding, not the whole debugging (etc...)
Change-Id: I42c9783348cd430b1c435bbca56329c678ac485c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... to a running application that already has one.
Task-number: QTCREATORBUG-19302
Change-Id: Id83f840408c26f3db85dbe30dadac9949ce6b660
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Same (or similar, in case an explicit path is configured) message
is triggered by the base class, no need for duplicated here.
Change-Id: I1a3e3c386674e98dc0ddd31f1156f7e8254a53c2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The device is needed to properly interrupt the inferior with cdb.
Change-Id: I96f3a7393770be9821d8edd7123c458399d4494a
Task-nnumber: QTCREATORBUG-19253
Reviewed-by: hjk <hjk@qt.io>
When neither c++ nor qml debugging is enabled in the run page the
debugger wont start. Print a message to the Application Output pane
describing where the setting is located that enables debugging.
Change-Id: I580139e62c0fb0f4ae518ce818738165b80f8e0c
Reviewed-by: hjk <hjk@qt.io>
It's always needed and GdbServerRunner knows the PortsGatherer.
This also makes the setup more similar to the QNX PDebugRunner setup.
Change-Id: I5863d2c77cd5c92d0f25682d655c9901b8939c30
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Less code in the target implementations.
Change-Id: I759f082eba5eab7f4e8252c0d7b5ec64059ba860
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Parts of the Debugger engine rampdown mechanisms are
essentially one code path now, don't distribute that
over four classes.
Change-Id: I4c6edbc0db94d1f658b0c1d9c154552f286db876
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
setUseTerminal was called before the engine was set. Reordered it.
Task-number: QTCREATORBUG-19056
Change-Id: I43f2aebaf72a904ea3a3bcf03cd41186b191b209
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Fixes a regression introduced yesterday with 58a69c461a.
Change-Id: I9eea3d0adf45e2b65b7d395280ae0e0fbbe01127
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It is a fixed value in the respective contexts, no need to track
this 'state' separately.
Change-Id: Id442202ff7a72baf5a2b19ba4bb9dfec5f47fb70
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Moving the knowledge that this won't work well outside windows
kind of decreases encapsulation, but that's not really worth the
complication of the error handling here.
Change-Id: Idcb6f6d64f33ee8c49a01e62e20aad16d3f01b86
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Allow to rely on kit plus data directly specified in the dialogs.
This means, RunControls with nullptr RunConfigurations are allowed
again.
Change-Id: I0b574b397603c0520c8187a8967bff2cf5e20ae8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The idea is that they shouldn't change after start() to
be re-usable for an additional run later.
Change-Id: I272fc975657b0d8b5b13a07d58bd0b626868d32e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There was almost 1:1 overlap with DebuggerRunTool::is{Cpp,Qml}Debugging,
use one version only.
Change-Id: I4a8f2b7005d3f2e440cdab3eaf6ac476af894308
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Harm was limited, as these were the fallback values for terminal
and working directory that are overridden in all cases with
real RunConfiguations.
Change-Id: I7d3cef1ac814a0ffcf60a8977e0ae13136ea50b5
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
The idea is that the fixup should not be needed at all anymore,
instead, static data coming e.g. from the RunConfiguration should
be setup in the constructor, and everything else should be ready
at entry into start().
This also proceeds on path to the planned-but-never-implemented
idea that the RunConfiguration should (at most) be accessed at
RunControl creation time, not later.
Change-Id: I04d622785f5de628a7bb479bc0c39aff7d6cce01
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Only works for opened, active project, but better than before.
Change-Id: Icafe3a9605cea29cd16ed4bd316bf195e78efdb5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
It's all coming via individual setters now.
Change-Id: I373f43963e696fa7223f9d664de1df1bc8b021e5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
