Fix the following warning:
qgetenv().toInt() is slow. Use qEnvironmentVariableIntValue()
instead [clazy-qgetenv].
Change-Id: Ifb5d3869e758f8c42bb9f34004d9c04d5dbb4d89
Reviewed-by: hjk <hjk@qt.io>
There are very few reasons to use mainWindow() directly.
Especially for modal dialogs, using dialogParent() is important, since
that guarantees the stacking order in case of other dialogs currently
being open.
Change-Id: I7ad2c23c5034b43195eb35cfe405932a7ea003e6
Reviewed-by: hjk <hjk@qt.io>
This is apparently the right thing to do anyway and also helps to
select the right emulator or device when multiple ones are connected.
In that situation otherwise an error
"Expected a single connected device, got instead 2 -
try setting 'ANDROID_SERIAL'"
would occur.
Change-Id: I650a221d1a321d4dd9035411f85c7a68244c20e2
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
We'd like to create more useful tasks from compiler output, that is, try
harder to identify consecutive lines that refer to the same issue and
create one task for them, rather than one for each line. In such
"aggregate" tasks, the first line will not necessarily carry the main
information. Therefore, we make it explicit what this main information
is by introducing a dedicated summary member.
Also streamline the font handling for compile tasks.
Change-Id: I933f2643a13c710dab1ab548c56669b129026eb5
Reviewed-by: hjk <hjk@qt.io>
Might be useful to set ANDROID_SERIAL to get hold of the right device
when multiple are connected.
Change-Id: I8f1f02552a9f57ee8a9ed35ae696d137cc85fe52
Reviewed-by: David Schulz <david.schulz@qt.io>
... when the debug server looks like lldb-sever.
Also use suitable arguments.
Needed for setting up device connection later.
Change-Id: Ie4130be7881e12d460ab5116b0018916d47ed012
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Needed for setting up device connection later.
Change-Id: Ib794a8bf093714935b9a3ed3f290d46550763d68
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It could be lldb-server at some time, too.
Change-Id: Iba4bd0d073ba74e10dd579f0115570ccd4189da3
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Presumably, they were intended for output that shouldn't get an
automatic newline, but if there ever was such a thing as automatic
newlines, it must have evaporated over time. All users of
OutputFormatter provide a newline if they want one.
Change-Id: Ibd219b7305fd503ce075d6f77930d2b538d5e2e8
Reviewed-by: hjk <hjk@qt.io>
This patch adds debugger integration from the KEIL uVision IDE:
* http://www2.keil.com/mdk5/uvision/
This IDE has the uVision Socket Interface (UVSC) that allows
to the applications configuration, building and debugging:
* http://www.keil.com/appnotes/docs/apnt_198.asp
Besides, it provides a binary client libraries for Windows, which
are implements some API which we are use in this patch.
Currently implemented the following features:
* Enumeration of a stack frames.
* Enumeration of a threads (tasks).
* Registers view (read/write).
* Local variables view (read/write).
* Watchers view (read/write).
* Disassembler view.
* Current location marker.
* Break-points.
* Step-in.
* Step-over.
* Step-out.
* Step-by-instruction.
* Start/stop/pause/continue debugger.
* Auto-detection for the installed uVision instances (as debuggers).
* Wizard for choosing and configuring of the UVSC debug providers.
At this moment added support only for the 32-bit ARM devices, provided
by the STMicroelectronics:
https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html
For this are implemented two debugger providers:
* Simulator - allow to simulate the target device.
* ST-Link v2 - it is a HW debugger.
This implementation tested only with the QBS using the following
target boards:
* NUCLEO-F767ZI (based on STM32F767ZIT6 MCU).
* STM32F4DISCOVERY (based on STM32F407VG MCU).
* STM32F103x (based on STM32F103C8T6 MCU).
A more detailed information about this patch can be found in a
bug-tracker.
Fixes: QTCREATORBUG-23426
Change-Id: Ie36a1f7430b56c33d6665cc35e43fe9bd95d28f1
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
This is mimicking a bit what has been done on the baremetal side,
and is formally more correct when the gdbserver is not a real
gdbserver, but e.g. a probe speaking the gdb remote protocol.
Change-Id: I1b42624b94071b34c009bd0650095792a5b2fcb7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This spares us the typical r = runnable(); modify(r); setRunnable(r)
roundtrip and the m_runnable storage that might or might not
be the same as runControl->runnable. Similar for m_device.
Change-Id: I8300260dd8dd7cd395e40bcd3d2ae45089085008
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... to filePath and setFilePath. In line with Utils::FilePath.
Change-Id: I7115b91876542629c3d61c8259bbd8d9f4022fc1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is what the consuming code expects in most cases.
Change-Id: I135592039e28b994996186f627215ab1d2f8d6dc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The Environment class is supposed to support values with references to
other variables, but we failed to actually expand them in most places.
Fixes: QTCREATORBUG-22687
Change-Id: I108cb59d3b4571471423455240f6f4f1cf64bf05
Reviewed-by: hjk <hjk@qt.io>
... taking a QString for the executable.
This weakens the very explicit QString -> FileName conversion via the
named constructors for the special case of constructing a CommandLine.
I think that's worthwhile here, as it reduces the noise on the caller
site under circumstance where the nature of the thing is obvious.
Change-Id: I27b4a73639728893d053b2e7ba65cb745f0ffe83
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Seems to be possible to trigger in a failing MinGW start on Windows.
Change-Id: Ica93c29ad677c24688a8cf2c5a0f1018471ffe51
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We regularly pass around strings or filenames or pairs of strings
or filenames and stringlist etc the in the end will be used
as a kind of "command line", with quite a bit of ad-hoc user
code and QtcProcess::addArg etc to set them up and manipulate them.
Let's have a class for that concept.
Change-Id: I288ab939d853b32c717135a65242c584c2beab50
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Looks like the mainwindow cannot be convinced to handle multiple
sets of dockwidgets.
So switch back to a single set containing everything and keep
track of non-default visibility in the perspectives, and persist
these sets.
The following pass:
1.
Start Creator with new settings
Goto Debug Mode
Move Break dock widget to right, switch on Global log widget
Leave Creator
Start Creator
Goto Debug Mode
Check: Debugger Selected, Break on right, Global log visible
2.
Start Creator with new settings
Goto Debug Mode
Move Break dock widget to right, switch on Global log widget
Switch to QmlProfiler sub-perspective
Leave Creator
Start Creator
Goto Debug Mode
Check QmlProfiler selected
Switch to Debugger sub-perspective
Check: Debugger Selected, Break on right, Global log visible
3.
Start Creator with new settings
Use any C++ test project
Start debugging / stop at main() (F10)
Wait for stop
Switch to Edit mode
Switch back to Debug mode
Check: Only "running" debugger dock widget layout present
(not the normal + preset at the same time)
Quit Qt Creator while this debugger is running
Check: Shuts down without crash
4.
Use any C++ test project
Start debugging
Switch to Debugger Preset perspective
Start a second debugger
Kill either instance
Check: Application dies, Debugger Preset perspective gets displayed
Switch to perspective of second instance
Check: Perspective looks ok (docks visible as before)
Task-number: QTCREATORBUG-21083
Task-number: QTCREATORBUG-21669
Task-number: QTCREATORBUG-21668
Task-number: QTCREATORBUG-21813
Task-number: QTCREATORBUG-21851
Task-number: QTCREATORBUG-22110
Task-number: QTCREATORBUG-22169
Task-number: QTCREATORBUG-22189
Change-Id: Ic9eb41ff7699ac0f48a85e68376daa80b2b6847e
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
For cases where no genuine RunConfiguration is available.
Use it in the debugger for the cases triggered from the menu.
Change-Id: I5671f4f5db2547c4a7a70bd34292bb6ccc8e6bf4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Into a trivial bit and two setters. Plan is to use it only with information
that is truly there (e.g. kit/device only) at the user side without having
to invent a RunConfiguration "handle".
Also remove some dead code in the test runner.
Change-Id: I987881e41722178b14b91f973b84cbdb67a9f85e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Move some constants to internalconstants.h or remove them entirely.
Change-Id: Iecd4def3b48130fb390bddf420da672d44e3d6b8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@qt.io>
Using aspects is the standard pattern nowadays, there's nothing 'extra'
to them anymore.
Change-Id: I446f9d7b1db58a4899e5e44df33ce51f655e7be4
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
