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>
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>
If several threads can be involved in the signal/slot exchange we need
to show the receiver objects to connect() so that the signals can be
queued when necessary.
Change-Id: I24b4fe90095ce10eeeff9618faff97bd9d05c6eb
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
The tools' ability to hook into processing of the output is
retained by making the function virtual.
Also remove the unusual overload of the RunControl::appendMessage
slot and the signal of the same name by renaming the signal.
Change-Id: If3c3cc2dd9c933169dc30b16e3165c9b3cf1440e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This solves the ambiguity between 0 and -1 being the "invalid" port.
Change-Id: I3bac11dd4117bb1820fbd58186699925b73df1c5
Reviewed-by: hjk <hjk@theqtcompany.com>
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>
Decouple layout generation from widget generation and
separate analyzer action description from menu action creation.
Tool specific layouts are named "Perspective" now.
Change-Id: I774efe77a07640c4cc26e4e566662c8a673c8831
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>
These re-implementations are conceptually "too specific". Rather let
the indiviual tools handle there expectations themselves.
Change-Id: I0bbea407b2241816a40d19eb1dbb0a7589cbda7b
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 provides a way for third-party plugins to implement run
modes without the need to add a value to the central enum or
using manual workarounds like RunMode(*(int*)&someUniqueObject).
Instead of centrally defined enum values this uses Core::Id that could
be defined anywhere.
Change-Id: Ic350e3d8dbb8042c61b2d4ffec993ca151f53099
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Reviewed-by: Eike Ziller <eike.ziller@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>
Mostly done using the following ruby script:
Dir.glob('**/*.cpp').each { |file|
next if file =~ %r{src/shared/qbs|/qmljs/}
s = File.read(file)
s.scan(/^using namespace (.*);$/) {
ns = $1
t = s.gsub(/^(.*)\b#{ns}::((?!Const)[A-Z])/) { |m|
before = $1
char = $2
if before =~ /"|\/\/|\\|using|SIGNAL|SLOT|Q_/
m
else
before + char
end
}
if t != s
puts file
File.open(file, 'w').write(t)
end
}
}
Change-Id: I44745947f315b73f0b983d4362f884580dc2d94b
Reviewed-by: BogDan Vatra <bogdan@kde.org>
The common base class contains only unused functionality.
Change-Id: I5f6db59a2972d6ab8383ce209937090cd46ae39d
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
Reviewed-by: BogDan Vatra <bogdan@kde.org>
Use one less signal for result passing.
Change-Id: I6209d248fb01056835ef65b91981b9b2747d6f7f
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
Reviewed-by: BogDan Vatra <bogdan@kde.org>
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>
Most of the time the port is not announced on stdout but on stderr.
Change-Id: If72bb7f65dcfe7e697de2545d33e99ddb6363ecf
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
