... instead of simply setting the result state.
Change-Id: I6525893b6459fbc07a6da2d036d531101864515b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... when a RunWorker reportStopped(). We have now always a
"main" RunWorker (again) that is in a better position to decide
what to do with "lower" worker states than the RunControl.
The overall RunControl stopped state meaning is not changed:
It is Stopped if all workers are Stopped (or Done, or Failed)
Change-Id: I04ce6a8cb5b2067ec05fd506f6adc6ca65de0c39
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This fixes the temporary regression introduced by 5a848aa1. After
having RunWorker registration in RunControl and RunConfigurationAspect
registration in RunConfiguration, this was effectively the only
remaining code in IRunControlFactory, so this can go now.
Change-Id: I38b51bb00058b90d30f0260660b040f788920008
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and replace it by direct uses of ProcessHandle::activate().
Change-Id: I7beffba7bfbeff72a81b8699ff54a311a74ce1a3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Instead of a blunt delete() RunControl::initiateFinish() is triggered
by the closing of the application output instead. The rampdown process
is basically the same as stop() now, except for the other success
signal (new finished()) and the final self-destruction of the
runcontrol.
stop() itself triggers initiateStop() on all running workers in
parallel (before it was in the order of start). This gives
downstream complex worker combinations the flexibility to use any
order it wants by ignoring stop() on 'uninteresting' workers,
and centralizing rampdown e.g. in the main worker. That setup should
be rare in practice, but seems needed in some profiler cases.
Change-Id: I986a152a663754206709ed4df0d4568847afad17
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This fixes the regression introduced in 5a848aa188 and uses the
feature to resolve the conflict between ClangStaticAnalyzer and Boot2Qt.
Change-Id: I6cdec8261a457c399c11a4b2078a78088d4c56d1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Realistically, we only have UTF-8/plain ASCII messages, and if not then
the conversion should happen when the message enters the "creator eco
system" as there's potentially information on the actual encoding
present, not at some random consumer further down the chain.
Change-Id: Ie21199b99255f5c4d28fce3da7db2fd6c3bcfb3a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Let the workers keep track of errors instead of passing around
string pointers in some but not all interesting places.
Change-Id: I3956bc947a50747dd3a0c9302b9f9873d192e9c6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
A RunControl is re-runnable if all its workers are,
a RunWorker is re-runnable if it's Stopped and unless it
says otherwise.
Also ensure SimpleTargetRunner only reportStop() once
per run and make process error message re-usable.
Change-Id: I73f5fb724d3026ceb81d5e32a3a71b4814b2bca9
Reviewed-by: Christian Stenger <christian.stenger@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>
Looks like this was done for debugging, but the user is not supposed to be
aware of internal implementation.
Change-Id: If24a2b0f85a04c2e88c5ef5fd66d34a606d46712
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
It turns out that one "Connection" per RunControl doesn't map
well to the uses we have. Instead, RunWorkers need to know
individually how to connect to the place where they can work,
but they are already specific enough to be able to use a
standard class (like QUrl) as their way to specify the needed
entry point.
In theory one could see a RunControl's connection as an
aggregation of its workers connection bits, but that does
not really seem to be needed in code.
As consequence, replace UrlConnection by a plain QUrl, and also
the HostName connection by a QUrl with hostName set.
Change-Id: I40c97e37779314ac0a77041e864a18eadb78f987
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
The recent RunControl related changes have led to several regressions
in the fragile handling of button states in the output pane.
Take advantage of the new Starting phase to fix disabling of the
run and enabling of the stop button at reasonable times.
Change-Id: Iae191a840484dd08d61facf6b9f439bfafcbbcb0
Task-number: QTCREATORBUG-18508
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Not needed anymore, effectively replaced by RunWorker start/stop.
Change-Id: I7483c841cdd4e05c9e1f7636a27b20ece37947c2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This can be used by downstream plugins to overrule existing
RunControlFactories.
Change-Id: I23c8e3983827dfa1b5f780664d2e539e908944aa
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... and remove getter. It's only a debugging aid.
Change-Id: I760dcddbfa1a5669c545ed8e9552381031836bd0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
A lot of the target-and-tool specific run controls nowadays
have something like a single main RunWorker. This patch
removes the need to have user-implemented RunControlFactories
in those cases and adjusts local run, remote linux,
python and nim to take advantage.
There's more potential use downstream.
Change-Id: Ie2d2f839b8be1fad2be3b79e21de3c0e475d88cf
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The interface has now moved to the RunWorkers.
Change-Id: I1ebf74c081697b8e44926ab00053417f9f60647d
Reviewed-by: Christian Stenger <christian.stenger@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>
Tools like ClangStaticAnalyzer do not operate on a running process,
so there is no valid process handle when they are 'stopping'.
Change-Id: I42754475f9c7c7367e0f4875c6f3348fd81fccf8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Forward all tool and target activities to run control, and initiate
further state transitions (only) from there. Also, make sure
tool/target's on finished() triggered on all finishing code paths.
After that, the base state handling is sufficient to handle remote linux
running and debugging.
Change-Id: I0150ef249c9ad0b7b8ac7192be6dc860c9ca8fc5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Remove some now-unusual connection to RunControl::finished
and use a finished() callback in the ToolRunner implementation
instead.
Change-Id: Ieddf05a2258d9a300ac50a739d77d9cfaee10ca6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Replicate parts of RunControl's read-only interface for
simpler user code.
Change-Id: Ic0f2efc0a7a0b96d26c5817f7fbc18b0c91a013b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Add some customization hooks to make tools aware of target errors
and vice versa.
Change-Id: I4d815087297a3fa1d1d6d52daeed7c4ae0f624bf
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
No need to depend on RunControl life time here.
The isRunning test is already done outside sufficiently often.
Change-Id: I3b33444df6092f52b186bbf3a58585ad0bbb03bb
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Less opportunity for tool/target implementations to mess with the
RunControl state.
Change-Id: I2d179cd85c50efd2314bad9b1c2250ff6b16370e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This essentially just puts the data members and most of the original
interface on the proper, i.e. the 'target', side of the tool/target
divide. Since the SimpleTargetRunner base already has an
ApplicationLauncher member, this can be used directly.
State handling and coordination between tool and target runner parts
stays as before for now, with unchanged 'custom' transition logic.
The plan here is to remove the custom state handling later, including
the two remaining cases of direct targetRunner->toolRunner calling
(startExecution, and adapterSetupFailed) for which this patch here
temporarily uses signal/slot connections.
Change-Id: I664f2e333b48b582befd0531a17d4008acac7c4c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Less coupling than using virtual functions for better re-use.
Change-Id: Ibbab38175538f65c0f563129c87e01736ed220af
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... to where it belongs, guarded by a check of RunConfigartion presence
Change-Id: Ie2bfdea30fded81f12a6962c9717c8574fc14ba5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Removes one reason to derive from base RunControls (specifically
ValgrindRunControl).
Change-Id: I81e32a49ef30e79ee7e7b53a54021eaaba43453a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
That's a good first approximation and often enough all that is needed.
Change-Id: If54cdb0e98cda94bc4a4ef24fcc12c78018c4dbe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
ToolRunner have access to the RunControl, which have a device.
No need for another copy anymore.
Change-Id: I1b71cf2fad9ecbadba859b7963175c1b7057f94d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This adds enough hooks to enable the base RunControl to take over
the task of most of the current ad-hoc "state machine" implementations
in derived RunControls (only exception is "intra-debugger" Start/Stop
handling), including error reporting.
The idea is to migrate "downstream" uses and finally remove the custom
state handling everywhere.
With this setup here, both varieties of RunControls can co-exist
for a while: New-style uses the Tool/Target state handling triggered
by the base RunControl::start implementation, old-style had this
function = 0, so all have their custom start() implementation.
'SimpleRunControl' derived cases (Local/RemoteLinux/Python run)
already use new-style with this patch SimpleRunControl doesn't
re-implement start().
Change-Id: I508f5ed05c557ca7188af92f9d9c8d00e2a4acfe
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This introduces a 'TargetRunner' base that it meant as a base
class for classes like the current AndroidRunner, IosRunner,
WinRTRunnerHelper, similar to the existing 'ToolRunner' class
taking care of the tool bits.
This makes a RunControl only responsible for state management
(start/stop control), application output and general user
visible display tasks, delegation most of the real work either
to the the target or the tool.
The usage pattern for creating a run control is now
RunControl *RunControlFactory::create(...)
{
if (barToolOnFooTargetIsSupported()) {
auto runControl = new RunControl(runConfig, runMode);
(void) new FooTargetRunner(runControl);
(void) new BarToolRunner(runControl);
return runControl;
}
...
}
The pattern can possibly be simplified later, for now the goal
is to make it uniformly used.
As first use, "split" SimpleRunControl into a SimpleToolRunner
(which happens to be all its previous non-(Base)RunControl bits)
and the run control bits (its RunControl base).
This will make the SimpleRun*Control* class as such vanish again,
keep it for now to give downstream uses (Qnx/Boot2Qt) some time
window to adapt.
Change-Id: Ifafed4d0577466186280ac5014f4ad9eec78c56c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This continues the quest started with eb0b0f944.
This also moves the AnalyzerRunControl::starting signal to the
base, similar to the already present started and finished
signals. Moving emission of the signal to the base is left
to a follow-up patch to keep this here small.
Change-Id: I12e04823df22e7667a4d0a9ee7412153180c60cc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
