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>
... from CMakeBuildConfiguration to CMakeBuildSystem.
Less back-and-forth this way.
Also, prefer plain buildConfiguration() over cmakeBuildConfiguration()
back-pointers.
Change-Id: Ie1341302ecc10e53d71ca68b7b6eb5f46cfdad5f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Most inclusions of idevice.h inside other headers are
required just because of IDevice::Ptr or IDevice::ConstPtr
was used there. Unfortunately, since these "using"
are defined inside a IDevice class, we just can't
forward declare IDevice::Ptr nor IDevice::ConstPtr.
Instead, create a separate header that defines
IDevicePtr and IDeviceConstPtr while having IDevice
forward declared. Redefine IDevice::Ptr/ConstPtr
inside IDevice to use IDevicePtr/IDeviceConstPtr.
Now, instead of forward declaring a IDevice::Ptr
it's sufficient to include the idevicefwd.h.
This drops the number of files being recompiled
after touching idevice.h from ~770 to ~210.
Change-Id: Ib6f2982aa0761fb4cd6593badb9c3c0c527ea535
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
These calls would make interactive changes useless and the fake hide
event would remove the interactive flag which would prevent the user
from doing any changes.
Fixes: QTCREATORBUG-27257
Change-Id: I80a53d8955ac2329c726989954f1d910e93b3501
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
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>
A tab bar should span completely above the group that it "tabs", and
have no spacing to it. Otherwise there are funny visual artifacts, and
the visual correspondance is not clear.
Add an option for spacing to LayoutBuilder for that.
Change-Id: I5ca9dc713fff95599c9ec1cf90abe8473bc67c2a
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@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>
