They are marked as obsolete in CMake 3.27 and will be removed in a
future version of CMake.
Fixes: QTCREATORBUG-29603
Change-Id: I6e5d36441d05b87ee4467d13781f53d4269636ad
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Qt Creator would do a compiler probe for CMake presets when the compiler
was not set.
But the same needs to be done when the generator is not set. Otherwise
Qt Creator would set a different generator by default. On Windows is
"Ninja".
This is different from what CMake does from command line.
Task-number: QTCREATORBUG-28693
Change-Id: I96e917b11561a042f9476bad302f3f153e37bafd
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
When CMAKE_TOOLCHAIN_FILE and CMAKE_PREFIX_PATH were both set, the later
was ignored.
This resulted in Kits being created without Qt and without Qml
Debugging.
Task-number: QTCREATORBUG-28982
Change-Id: Ib45b4ac8335391f85a0b9c321196597d1c0a7a3f
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
The CMake presets will be reloaded. The preset kits will get the CMake
configuration cleared (no more CMakeCache.txt)
All the kits will be removed from the project, so that the Kit
configuration wizard will be displayed at the end.
If a normal Qt Kit was configured, the user will get the chance to
import the existing configuration (the initial configuration will be
lost though).
Change-Id: Ieda83098d7716913d7870b67ab522705da4ed93b
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
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>
Qt6_DIR and Qt5_DIR CMake variables are additionally checked for
existence.
Qt6_ROOT and Qt5_ROOT are taken into consideration for both environment
and CMake variables.
CMAKE_PREFIX_PATH is also returned from the qmake probe. This fixes the
case when qt.toolchain.cmake is used exclusively.
Task-number: QTCREATORBUG-29075
Change-Id: I6e0c3adf7f5d9860a1cb776371e66dea1dfc26cc
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This reverts commit ca04d9afcd.
GCC 9 or later is the minimum required version nowadays, so this piece
of code can be more readable.
Change-Id: I939ee6cd62572d23d5b1de8d113472136752a590
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This fixes the case when a CMake variable (CMAKE_PREFIX_PATH) would
reference an environment variable (qt_path) that would contain a CMake
preset macro (${sourceDir}/../qt_install).
Fixes: QTCREATORBUG-28606
Change-Id: Ib6239b13782b2ea854969547af46c3fe82a061f4
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
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>
Specifies the main purpose more clearly. The remaining ones a "true"
(internal) variants in models and as action data.
Change-Id: I8dd3c846e419f29d88283c2f48268ef6685b19fe
Reviewed-by: Eike Ziller <eike.ziller@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>
You can have a preset with the PATH environment variable modified and
with CMAKE_C|XX_COMPILER CMake variables only as "gcc.exe" and "g++.exe"
Qt Creator now will search in PATH after the compiler file names and
work as expected.
Fixes: QTCREATORBUG-28602
Change-Id: I8520f6fcf5e542600fab08228d04d3709d3a8e8f
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This way the CMAKE_PREFIX_PATH set to $env{HOME}/Qt (Linux) or
$env{SystemDrive}/Qt (Windows) would work as expected.
Change-Id: I03a9102d6d1da2a8740cab738577c47c44166c6c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
For CMakePresets if a preset is broken we should not create a preset kit
for every build type.
Instead reuse the broken kit created by the first build type.
Task-number: QTCREATORBUG-28295
Change-Id: I038fbb23817834f59ac73ccd2f9953f1a412b656
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
This allows presets that do not have a generator specified to proper
work.
On Windows CMake will detect "Visual Studio" as generator. This change
sets the generator and the architecture values accordingly.
Change-Id: I943e082430445c4b16cf9eaf4ae5ae2500b2bd2b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
This doesn't mean that CMakePresets will work with a remote project, but
at least it avoids Environment::systemEnvironment() usage.
Change-Id: I17081c747d32e50224ac74507d3aa336ff5c8948
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Restrict the build types only if CMAKE_BUILD_TYPE or
CMAKE_CONFIGURATION_TYPES cache variables are set.
Change-Id: Ib88dcd5d4a0fca86f86e95815edff1116f896324
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
CMakePresets v3 relax the requirement of having the buildDirectory
specified.
This way Qt Creator should use its own mechanism of specifying the build
directory.
Change-Id: I6ba69e6a03cdc058e7b8fa540a6fc564356aba63
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
If we configure a project with presets, build all the configurations,
then delete the CMakeLists.txt.user file to re-configure the presets, we
shouldn't get two entries in the initial configuration dialog.
Change-Id: I9bb234aa54fcce193dbd07dd3aa77e91f639b179
Reviewed-by: Alessandro Portale <alessandro.portale@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>
This fixes issues with Visual C++ generator, which needs the right
parameters to pinpoint the right compilers.
Also use CMAKE_TOOLCHAIN_FILE for qmake detection.
Change-Id: I6edc84c7ed1a892fbc5545ff61dc06ac20720f0a
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Proliferates FilePath use a bit further. Actual changes to the
individual importers are left for further patches.
Change-Id: Ie7c6b2e3f4ac7d0eca6d2f56d30fb23354bb404b
Reviewed-by: Cristian Adam <cristian.adam@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>
When importing a CMake build, the CMake version that's used in the build
could be registered as "CMake 0.0.0". This is obviously wrong.
Fixes: QTCREATORBUG-26999
Change-Id: I1401106806c4356516e8235a3767d9615e4d428d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
After parsing the CMake response, we make the configuration variables
table reflect the actual configuration in the build directory. It is one
of our "promises" that we do not break an existing build configuration,
to avoid unexpected rebuilds.
This was not quite true for the "QML debugging and profiling" setting.
When that setting and the actual build directory disagreed, the user
would get a dialog asking for running CMake with additional parameters,
and when running CMake via the button in projects mode or the menu, it
would just change these configuration parameters, potentially leading to
an unexpected complete rebuild of the application.
So, after parsing check if the actual CMake configuration matches our
QML debugging setting, and if not, change the setting to "Leave at
Default", to ensure that we don't mess with the build.
Fix the "Run CMake" button state (in the "Current Configuration") when
changing the QML debugging option, which should become bold, if the
CMake parameters change.
Amends 2577ce8ba1 and fixes the drawback
mentioned there, i.e. setting the build directory of a "Debug" build
configuration to an existing build directory with QML debugging
disabled, will now simply set the QML debugging option to "Leave at
Default" instead of forcing it to "Enabled".
Change-Id: Ie6d4875d59319687d94e44e459ca76038e5813c0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
