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>
This is a mechanical replacement for the former executable, processArgs,
inferiorEnvironment and workingDirectory members.
Change-Id: I4160e01427ed801df9b729f1f31d0a2ca48159b5
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
... with a lot potential to code consolidation.
Change-Id: I4d3a7fcc1cc6ae8763799f18cf9701695f387791
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
This is almost uniformly used everywhere else.
Change-Id: I1ef9abb24066b21652aeb994b18ea3e19f48b3c6
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
The cases handled here are later handled using generic code in
DebuggerRunControlCreator::enrich().
Change-Id: I03de1d5378718019afdb046f4446bb46a97ddee6
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>
- Move sysRoot, debuggerCommand, targetAbi to DebuggerRunParameters,
they are always the one coming from the kit.
- Move projectSource{Directory,Files} to DebuggerRunParameters,
they are alway coming from the runConfiguration's project
- Pass RunConfiguration always as separate parameter, that's
what related code does.
Change-Id: I9965a052237af53fa2d170701bc88b552cab12ed
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Christian Kandeler <christian.kandeler@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: I78a70180927d085822e215ffb2b8ad256301e4a7
Reviewed-by: hjk <hjk@theqtcompany.com>
Export factory, de-export plugin, to remove one indirection
Change-Id: I13a46460d07d5ded6b26f2b5ceccd01142fb10e8
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
Less typing and less cycles than join(QString) where appropriate
Change-Id: I6ebc0e17e4d7fd9845864dd95b7de4ba4dad6906
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
"Run" should be disabled if active the kit contains not QNX device.
Task-number: QTCREATORBUG-12143
Change-Id: I6cf9c70a8c3fc2ec63833e93840c9310345bc2b6
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Change-Id: Ib67b696b7938eb4de1b67b211b7f529651cdb99a
Reviewed-by: Aurindam Jana <aurindam.jana@digia.com>
Reviewed-by: Nicolas Arnaud-Cormos <nicolas@kdab.com>
The previous approach when debugging on pure QNX 6.5
no longer works with QNX version >6.5. Use proper way with
"set nto-executable" and "run" instead.
Change-Id: I00961236b416c42a0c81e29ea087de5ddd3a5f00
Reviewed-by: hjk <hjk121@nokiamail.com>
This fixes interrupting the inferior process when debugging
BlackBerry applications on Windows. The code was already in use
for pure QNX application, but never BlackBerry.
Change-Id: Icbf8f913475f523ca178250087bfdf3b89086605
Reviewed-by: Nicolas Arnaud-Cormos <nicolas@kdab.com>
Reviewed-by: David Schulz <david.schulz@digia.com>
Change-Id: I10e5f7b4c9d0d527f8df34aa425a2a0bdaac5243
Reviewed-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-by: Nicolas Arnaud-Cormos <nicolas@kdab.com>
Use setBuildDirectory() in the different BuildConfigurations instead
of reimplementing that over and over again.
Change-Id: Ic355fdb4624c71667ce470b3e2865c9a8722ef09
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Provide a QProcess-like abstraction that can be used
to implement processes running locally or on a remote
device. Objects of a concrete class implementing the functionality
are created by IDevice objects.
Current implementations are:
- Local execution (QProcess-based), provided via the DesktopDevice.
- Remote execution via SSH.
- A specialized case of the former for remote Linux systems (provided by
LinuxDevice).
The latter is already being used in a number of places. As a result, lots of
code dealing with details such as setting the remote environment could be
moved to a central location. These things are no longer the concern of whoever
is wishing to run a remote process.
Change-Id: I919260ee6e77a020ca47226a4a534e7b8398106f
Reviewed-by: hjk <hjk121@nokiamail.com>
When debugging on a QNX device on Windows, neither
DebugBreakProcess(..) nor "-exec-interrupt" works for interrupting
the inferior process. Neither does sending it a SIGINT signal using
"kill" on the device.
This changes the local gdb process to run under the CtrlC stub on
Windows when debugging on QNX. This enables us to send a Ctrl+C
message to gdb, which interrupts the inferior, and allows us to
insert breakpoints during runtime on Windows.
Change-Id: I4b01fbe81138f3fe7a939a7e64267bac4eb8bf43
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
This includes fixing the application arguments when launching
the application through gdb. As the application is launched by
passing it as an argument to -exec-run (or run), the application arguments
needs to go in the same command. -exec-run won't care about
arguments set with -exec-arguments when being passed the application
binary.
Change-Id: I869acbedd2593a931bf5c3d88559ea2bda2c3ff1
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Reviewed-by: Aurindam Jana <aurindam.jana@digia.com>
Move the method used to create a config widget for a
RunConfigurationAspect from the RunControlFactory into the aspect
itself. This allows for aspects that are not bound to any factory,
which is what I eventually want to use to hold the environment for
run configurations.
Change-Id: Icceb5f44ca9eb63a87b9c7bb6468ff30dab943c2
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
