Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Use FilePath::refersToExecutableFile() instead.
This makes it better re-usable for remote setup.
Change-Id: Ic69739b332f036ed791adbbc8092a139b4c83c2d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
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>
And instead of qgetenv.
Takes Qt Creator's setting at "Environment > System > Environment" into
account, which makes it easier on some platforms to set them (e.g.
macOS), can be configured differently in different settings paths, and
potentially can be changed at runtime (depending on usage).
Change-Id: I2217f13336ec816d28bd447ccd14a405bff2a3a7
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
Also when reading settings. Check was there for writing already,
and possibly should not exist at all, other kit settings are not
purging at that stage.
Change-Id: Ia052efd5a791f4a86be3d26a61ebeb94d506b012
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Otherwise we may easily lose registered tools if the device
is currently not available.
This happens e.g. if the docker daemon is not running.
Change-Id: I10156d749bf33d7d789c3fad78bf3acdf1f6fd74
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Similar to QT_RESTRICTED_CAST_FROM_ASCII to avoid the need for
decorations in user code.
At the same time, drop some convenience constructors and functions
in CommandLine and Icon essentially serving the same purpose.
Change-Id: Ida4e5ac19c2da0a4298a97b2a8e1511d56bbb79d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
So far this only worked accidentally for cases where a local cmake
was available in a similar place.
Change-Id: I089d2774b3fde00cf369b5524bb98023b6f1aadb
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
When storing the cmake tools we otherwise drop auto detected
ones when failing to access them locally.
This makes the cmake tools on docker devices persist on Windows
as long the docker daemon is running.
Change-Id: I5235cf00aff49359a2e20ddc1667bcbb99337092
Reviewed-by: hjk <hjk@qt.io>
If you had an auto detected CMake tool from the sdk you would
not be able to change the "Autorun CMake" state from ON to OFF
because the sdk value would always be used instead of the
user one.
Fixes: QTCREATORBUG-25911
Change-Id: Ibe3b393a2b9e4d397251018fda8a9508ad096791
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Drop top-level static of consts, namespaces.
Change-Id: Ibc902e41278b78843a8f5aeced8321e76296ca1b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Saves some code on the user side.
Change-Id: I32cd220b6e533f5497a1865f9c34ab9db4cfda79
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Keep internals internal, remove some unnecessary includes, add
some that should have been there.
This reduces the number of files that get rebuild when working
on CMake internals from over 1000 to about 200.
This patch also moves some code around that ended up being
in the wrong file.
Change-Id: Icd7366ac760dc85031040720418fbb16336dce9b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Also search in "ProgramW6432", so that a 32-bit Qt Creator on a 64-bit
Windows can find a 64-bit CMake installation.
Change-Id: Ia02a8a3e2308fa0dfb422df6969c8313868d3ce6
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Running CMake via a non-canonical path (including '..' in the path, or
via a symlink) can result in funny errors.
de6faa0f15 added a warning for that
condition. Unfortunately the auto-detection of CMake can return a path
to a symlink (e.g. for CMake from brew on macOS). Also it is helpful to
use a symlink to e.g. manage different CMake versions.
Instead of warning about the condition, and forcing the user to resolve
it manually, simply run CMake via its canonical path when actually
running it from Qt Creator.
Change-Id: I95623b45c5436a6d61c1419b7aba23e2a73a0650
Reviewed-by: Tobias Hunger <tobias.hunger@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>
