It's only used internally as one-time communication between
worker and the *Tool singleton that handles toolbar button
states.
We basically start immediately after creation of the worker, so
any pre-start tool bar specific operations can be done at
RunWorker creation time.
Medium term, the runworker should proably steer "their" buttons
more directly.
Change-Id: Id6df703746ece5eebc23507739cd2a92ec55d11d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... instead of having one in each derived class.
Change-Id: Icd121ce46b1d161bd2d59eaeaad8363528dc3c23
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>
Removes one reason to derive from base RunControls (specifically
ValgrindRunControl).
Change-Id: I81e32a49ef30e79ee7e7b53a54021eaaba43453a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The change is "conceptually wrong", the AnalyzerRunControl derived
classes' functionality should be provided by ToolRunners based classes
encapsulating/"being" the current Analyzer*Runner classes.
However, the AnalyzerRunControl is only three (empty even) virtual
functions, but a big obstacle in merging attempt due to a lot of
mechanical followup changes in downstream users.
The current construction mechanism of analyzer run controls is actually
two different mechanisms (locally direct RunControlFactories, and a
"generic" createAnalyzerRunControl wrapper for remote cases). The generic
createAnalyzerRunControl makes it difficult to migrated them one-by-one,
due to the various downstream users.
So instead of merging the per-analyzer two uses directly reduce
the "indirection" distance by removing the AnalyzerRunControl
intermediate layer. After that the createAnalyzerRunControl mechanism
can be dissolved by using normal RunControlFactories also for
the remote cases. After that, porting to ToolRunner, and combining
with ther local equivalent can be done one by one.
Change-Id: I0ddace33fcce210cf3a547ac5bb23b3d85013934
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This introduces a mini-state-"machine" to handle RunControl states
Intialized->[Starting->Running->Stopping->Stopped->]*->Finished.
Needing time between trying to start and getting feedback is nowadays
the normal setup for all remote targets as well as for most local tools.
Making that the default for all runs simplifies the code and provides an
opportunity to (a) fix some currently wrong reports of "stopped
immediately" and (b) to remove target-specific (WinRT) or tool-specific
(Valgrind, GammaRay) state members doing essentially the same.
Change-Id: I7f52fee41144188ee8389e922fdc265f8c0a6459
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Provide protected methods in RunControl to handle the notification
of when the RunControl starts and stops. Use these helpers to
move the isRunning() method into the RunConfiguration itself instead
of reimplementing it everywhere.
Change-Id: Ia8de42f7a6a14a049870d4e7fcb9af6756c2caa4
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This maintains current behavior by letting all subclasses return 'false'.
This might be too pessimistic, but can be fixed on a per-tool base
Change-Id: I71ac1b1e2cc98cfb1c5b76bc7c60a3240c5d1dcd
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
On the user-visible side, only the 'Analyze' mode button disappears,
and instead a combobox to switch between different tools in appears
in the Debug mode toolbar.
Internally, that's quite some re-organzition: The centralized
'Analyze mode is busy' flag is gone, allowing us to run e.g.
ClangStaticAnalyzer and MemCheck in parallel.
Analyzer tools and debugger now share the same mechanism to
generate/load/save dock widgets.
Analyzer tools now create and handle their own start/stop button
when appropriate. In general, Analyzer tools can create/handle more
than one run control at a time.
Further consolidation is possible, e.g. RunControl state handling
could be merged into the base ProjectExplorer::RunControl to
avoid the still existing duplication in ~15 instances.
Change-Id: I91e5940ebc4211f98056d507cf2f7b5f8efe7f07
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
This is the first mechanical step to execute on the 'shared pool of
debugger/analyzer views' idea.
Future steps would be providing infrastructure for the view pool,
making all analyzer/debugger views use the pool and then re-extract
a sensible base for a 'analyzer-and/or-debugger' tool plugin interface.
Change-Id: I1bb392e6dd3084fc56937956bee1d6fd9530335d
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Make isLocal() less intrusively used and correct. Use the stored device
more often, also handle errors more quickly.
Change-Id: I146d1f5788ea79d0a9d7b058c81908d451cf00d0
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Sprinkle overrides over code derived from classes in ProjectExplorer
Change-Id: Ia4cc25649f7dc00b0ea126d8176a59afbc5ed574
Reviewed-by: hjk <hjk@theqtcompany.com>
Instead, use the one in its (Standard)Runnable.
Change-Id: I14dbe91c50d083d11e18d514ec391875c64e3851
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Remove unneeded function arguments, Qt 5 connects etc.
Change-Id: I95faf80e7b5ccc574e2457b841f7913bc2aa05d3
Reviewed-by: Christian Stenger <christian.stenger@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>
This does not need to go through the PE machinery.
Change-Id: If0b2fde5309d7e119e8ac27245a22939b68d847d
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
QFutureInterface acts by a shared pointer itself, so use that to
guards against the QFutureInterface object being destroyed while
the timer is running.
This feels awkward as QFutureInterfaceBase::future() is non-const
for unknown reason.
Change-Id: I1d43abe0c27183af2f01cf269e2a94d2fcaba46e
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Setting this option to e.g. "Everywhere Except in File-backend Mappings"
allows to 'valgrind' Qt Creator itself.
Without that option the valgrind process will die if certain code paths
are executed.
Change-Id: I8888456d324a25ce092f0b0128407adf2159f496
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
Getting the #include directives ready for Qt5. This includes the
new-project wizards.
Change-Id: Ia9261f1e8faec06b9285b694d2b7e9a095978d2b
Reviewed-by: Eike Ziller <eike.ziller@nokia.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>
