KitAspect -> KitAspectFactory
KitAspectWidget -> KitAspect
KitAspect::createConfigWidget() -> KitAspectFactory::createKitAspect()
Possibly not perfect yet, but closer to what it does and is.
There will be follow-ups to rename derived classes.
Change-Id: I226f6f025f1e6462c348b68663f776f5a2e8c42d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Most information is available via Q(Core|Gui)Application.
Add an AppInfo structure for the things that are not.
This avoids that the information ends up duplicated and
hardcoded in the plugins, which is not needed or desired.
Change-Id: I4d565e75c42a7b8facafa90c27096ea49359215d
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Intenally just wrapping a 'bindTo' result, but less trigger potential
for pointer related peladophobia
Change-Id: I25171a2675fb0474ce97c04552ac1cf5ffd6ee56
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: hjk <hjk@qt.io>
QTC_KIT_DEFAULT_CONFIG_HASH was introduced in order to match the
previous CMake presets kits.
This would hash the Qt and the C/C++ compiler paths.
Unfortunately on Linux CMake would pick "cc" and "c++" by default,
whilst Qt Creator uses "gcc" and "g++". The compilers would match from
the Qt Creator point of view, but the hash values would be different.
On mac there is a similar issue with compiler launchers.
This patchset fixes this by removing the hash and fixes also the issue
of allowing broken CMake presets kits (without any compilers), which
were the reason for introducing the hash key in the first place.
Fixes: QTCREATORBUG-29075
Change-Id: Id8dc081febba7bc7023c98055afc6ebfcdc55542
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
LayoutBuilder is meant to be an implementation detail nowadays.
Change-Id: I777ab934d3d405873e819eeddd27428d8c652f9a
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The whole machinery is now almost only layoutbuilder.{h,cpp},
mostly independent of the rest of Utils. Idea is to finish the
separation to make it stand-alone usable also outside creator.
Change-Id: I958aa667d17ae26b21209f22412309c5307a579c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Basically a.onDevice(b) == b.withNewMappedPath(a), matching the order
of b.withNewPath(a).
Whether the (curretly docker-specific) path mapping is useful /there/, and
whether some of the calls are needed at all is dubious. I added some
FIXME and changed a few cases directly.
Change-Id: I7514736ce922f632f1f737bc496f6783389a42b6
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Amends a3153c535d
QT_QMAKE_EXECUTABLE was not taken into consideration and this would
result in not matching kits.
Also Visual Studio generator will not have a CMAKE_C|XX_COMPILER values
in the cache.
On Windows there could be paths with "C:" vs "c:" and the hashes again
wouldn't match.
Change-Id: I5da5fafbd29f3d1fd8c9615c41b7659e63c30ff1
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Originally the idea was to only expose LayoutBuilder, but we
are getting more and more related items. Be consequent now,
and have everything in Utils::Layouting, but not in nested classes.
Change-Id: Ic0f98595882e5c60a25c30ec52df4a0ea79bc0ca
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
This adds a QTC_KIT_DEFAULT_CONFIG_HASH variable containing the hash of
all the default Qt Creator CMake kit variables:
* CMAKE_C_COMPILER
* CMAKE_CXX_COMPILER
* QT_QMAKE_EXECUTABLE
* CMAKE_PREFIX_PATH
This way when a CMake preset changes any of these CMake variables a new
Kit will be created. Otherwise a previous kit containing different
values will be used.
Fixes: QTCREATORBUG-28609
Change-Id: I77b67e9c8fa15dc3ff2f22c5b63d4ca1c7670fdc
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
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>
This commit adds a "CMake Install" deployment step, which is using
"cmake --install" command.
"cmake --install" command has been added in CMake 3.15, this is why the
minimum CMake version has been updated to 3.15.
Note that CMakeBuildSystem::makeInstallCommand is still using cmake --
build --target install due to a CMake bug regarding "Ninja Multi-Config"
generator, which doesn't intall all binaries via "cmake --install".
Fixes: QTCREATORBUG-25880
Change-Id: I504674c380055d8ef136d344a78b80c17ecf9765
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
CMakePM was setting the default generator to Ninja if the ninja
executable was set in the build environment.
This had the side effect of having to instantiate the build environment
for Visual C++, which meant running vcvars.bat files. This operation can
be costly if clink is also installed in the system.
This way the users that have ninja installed via choco, or manually set
it path, will not be affected by this delay.
Note that this only fixes the issue for the first start of Qt Creator
with new settings.
Some number from my machine:
- with clink 21s
- without clink 10s
- with this patchset 4s
Task-number: QTCREATORBUG-27906
Change-Id: I74d19b08211d93b3962a8877b49a58089310fbd6
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
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>
The values coming from a CMakeConfig do not contain
the device they are relative to.
This transforms the FilePath to be relative to the device
that the cmake executable was run on.
Change-Id: I7bfdf065ddb4acfc751ac6456f1c32398393e2ad
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
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>
CMake settings were split in two places, which complicates things.
Now they are both into one settings category, just like other build
systems Qbs, Meson.
Change-Id: I55f434d83604c9b3be111fc89014b720ee72b513
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Currently if no CMake has been registered and a CMake project has been
openend the user will get the error:
"CMake version is unsupported. Update to version 3.14 (with file-api)
or later."
With this patch the user will get the error:
"The kit needs to define a CMake tool to parse this project."
Change-Id: I555884fff1eac321052998d1ef7970a49b2f44af
Reviewed-by: hjk <hjk@qt.io>
The patch breaks several plugin unit tests; at the very least QtSupport,
AutoTest and ClangCodeModel.
This reverts commit 72aa77ced7.
Change-Id: Iaa7f452d0f43d0072b0bbcf8934fa0dcd6f9b240
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
qmake is a "build tool", and it is also a "query tool" when called with
parameter "-query". Qt Creator, so far, assumes that building and
querying with a Qt installation are done with one and the same tool:
qmake. This change adds the ability to register a Qt version vie either
qmake or qtpaths and still build with qmake, if that is installed (which
is not anymore mandatory from Qt 6 on).
1) Distinguish between Qt query tool and qmake build tool:
Add QtVersion::queryToolFilePath() to the existing
QtVersion::qmakeFilePath(), and use queryToolFilePath in most "query"
related code, and qmakeFilePath when building with qmake (e.g. in
QmakeProjectManager).
Also, a couple of functions and variables were renamed from *qmake* to
*queryTool* in order to express that the affected code is about
querying/managing Qt versions rather than about building with qmake.
2) Support manual Qt Version adding by qtpaths via file dialog
This change adds qtpaths to the "Add" Qt Version file picker filter.
After selection, "qtpaths -query" is executed for testing purposes. If
that fails, (e.g. because it is an older Qt version), qmake is instead
chosen, silently.
Task-number: QTCREATORBUG-22175
Task-number: QTCREATORBUG-25546
Change-Id: I4d9c1e7eec7d5ae7c5a8d2e1a1ed95addff69966
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Added returning the Id after detecting CMake so it can be set in the autodetected kit
* Trying to keep autodetect from adding the same Qt installation twice if qmake is linked in /bin and /usr/bin
* Added FIXME for RunControlPrivate::runConfiguration as it is used after free in rare cases
* Fixed IosCompilerDetector to not just run if a device is set
* Fixed QnxCompilerDetector to not just run if a device is set
* Fixed auto-detected debuggers not being set as auto-detected, as they now can be removed from the device screen
Change-Id: Ia7772c454d70e147e4326efacc4a6a888fa26782
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
There were cases when an empty "-D" CMake command line parameter would
be genered, resulting in a failed CMake project configuration.
Task-number: QTCREATORBUG-27256
Fixes: QTCREATORBUG-27237
Change-Id: Ic26c9dfe72db154cd76fdcc913eb7fe623b3123c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
CMake fails if it has -DCMAKE_GENERATOR:STRING=CodeBlocks - Ninja
It expects separate values:
-DCMAKE_EXTRA_GENERATOR:STRING=CodeBlocks
-DCMAKE_GENERATOR:STRING=Ninja
Fixes: QTCREATORBUG-27060
Change-Id: Ia2b5bdc425e569118d689b7223fbef5f953d98a7
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The CMAKE_GENERATOR variable in "Initial Configuration" didn't get
the Kit value after a change in the "Kit Configuration" dialog.
Change-Id: Ieb9d634e2e9b1a5522b189e16bb66f8cea4c63b1
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Use FILEPATH for CMAKE_C|CXX_COMPILER variables, and PATH for directory
variables like CMAKE_PREFIX_PATH.
Task-number: QTCREATORBUG-27005
Change-Id: I906de43ab97d2dbad0374469c4576d901d2f6339
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
