We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace.
Task-number: QTBUG-99313
Change-Id: I88edd91395849574436299b8badda21bb93bea39
Reviewed-by: hjk <hjk@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... or nothing, if the process object is destroyed immediately.
Change-Id: I6a1e1928bc49fc20a1c0e0ee9b8f4f723276bbca
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Centralize some boiler plate and warn about best-guessed cases.
Keep the QByteArray based access as writeRaw()
Fixes: QTCREATORBUG-27445
Change-Id: I948d80fba78b36cf85cc73664175ab05eb7707d4
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
The cmdline-tools package used to have the folder structure "tools/bin".
However, latest packages are using the structure "cmdline-tools/bin".
And since subsequent updates we are installing "cmdline-tools;latest"
package, it will be put in "cmdline-tools/latest" folder, so we cannot
extract to that path, or otherwise sdkmanager will complain that the
path is in use.
Currently we extract it and put it under the SDK path, then use it to
install the essential packages, then it won't be used at all. This patch
changes that by extracting the downloaded package into a temporary
location, and use sdkmanager from there directly.
Also, this patch updates the links to the cmdline-tools along the way.
Fixes: QTCREATORBUG-27174
Change-Id: I1f5d0e38f5a026631e8a3852821d85a69d543c32
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
This includes replacing DeviceProcess terminal handling with base
member.
Change-Id: Id1541bfce33c71dddc71b4816ad0b174dce3879c
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
- There is no PLUGIN_DEPENDS for tests, and it wouldn't work anyhow
because of duplicated symbols. It was interpreted as a dependency and
the test disabled because no such target exists.
- Move the platformNameToApiLevel(...) function to
avdmanageroutputparser.h to break the dependency to a lot of Android
support code.
Amends 78da7e2922
Change-Id: I6933684a76e5291d415c72388caa3df2bee7cbfb
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Introduce EventLoopMode enum and pass it to the
QtcProcess::runBlocking() instead. There is no need to
store this setting. By default this value is NoEventLoop.
Change-Id: Icad98b77bec5280b79039b7e5aa4ec408261521c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Both the sdkmanger and avdmanager (maybe more) need to parse the sdk
level for packages and devices which may contain letters, make them
use the same logic.
Change-Id: Iff7fef3a66e00fac11b833f73f2f334a4cf1a766
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This patch needs to be applied together with the parent change.
There are 3 basic cases:
1. The user doesn't write anything to the write channel:
You don't need to call closeWriteChannel manually anymore.
By default the QtcProcess you create is in ProcessMode::Reader mode.
Internally it opens the process in ReadOnly mode and
closes the write channel just after starting.
2. The user writes some initial data (after being started)
and then closes the write channel:
All what is needed now it to set the write data
(QtcProcess::setWriteData) before calling start.
You also use the default ProcessMode::Reader mode.
Internally it opens the process in ReadWrite mode
and writes the writeData asynchonously when the process
already started. After writing the data it closes the
write channel automatically.
3. The user writes the data also after calling start.
All you need now is to create a process with
ProcessMode::Writer mode. In this mode the write
channel is not closed.
Internally it opens the process in ReadWrite mode
as some writers also read the data from the process.
All the code base is adapted here to the above rules.
Change-Id: Id103019d1d71a3012fd1eade226fe96b9aaa48c2
Reviewed-by: hjk <hjk@qt.io>
The Windows-only restriction is nowadays handled inside QtcProcess.
Change-Id: I77d6914831ff172026665a429b497940c60970ac
Reviewed-by: David Schulz <david.schulz@qt.io>
To make clear that this is not just any finish.
Also change FinishedError to FinishedWithError, to create
symmetry.
Also adapt enum member description to reality.
Change-Id: I13e05391eb86fdb24e2ae660f14dfddb282e1104
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
An issue in SynchronousProcess causes a time-out when the process output
is not terminated with a \n or \r.
This workaround lowers the timeout from 600 to 4 so that the
unterminated output gets consumed nevertheless, and the user needs to
wait only 4 seconds for that.
Task-number: QTCREATORBUG-25667
Change-Id: I40f3053c7c4948c27003e9ec73d00a9d660024a4
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Make functionality dependent on an (intentionally ugly)
setProcessUserEventWhileRunning call.
Also, back-paddle a bit on API combination of QtcProcess and
SynchronousPrceoss for now and prevent the QtcProcess-and-
runBlocking and SynchronousProcess-and-start combinations.
Goal is still to have all in QtcProcess in the end, but this
may take a while.
Change-Id: Ic146ec5db0ab8dc9613e5b2af5f4dc90bc7465ca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Makes run() more similar to what start() looks like.
Also add some asserts to make sure run() and related functions are
only called on SyncronousProcesses, as these are currently the only
ones where this works.
Change-Id: Idee6076c3f40a484db5c17f5bb348698cc83d220
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Quick and dirty as plugin test. Depending on how the upcoming SdkManager
parsing tests turn out, these could become standalone tests.
Launch qtcreator with command line option "-test Android"
Change-Id: I66c1604a1df96d8c2c50006052d664d4a339f5ff
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The result is fully stored in the object anyway. Using the extra
SynchronousProcessResponse structure only causes copies of
the data and complicates access on the user side in
a lot of cases.
The result bits are now also accessible individually.
There's obvious room for follow-up changes on the topic, e.g.
ShellCommand::runCommand's parameter list could shrink to
just a SynchronousProcess parameter.
Change-Id: I45aa7eb23832340be06905929280c012e1217263
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Mechanical to prepare merging the actual classes.
Adapting #includes.
Change-Id: I77a2c28129287778bc870c30cb890cd26bc2e62b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Makes the interface more similar to QtcProcess.
Change-Id: I58e57d9fdb7c37eb0d2a5c5eef8643d6be97c3cc
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
In Qt 6 implicit conversion between QFuture and other types
is forbidden. Make it explicit instead.
See ff0ba7e2d7b91fd5809cb314935a1ca1a436f6c9.
Change-Id: Ie42e6b9b5047ba5eeec9f63fd03179e73f95314d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Also, add the --sdk_root argument which is needed.
Change-Id: I85f9444b35bb31aed9670bd322f2754061cf70c6
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Follows af7c218d95, the old android
tool is not useful anymore.
Change-Id: I126ecc24622f2e90465440c86b84cdfb30c103e1
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
* There were two functions to detect jdk path, unified them.
* First try to find jdk 1.8, if not found, look for newer versions.
SDK Tools version 26.x needs jdk 1.8 however, the new cmdline-tools
can work with the newest jdk, so the UI will warn the user if the
selected jdk cannot run sdkmanager potentially because of the jdk
version.
Change-Id: Iee2c378598c26e8a9a8245262110ac20322a2d2b
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The newly added cmdline-tools is not used by Qt Creator.
So QC Android settings will be broken for users who have
an Android SDK installed from Android Studio, or who
updated their SDK package (i.e. tools -> cmdline-tools).
This patch fixes both of the following issues:
1- QC looks for sdkmanager tools under <SDK_ROOT>/tools/bin/sdkmanager,
and with the new SDK it's under
<SDK_ROOT>/cmdline-tools/latest/sdkmanger.
2- QC checks the version of the SDK tools and opens the
old SDK Manager for SDK tools version 25.3.0 or less.
However, since cmdline-tools is now version 1.0, it causes
QC to think this is an old version.
Fixes: QTCREATORBUG-23726
Change-Id: I7e6bbc6840d24d358f68dfa3e229799394ace950
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Allow parsing packages of the latest Android 11 (R) with API level 30.
Change-Id: Ia50d2ff23395b79828d47a8f9aeb3880aa131d83
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
We don't have logic to parse that part and it's not
even needed, because if an update is available the package
will be listed in "available packages" section. This is now
throwing errors and it's not needed.
Change-Id: I3bb65694fbef9218e5a294d9dbfd9e3f1f4c8333
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Automatically download Android SDK Tools to default path
used by Android Studio, then essential packages will be installed
using the sdkmanager tool. Automatic installation can also be
triggered by an added button in the settings page.
Essentials packages include NDK Bundle and other NDK versions
required by previous Qt versions.
An sdk_definitions.json file holds download paths for SDK Tools,
and other (Qt version <-> essential packages) combinations.
[ChangeLog][Android] Automatically download SDK Tools, NDKs and
all essential packages for Android builds.
Task-number: QTCREATORBUG-23285
Change-Id: I90e7aafecd017d2bdc959e403711d9d440a6bbb2
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
