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>
When configuring a CMake project on the command line, CMake will
(correctly) find and use the compiler from the current developer
directory, usually somewhere in
/Applications/Xcode.app/Contents/Developer
But Qt Creator auto-detects and sets up the compiler /usr/bin/clang(++)
for desktop kits. This leads to a compiler mismatch between kits and the
imported build, and to new kits registered in Qt Creator for the import.
Since /usr/bin/clang(++) is just a thin wrapper that resolves to the
compiler in the current developer directory, resolve that in Qt Creator
with "xcrun -f <command>" too (caching the result), and include that
when comparing toolchains for importing builds.
Fixes: QTCREATORBUG-27591
Change-Id: I301e2a4e267450b488b49d0c32d4ce89001bb5ec
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Get rid of the hardcoded QML Debugging for Debug & RelWithDebInfo from
the project template, because RelWithDebInfo is actually a good
configuration for doing releases (we use it for Qt Creator), and
enabling QML debugging for releases is a bad idea.
Instead enable QML Debugging in Qt Creator for the Debug configuration,
and add a 'Profile' configuration that is 'RelWithDebInfo + QML
Debugging'.
When importing a build, we only set the "QML debugging" option of the
build configuration, if it is enabled in the imported build, even if it
uses CMAKE_BUILD_TYPE=Debug .
One drawback: When not importing a build, but just setting the build
directory of a "Profile" or "Debug" configuration to an existing build,
Qt Creator asks if it should apply "-DCMAKE_CXX_FLAGS=-DQT_QML_DEBUG".
The user can choose not to, but then is asked the next time again, and
it is not obvious that the "QML debugging" option is responsible for
this.
That is somewhat orthogonal to this change though: Even without this
change, if the user changes the QML debugging option from "Leave at
Default" to "Enable", the same happens, and it is also not clear to the
user how to get rid of it. The user might not even have realized that
they changed the option (e.g. on platforms where the mouse wheel cycles
combo box values).
I think the correct solution is to 1. make clearer where the CMake flags
came from in that dialog, 2. allow the user to cancel a build from that
dialog, 3. allow the user to discard these changes (by changing the
setting) from that dialog. But that is for another patch.
Amends 3300182d40
Amends 77fed0b0fd
Change-Id: I95de59473b67c5afd6a53ea7f49838dbaef770d4
Reviewed-by: Artem Sokolovskii <artem.sokolovskii@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
... by direct use of CMakeConfig::fromFile(). It was only duplicating
checks that are done on the user side already.
Change-Id: Iaf5e89c924c2b0a9080db9fe160970bbf6e33154
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
... into a single class.
This makes passing them around as a whole easier, and opens a path
to have "generic" filters in form of a lambda or such.
Change-Id: Ibf644b2fedcf0f1a35258030710afff8f5873f88
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Less conversions cycles at the price of a few more temporary bytes.
Change-Id: Ibda82e02d7b83944f5db38ac7cf75c4bae4f55ec
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
