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>
When given an empty string as executable and some non-empty arguments
QProcess might emit error() but not errorOccurred(). This was fixed by
2f0ffba638bdb868a810bc0349c240b6b6e172cd in qtbase, but we cannot rely
on that being present, yet. Thus, avoid passing empty strings as
executable.
Change-Id: Ia1bb5ebceb6edeca1e54489d12b838f3cea8851e
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
If the application outputs the "QML debugging is disabled" line (and
Qt Creator can read it), the QmlProfilerRunControl will kill the
application. In the test this happens if Qt Creator was compiled
without QML debugging enabled.
Change-Id: I958a991d304ec9af8643e88dd9709f580a28753f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Depending on the build configuration of Qt and Qt Creator there can
be various kinds of messages and we cannot reliably determine their
number in advance.
Change-Id: I162cc02a72200026d3cbe7498fa705911f4cda39
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Start the process with valid environment, connection, configuration,
and better suited arguments, and re-enable the test.
Change-Id: I4ff92ab60d46f3a96a1eb7c8414abf0fc56e8b26
Task-number: QTCREATORBUG-16436
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This test does start QC with '-version' which results in a (blocking)
dialog on Windows.
Change-Id: I75fc84382bf7228f17febe4b852db01362b02537
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
