In the configure environment for MSVC toolchains.
The MSVC toolchain actually overwrites the PATH environment (triggered
via kit()->addToBuildEnvironment(result)), which it shouldn't.
But this is a minimal fix for Qt Creator 9.0 that also is in line with
what BuildConfiguration::baseEnvironment() does.
Fixes: QTCREATORBUG-28685
Change-Id: I0cb8e3c84419403672175bd581c16d90902e23ba
Reviewed-by: David Schulz <david.schulz@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>
ANDROID_NATIVE_API_LEVEL is not handled by the android toolchain files
starting the NDK version r23b. We should set ANDROID_PLATFORM instead,
to specify the NDK platform version, that exists in all NDK versions
supported by Qt. Also the ANDROID_PLATFORM variable expects the
'android-xx' format as a value, so avoid cutting the 'android-' prefix
when adding the value to the CMake configure string.
Fixes: QTCREATORBUG-28624
Change-Id: Idd4ba472e46982162e5ad74e9fc6868e50e3b434
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This allows a project to be properly configured with Qt Creator 9 when
the build environment had user defined changes.
Qt Creator version prior to 9 had one setting for both configure and
build steps.
Fixes: QTCREATORBUG-28372
Change-Id: I0da8065085bd6628ba75923c17b46648eb031801
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Is part of CMakePrests v3, and slipped at the implementation time.
Task-number: QTCREATORBUG-24555
Change-Id: Id3ce90c0a979d44287fc03ae1dd49a64e964cdf2
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Shortens the "Run CMake" button and the cmake variables
tab header to make them easier to read on wide monitors
Change-Id: I2579a8fa1c2899ae94f9c4a72c4188dc61ecd5f9
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Previously, if you have a filter set in the CMake Settings
variable list, adding a new one would immediately hide it,
as the text filter hides the "<UNSET>" key. This made it look
like the adding failed.
With this change, new Variables are always shown so
they stay editable to user.
Change-Id: I9c2eb7f9983b23e1cd3aa50f589142551caaf56f
Reviewed-by: Cristian Adam <cristian.adam@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 a preset has a build directory set, that build directory and build
type should be displayed in the initial configuration dialog.
Change-Id: I884471cb4d482c92ab091a4043d642828318b4d2
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
When trying to configure a CMake project on a remote linux device,
there's currently PATH=/some/local/dir/for/ninja added on the ssh
command line, which won't work with the remote cmake.
Change-Id: I97adb58e4c8b33f74edcc37a7b2cfb00c764b829
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
If certain tools are not in the systems base PATH, as can be the case
on macOS where Ninja might be located in /usr/local/bin, the initial run
of cmake for a new/clean project would fail as the PATH (and the rest
of the environment variables) would not be set for a freshly initialized
CMakeBuildConfiguration.
This change fixes that by calling
updateAndEmitConfigureEnvironmentChanged at the end of the build system
initialization.
Change-Id: Ib2ebe4da60a6284548eabed124240212178c67e1
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Since we are now requiring macOS 10.14 we can remove our local
implementation of optional and use std::optional for macOS too.
Change-Id: I2bd018261b68da64f7f031a812045dd7784697e1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
This code path was used when adding a new build type from settings via
Add -> RelWithDebInfo and it would be expanded to "Release-with-Debug-
Information".
On Windows this can lead to long paths and problems.
Change-Id: Ie6ab74414778a2e723bfa08d6765292dfe6bce22
Reviewed-by: Eike Ziller <eike.ziller@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>
CMakePresets have the concept of modifying the configure process
environment variables.
Qt Creator had only one "build environment".
Change-Id: I131d54971b4bf7e5f87e680f817f93868d62ab29
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
More explicit and more potential options (e.g. "treat grid as form")
than a bool.
Change-Id: I89413efe30410160c38b0e524ba64288dde2332e
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... as "standard" ways to define line breaks and simple stretch.
There have already been too many patterns to do it.
Break() and Stretch() still work for the patches in flight, but
they are planned to be removed.
Change-Id: I9b70dcdc11244a904a496b0c55938dfb0b265fc8
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
It had a implicit vertical layout leading to unneded layout nesting
in quite a few cases. The price is an added Column { ... } in those
places where the implicit vertical layout was sufficient before.
Change-Id: I3ae1f03f9c1d691bd0c563b0447edd03ee02bbd2
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
It currently can't work for any remote setup, not just for docker.
Change-Id: I597dc9a0d51f0dafb6c45c635bef0cd047a4ab2c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Mostly unused #include's, also sort them or reduce scope.
A few namespaces, ...
Change-Id: I9ee71e07de7157c9942125672addf87dd41e78f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
ExternalProject_Add runs CMake not during the CMake run of the toplevel
project, but instead it runs CMake for the external project during the
build step. And while ExternalProject passes the CMAKE_COMMAND on to the
external project, it does not do so for the CMAKE_MAKE_PROGRAM.
Make sure that the make program is also found when configuring the
external project during the build step, by adding the path to ninja to
the build environment, instead of just the CMake process.
Fixes: QTCREATORBUG-27495
Change-Id: I672ec04881387a7411836ab94655176b7a5fb681
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@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>
... for use in the default build dir template.
Task-number: QTCREATORBUG-26147
Change-Id: I1a32d60e0d5e2db514ac315c48c615c55ccda51f
Reviewed-by: hjk <hjk@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>
Before this, if you set "QML debugging and profiling" to "Enable" and
then triggered "Re-configure with initial parameters", it would at first
not have QML debugging enabled, and only at some later point if you want
to re-run CMake with the additional options.
Change-Id: I5e8de7ebadbcb5a44b507ab9b953d4cbd8a3d063
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
By default xcodebuild does not try create / download a provisioning
profile for a project if a valid one does not exist locally
in ~/Library/MobileDevice/Provisioning Profiles, even if the
Xcode CODE_SIGN_STYLE attribute is set to Automatic.
Starting with Xcode 9, xcodebuild accepts a new
-allowProvisioningUpdates option.
When passed, xcodebuild will request a new provisioning profile
from Apple's servers for the current project and use it during
the build. The provisioning profile is only needed when building
for a real device, not the simulator.
When building an iOS project with qmake, the option is embedded in the
wrapping Makefile generated by qmake, so Qt Creator can simply call
make (which it does).
For CMake, there is no wrapping Makefile, so we need to pass the new
option explicitly as an additional build tool argument.
There might be cases where automatic provisioning is not desired,
which is why there is now a new checkbox in the CMake build step
configuration widget. It's default value is 'enabled', to match
qmake's behavior.
As an implementation detail, isiOS had to be moved to a header file so
it's accessible to both the build configuration and the build step.
Fixes: QTCREATORBUG-26246
Change-Id: Ic80cd965ba095d0ff379e13ad2ffb8c298c9f7c4
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
... 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>
