Keep the old method for now to ease downstream porting.
The change is kept mechanical, there's a lot of cleanup possible now
on the user code side.
Change-Id: I936baedd45b7ba057f1c789a1bec896886f48eff
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
It's returning a FilePath, so it's a better fit.
Keep the old versions as inline function now to ease downstream migration.
Change-Id: I535887928018f42b92895c8b0c82527f0d55e5ca
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: André Hartmann <aha_1980@gmx.de>
This is mimicking a bit what has been done on the baremetal side,
and is formally more correct when the gdbserver is not a real
gdbserver, but e.g. a probe speaking the gdb remote protocol.
Change-Id: I1b42624b94071b34c009bd0650095792a5b2fcb7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Qt 6 will not use qmake to identify a Qt version, so this can not
be part of the public interface of BaseQtVersion anymore.
Provide getters for the information actually read via qmakeProperty(...).
Use the getters whenever possible.
Change-Id: Iadbee80b75e4f8b06caf90e7ed69fae2029b4dd7
Reviewed-by: hjk <hjk@qt.io>
This spares us the typical r = runnable(); modify(r); setRunnable(r)
roundtrip and the m_runnable storage that might or might not
be the same as runControl->runnable. Similar for m_device.
Change-Id: I8300260dd8dd7cd395e40bcd3d2ae45089085008
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... to filePath and setFilePath. In line with Utils::FilePath.
Change-Id: I7115b91876542629c3d61c8259bbd8d9f4022fc1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is what the consuming code expects in most cases.
Change-Id: I135592039e28b994996186f627215ab1d2f8d6dc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Into a trivial bit and two setters. Plan is to use it only with information
that is truly there (e.g. kit/device only) at the user side without having
to invent a RunConfiguration "handle".
Also remove some dead code in the test runner.
Change-Id: I987881e41722178b14b91f973b84cbdb67a9f85e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For a long time, probably from the very beginning, a RunControl
was meant to hold (a copy of) data needed for its operation, that was
valid at the time of its construction, to be resilient in cases
where RunConfiguration setting were changed while the RunControl
was running, or to properly re-run with the original settings.
Unfortunately, the task was repetitive, as RunConfiguration
classes had no generic access to properties / "aspects"
and there was was the runConfiguration() accessor (probably
for mostly unrelated reasons in the output pane handling) which
made the idea of just casting that to the original runConfiguration
and access the data directly there appealing, with all the
expected consequences.
This patch here partially addresses the issue by copying some
more of the related data at RunControl construction time and
adjust the using code, avoiding most uses of the runConfiguration()
accessor in a mostly mechanical matter.
Complete removal appears possible, but will be less mechanical
in "difficult" plugins like ios, so this is left for later.
The new accessors in RunControl are very much ad-hoc, leaving
room for improvement, e.g. by consolidating the access to the
run config settings aspects with the other runconfig aspects
or similar. For now the goal is to remove the runConfiguration()
accessor, and to as much as possible fixed data after RunControl
setup is finished.
Next step would be to officially allow construction of RunControls
without a specific RunConfiguration by setting the necessary
data independently, removing the need for the various workarounds
that are currently used for the purpose of faking (parts of) the
effect of the non-existing RunConfiguration or refusing to operate
at all, even if it would be possible.
Change-Id: If8e5596da8422c70e90f97270389adbe6d0b46f2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@qt.io>
Using aspects is the standard pattern nowadays, there's nothing 'extra'
to them anymore.
Change-Id: I446f9d7b1db58a4899e5e44df33ce51f655e7be4
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
It has been an obsolete alias for setId for a while and downstream
uses have been adapted.
Change-Id: I467370aa67054599c7771e8275d28e62ddc461fa
Reviewed-by: Tobias Hunger <tobias.hunger@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>
The basic idea is to provide an easy-to-configure reusable
building block to provide an "Executable" in a run configuration.
This patch here extracts some generic from the previous
ExecutableAspect into a BaseStringAspect and bases the new
ExecutableAspect implementation on it. It also adds the
the ability to make it editable or to manually override an
executable, and adds a SymbolFile aspect for the accompanying
sources of debug information.
Use in RemoteLinux and Qnx for starters and demonstration purposes.
In the end the Qnx runconfiguration widget does not depend on the
RemoteLinux implementation anymore by replacing the previous
code-sharing-by-inheritance by direct (and less) code.
Change-Id: I91b55820455256a8526e39458364b6cb74e63cd7
Reviewed-by: Tobias Hunger <tobias.hunger@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>
The attach part has not been active for a while, but there's code
now easier to reuse. So move participants of a potential solution
to a suitable place before attempting to fix functionality.
Change-Id: I9a7d4a6637e8ef214c22ee5683103e464109210d
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This apparently fell through the cracks in 89f02cba2.
Task-number: QTCREATORBUG-18804
Change-Id: Ib00a5a074ec1df3292267a194e8e87a92d3c6dfc
Reviewed-by: Dan Cape <dcape@qnx.com>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Host and port reasonably belong together, using a QUrl makes that more
explicit and follows the lead of the Qml profiler in that area.
Change-Id: I754cb17d165ce6b2f25c655eeebfd8ac8f5a93c7
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
There will be stopDependencies, too, which apply when stopping the
runcontrol.
Change-Id: Id72771d28cbb6b254572c9f93db93e0d054b890f
Reviewed-by: hjk <hjk@qt.io>
It looks like the case where workers need talk to each other by
only knowing the type of the 'partner' does not exist in practice
anymore. With the now-common setup of a 'primary' worker that one
can introduce the 'lesser' workers to each other directly.
That's also conceptually more robust that picking a partner by
type only only from some 'pool' (all the workers in a runcontrol),
scales better (it e.g. is imaginable that a RunControl needs
more than one PortGatherer in complex setups where more than one
device is involved) saves a few cycles, and even removes the need
for workers to be qobject_cast-able.
Change-Id: Ib3d8c942c893d6c198d9813cce7df28ba3260ce8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
This increases re-usability of activities like 'port gathering',
and makes their use less dependent on actual device implementations.
Change-Id: I017cb74874f2b38c487ba2d03906a675d5618647
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Aim is to replace it with its ProjectExplorer::RunControl base.
Change-Id: I30f837050e7c016887dc4b6cfef10b947f4f88ed
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's tool specific, so put it into the tool (only) related code.
The additional level of indirection will go again, plus the original
one will be removed once the *DebugSupport classes can directly
use DebuggerRunTool as base.
Change-Id: Ieaa386a0f7d724b09cedaaba8fb7d1e6dc4ad55b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Treat ApplicationLauncher as a special case of a DeviceApplicationRunner
with an implicit desktop device.
As a first step, lump the two implementations together.
Change-Id: Ifa3ea3f38d320023050378555e2d256e762b6683
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
In preparation of merging the class with LocalApplicationLauncher.
Change-Id: I190f8da34a2420061f05ccf4a9fdd428c2a2c57b
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Under the assumption that the QNX debug support should work similar
to the RemoteLinux debug support we have to:
a, use the Runnable provided with the run control
b, not recycle the arguments from the run control start parameters
c, prepend a new set of QML debugger arguments when QML debugging
There seems to be some mechanism that allows us to do C++ debugging
by simply starting a process "pdebug <n>" for some port number <n> on
the target. We don't touch this here.
Task-number: QTCREATORBUG-17208
Change-Id: I0f4541968e1d20940617e8ff6d16a8ad86ea22c9
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
All other targets call their devices "Device",
not "DeviceConfiguration".
Also, add a few namespaces and inline the trivial
QnxDeviceConfigurationWizardSetupPage files.
Change-Id: I26168d1b676f6a646b11b61d4cdb7d0f30e18242
Reviewed-by: Anton Kreuzkamp <anton.kreuzkamp@kdab.com>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This solves the ambiguity between 0 and -1 being the "invalid" port.
Change-Id: I3bac11dd4117bb1820fbd58186699925b73df1c5
Reviewed-by: hjk <hjk@theqtcompany.com>
This is a mechanical replacement for the former executable, processArgs,
inferiorEnvironment and workingDirectory members.
Change-Id: I4160e01427ed801df9b729f1f31d0a2ca48159b5
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
We have tcp, local, and native by now. We have to expose that in a
clean way.
Change-Id: I0ce7be693aa7f47ebea7abe435a224a176b6c94b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
The services need to be loaded before the first QML engine is created.
The first QML engine may be created before a client connects. When the
JavaScript debug service is loaded the engine is put into interpreter
mode as we don't support debugging in JIT mode. Profiling, however
should be done in JIT mode, whenever possible.
Thus, in order to avoid the loading of unnecessary plugins and to get
better results from the QML profiler we tell the debug server which
services we expect, even before the client connects. Qt 5.6 will support
additional command line arguments to specify the services and this
change uses them.
Change-Id: I6dcee016c39995e9adada6eaf0e39d8299c9b7e7
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: hjk <hjk@theqtcompany.com>
