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>
With AndroidRunnable gone, there is only one incarnation of
a Runnable left - the StandardRunnable.
It is not expected to ever need a different runnable again,
as platform differences are now handled in the platform specific
RunConfigurations and RunWorkers created there locally, and
global information is typically communicated via
RunConfigurationAspects, so there is no point in keeping the
Runnable::{Concept,Model} machinery.
This patch here essentially makes StandardRunnable a type alias
for Runnable, to allow downstream changing all
if (r.is<StandardRunnable>()) { ... r.as<StandardRunnable>(); }
one by one.
When all downstream is adjusted, the alias can go completely.
Change-Id: I86aa92c7fae8d54ca603484b7e1746c126b0bddb
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Killing every process on the system that happens to have the same name
as the one we've started is error prone and dangerous. We might kill
processes we haven't started and other processes might rename
themselves at runtime so that we don't find them anymore.
The process ID is obtained by outputting it as very first thing on
stdout and then starting the process with "exec", so that it isn't
forked.
Change-Id: Icc51bd1968afc47f4dc42f9e90e5dcbd0b1e40a7
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
A QLatin1String isn't a StandardRunnable.
This fixes a regression introduced in 58be2708a.
Change-Id: I6b3bb337227631011a6bc26c938945bb0e912e62
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Less typing and less cycles than join(QString) where appropriate
Change-Id: I6ebc0e17e4d7fd9845864dd95b7de4ba4dad6906
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
We cannot technically enforce a remote process to actually terminate,
but we don't want the associated DeviceProcess to "hang" forever.
Therefore, we now
a) check whether the kill operation reports an error and
b) start a timer after starting the kill operation.
If the kill operation either "officially" fails or does not have the
desired effect of actually terminating the process within a given time
frame, we set the DeviceProcess to "finished" manually. This is the same
thing that already happens when the connection gets lost, where we also
report the DeviceProcess as finished, even though the remote process
might still be running.
Change-Id: I5620f90453463c64d3a84abd30f1ec7eec9d492d
Reviewed-by: David Schulz <david.schulz@digia.com>
Every device can now return a DeviceProcessSignalOperation,
which allows to kill or interrupt processes running on the
device.
Change-Id: Idaa04ebc767e09ca167fa033ed93860b9b81479e
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
Reviewed-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
Provide a QProcess-like abstraction that can be used
to implement processes running locally or on a remote
device. Objects of a concrete class implementing the functionality
are created by IDevice objects.
Current implementations are:
- Local execution (QProcess-based), provided via the DesktopDevice.
- Remote execution via SSH.
- A specialized case of the former for remote Linux systems (provided by
LinuxDevice).
The latter is already being used in a number of places. As a result, lots of
code dealing with details such as setting the remote environment could be
moved to a central location. These things are no longer the concern of whoever
is wishing to run a remote process.
Change-Id: I919260ee6e77a020ca47226a4a534e7b8398106f
Reviewed-by: hjk <hjk121@nokiamail.com>
