sdk_definitions.json does not have to contain 'lldb;x.y' anymore
as this is part of the base installation nowadays.
Change-Id: I39bc988674a8e60b22cd852b890224ac1c87e8c8
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
(cherry picked from commit 430a33dcd9)
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
We are not re-using the server process currently, and servers surviving
their processes seems to lead to zombie server processes (on app
uninstall(?))
Change-Id: I996fcd490e98a5101840cbbab5f640abf1f2d90b
Reviewed-by: Dominik Holland <dominik.holland@qt.io>
Debugging will fail later, better catch the problem early.
Change-Id: I973ff346db718e2050f5aafab068717d4e723fa6
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Currently unused, guarded by an always-false m_useLldb flag.
Change-Id: Icedfa4bace3d5160cdc3d4fbcf72a22d74d0aa0f
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
That's the only user, and it's easier to extend to handle LLDB there.
Change-Id: I7ce236e2ff509b419d52b10d086a75ff0c2ea14b
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
There's LLDB coming into play, and debugServer is what we use on
BareMetal and RemoteLinux, too.
Change-Id: I77f8545ebbe6685708215ac579789f7d4990b7be
Task-number: QTCREATORBUG-23260
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Based on change 286266, we can find a correct NDK version for Qt for
Andriod version. This change allows Android plugin to get relevant NDK
information and registers appropriate toolchains and kits settings.
[ChangeLog][Android] Automatically use correct NDK version
corresponding to used Qt version.
Task-number: QTCREATORBUG-23583
Change-Id: Ic6b0d7a1ae8962c075b77498de88e018a008ac3e
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
androiddeplyqt does not deploy gdbserver anymore, since Qt 5.14.
Therefore the gdbverver deployment of Qt Creator is triggered for all
devices, some of which do not support the symbolic chmod parameters
(e.g. +x).
Change-Id: I66e9fabeb0da4a1a3693c655a085d81c15f9d263
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
The pid script was wrongly quoted on Windows resulting in not having
logcat ability, and no debugging.
Change-Id: Ica40d033b61b69bb2372f54f0eba19ae1d2e3c9f
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Only used once, and that use can be replaced.
Change-Id: I844254dfff9bb2b2c9c56ecbd56d2af2241fd2d8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For a long time, probably from the very beginning, a RunControl
was meant to hold (a copy of) data needed for its operation, that was
valid at the time of its construction, to be resilient in cases
where RunConfiguration setting were changed while the RunControl
was running, or to properly re-run with the original settings.
Unfortunately, the task was repetitive, as RunConfiguration
classes had no generic access to properties / "aspects"
and there was was the runConfiguration() accessor (probably
for mostly unrelated reasons in the output pane handling) which
made the idea of just casting that to the original runConfiguration
and access the data directly there appealing, with all the
expected consequences.
This patch here partially addresses the issue by copying some
more of the related data at RunControl construction time and
adjust the using code, avoiding most uses of the runConfiguration()
accessor in a mostly mechanical matter.
Complete removal appears possible, but will be less mechanical
in "difficult" plugins like ios, so this is left for later.
The new accessors in RunControl are very much ad-hoc, leaving
room for improvement, e.g. by consolidating the access to the
run config settings aspects with the other runconfig aspects
or similar. For now the goal is to remove the runConfiguration()
accessor, and to as much as possible fixed data after RunControl
setup is finished.
Next step would be to officially allow construction of RunControls
without a specific RunConfiguration by setting the necessary
data independently, removing the need for the various workarounds
that are currently used for the purpose of faking (parts of) the
effect of the non-existing RunConfiguration or refusing to operate
at all, even if it would be possible.
Change-Id: If8e5596da8422c70e90f97270389adbe6d0b46f2
Reviewed-by: Christian Kandeler <christian.kandeler@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>
The gdbserver is not uploaded to device for armv7 as lib symlink
is available and we can use the gdbserver packaged with the apk
Task-number: QTCREATORBUG-21317
Change-Id: I263eb48bbf3cf05b969db934a928185dba10373b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Since Qt 5.12.0 we don't use qmljsdebugger extra intent param anymore
and we need to pass qmljsdebugger to the application arguments.
Fixes: QTBUG-72132
Change-Id: Icefb75e94027b145832c114fd90579bd10bcb898
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
