... into AnalyzerRunnable and AnalyzerConnection and use the
RunControl's storage instead of an own copy in AnalyzerRunControl.
This is an intermediate step on the way to remove
AnalyzerStartParameters.
Change-Id: Iee7c38781b2fd6ef030dcdada1993684cbb34c74
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
* SysRoot can always be determined from kit.
* Pass around RunMode as extra parameter
not as part of AnalyzerStartParameters.
That's closer to the pattern used elsewhere.
* Environment was always initialized from the runconfig's
EnvironmentAspect. The tools can do that directly.
* Provide setter for display name for cases where
it is not equal to RunConfiguration::displayName
Change-Id: I811a0d7cdeb55cc37a16a593b3942abb567a2150
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
There is no gurantee that the runconfiguration stays alive after
creation.
Change-Id: Ia520cc33a89ec56ad6a9b928f841eb4551732ae0
Reviewed-by: hjk <hjk@theqtcompany.com>
This is what it is on the top level. The change makes it obvious
that in the valgrind(-derived) plugins the value is later wrongly
used to make a decision on whether to run the valgrind process
locally or remotely. But that's isolated in valgrind now and
can be fixed there.
Change-Id: I6fa5e669dec1f9e2cdebe42a1591d15144082a21
Reviewed-by: Anton Kreuzkamp <anton.kreuzkamp@kdab.com>
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
Our analyzers were designed with the assumption that only one of them is
ever running (e.g. there is only one instance of the respective UI
element for each Analyzer). Run controls, on the other hand, assume that
an arbitrary number of them can run concurrently. With "re-run" enabled
for an analyzer run control, these concepts clash. A quick test shows
that some analyzers actually crash if you try to re-run them, but even
if this were not the case, it could not work in a sensible way.
Perhaps it would make sense to change the analyzer design so that they
too can run concurrently, but not for 3.4, obviously.
Change-Id: Ie8650eeef0261f2b697269900d5b465aad10aaf2
Reviewed-by: hjk <hjk@theqtcompany.com>
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
As we cannot determine reliably what happened to the app we drop the
"success" parameter to notifyRemoteFinished(). It was almost always
true before and where it wasn't it didn't do anything useful. The
transition from AppRunning to AppKilled without AppDying in between
was invalid and would have triggered an assertion when it happened.
Task-number: QTCREATORBUG-11760
Change-Id: Iebf4ca9bddbcc7b152131f9574bc5f2c0a8ba44f
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Replace hard distinction between 'out', 'err' with flexible
OutputFormat. Also make sure that QmlProfiler shows application output.
Change-Id: I130c71884321e4c59c9a75f0836c37a7f0e805c4
Reviewed-on: http://codereview.qt.nokia.com/458
Reviewed-by: Christiaan Janssen <christiaan.janssen@nokia.com>
