When changing the Android device settings and pressing "Apply", the
information in the "Qt Versions" tab is no longer correct.
The Abi information is parsed from the mkspec, and that depends on the
NDK setting in the environment.
When the NDK in the device settings changes, it updates the toolchains,
and that triggers a re-validation of the Qt info in
QtOptionsPageWidget::validInformation, but since the Android Qt version
already has tried parsing the mkspec, and got (possibly empty) Abi
information, it never is parsed and updated again.
We need a way to force BaseQtVersion to update these things again.
Fixes: QTCREATORBUG-23095
Change-Id: I9cb55ad1a73db942804637344e4c856c7e95afd3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This hides the explicit use of a QFormLayout from the aspect
interface in a new LayoutBuilder class. That currently works
only on a QFormLayout in the back, but opens the possibility
to use e.g. a QGridLayout as use on the Kits and some option
pages.
The aspects now only announce sub-widgets they like to add,
actuall positioning is does by a new LayoutBuilder class,
also cramming several widgets in an hbox in the right column
of the QFormLayout is done there.
Change-Id: I2b788192c465f2ab82261849d34e514697c5a491
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
AndroidQtVersion reports as invalid also if NDK or SDK are not
configured, or there are other errors in Devices > Android, so point the
user there.
Fixes: QTCREATORBUG-23058
Change-Id: Ic81d0663552769f78b0121ee3e1ddfc1f6510c11
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Qt 6 will not use qmake to identify a Qt version, so this can not
be part of the public interface of BaseQtVersion anymore.
Provide getters for the information actually read via qmakeProperty(...).
Use the getters whenever possible.
Change-Id: Iadbee80b75e4f8b06caf90e7ed69fae2029b4dd7
Reviewed-by: hjk <hjk@qt.io>
Previously, AndroidManager::updateGradleProperties operated always
on a project node found using target->activeRunConfiguration()
which might or might not be the one that will actually be used
after the build.
This here still does not address the problem that the activeRunConfiguration
may change but introduces a way to specify the relevant node, and tries
to use the right one when available.
At some time, this could be developed into a real solution, e.g.
by invalidating the cache on build key changes.
Change-Id: I37a3d73e9ad3615025e4def2493f683d11add3c6
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
... on runcontrol creation to prevent later access. Adapt some users.
There are more to come.
Change-Id: I2a3fe5eea0ada4eff7d08b79a6f49694e6962c8a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In the new plugin setup scheme they are data members of the
plugin pimpl and never use the parent.
Change-Id: I28fe150393e8159064dcfbd113ce0320af50fd58
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Also add QT_INSTALL_IMPORTS, which is used in a so-called "copy" of
the code in the QtApplicationManager plugin. More is better in this
case.
Change-Id: Ie705d95a24664d3627875ee0463e83a13b830260
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This unifies the remaining paths of RunWorker creation to always
use RunWorkerFactories in the plugin pimpls.
There were, and are, still effectively three basic kinds of workers:
- "toplevel" tools corresponding to the run modes, that are often all
that's used for local runs and directly started via the fat buttons
or e.g. entries in the analyze menu, with factories already previously
located in the plugin pimpls
- core "tool helpers", providing tool specific functionality typically
used in conjunction with a remote device specific run mechanism,
set up via RunControl::registerWorkerCreator
- target/device specific runhelper like port gatherers contructed e.g.
via *Device::workerCreator(Core::Id id)
Worse, these categories are partially overlapping, so it was not
clear how a "clean" setup would look like, instead some ad-hoc cobbling
"to make it work" happened.
In some cases, the runMode id was used throughout the whole ensemble
of run workers for a given run, and which worker exactly was created
depended on which of the mechanism above was used in which order.
With the new central setup, the top-level runmodes remain, but the
second kind gets new ids, so the implicit dependencies on order
of setup mechanism are avoided.
This also helps in the cases where there was previously unclarity of where
and how to set up worker factories: It's always and only the plugin
pimpl now.
Change-Id: Icd9a08e2d53e19abe8b21fe546f469fae353a69f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This lets the compiler catch issues like QTCREATORBUG-22818 and
saves visible casts on the user side.
Change-Id: I5a307a55364daa0bec039a4c38cc9827841ff9c1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was triggered by a warning on a empty expression statement,
but it turns out that QDir::cleanPath calls can be avoided, too.
Change-Id: I930cbb1272294f57794c29e0cd48e3c0ba8c6fdf
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Add a line in the error checking for "SDK manager runs"
Fixes: QTCREATORBUG-22626
Change-Id: I63f783b376056a28c106bad1ce8c874acf6897f2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Essentially following the scheme used for the various project
configurations. This makes it possible to construct OutputFormatters
by Id only, potentially reducing hard plugin dependencies and
opening the road to have several output formatters per
RunConfiguration/Outputpane/...
Change-Id: I4b5fb6fb6be8b0d9a0859f178bb0effc3398b09e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We not only have to make sure that the Java path from the Qt Creator
settings exists in the PATH, it must also be the one that is found when
running Java tools. Otherwise having two different Java versions in the
PATH can lead to the wrong one being run for the build.
Fixes: QTCREATORBUG-22504
Change-Id: I22ff88fb334bb8ba5f719fbc3482c4629713409f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
33a9a03121 broke it by inverting the
condition.
Task-number: QTCREATORBUG-22504
Change-Id: Id0b66ec025281e6d6c52b7309f35a3bdfb8e7170
Reviewed-by: hjk <hjk@qt.io>
This combines two of the previous three paths to create run workers,
and refers to RunConfigurations by id, not by type where possible
to decrease coupling between the classes.
Only allow "type of run configuration" and "type of device"
as the only possible kind of restriction and require a uniform
RunWorker constructor signature.
Adapt user code to fit that pattern.
Change-Id: I5a6d49c9a144785fd0235d7586f244b56f67b366
Reviewed-by: Christian Stenger <christian.stenger@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>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
As replacement for functionality that's being deprecated
in Qt but still useful or needed, or that cannot easily be handled
without resorting to #if QT_VERSION checks in user code.
Change-Id: Id3575a54ff944bf0e89d452d13944fcaee270208
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... over setting command and args individually.
Change-Id: Iec7c8d3a0b05fb8fa0639f7ddbe7ccdc7387d2a2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Revert the IDs back to what they were.
Amends 26463a2219
Fixes: QTCREATORBUG-22564
Change-Id: I220e362793d525ee8f01ff9649feb2cdfc37bba3
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
