... by some out-of-band mechanism, keeping previous functionality.
The driving reason is to get the same fromMap signature as in the
AspectContainer base, however, the whole mechanism seems rather useless:
There are only a few places that actually ever could report errors,
in those places "moving on" looks ok, too, and these few places
are not conceptually different than a lot others.
Removal of this (new) mechanism is left for later.
Change-Id: Ibe7a0456bc3b84a84e942231f14446e783372d76
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
To match better with the rest, especially the base AspectContainer.
Change-Id: Ide0966cab3219800aa6b7b9e6012731a3fbe7a6f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Not quite harmless, as it was destroying persistent data written by
the normal one.
Amends b9cf021b8e.
Change-Id: Ie2775881535c4d19174177f443a4606acc1576de
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This avoids some repetition and could be a step towards
having type storage in (or rather accessible from) the base,
so we can have aspects for more complex data (treemodels...)
that are not easily converted to QVariant.
Change-Id: I9797b3d5646195705212db1830d2b415291ac651
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
EnvironmentAspect is used in the Run configuration page.
For a configuration not using presets the "Build Environment" will be
used by default. This is the pre Qt Creator 9 behavior.
With presets "System Environment" is used, which allows the environment
sepparation of configure and build steps.
Fixes: QTCREATORBUG-28513
Change-Id: Ie65c0a5ac67355642460fca9fc618a1d29f4b1bd
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@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>
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>
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>
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 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>
... 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>
Now we have "Initial Configuration" and "Current Configuration"
as tab bar buttons.
This way the UI can be shared between the two configuration states.
Task-number: QTCREATORBUG-26869
Change-Id: I8206032a2a5ac076629865057816edb99706f2ff
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Previously the only way to stop the CMake run was to click on "x"
button of the "Configure" progress bar.
Now you can click in Settings on "Stop CMake".
Change-Id: I167b86ba62679f197c194148b122ff0c87e87162
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The following variables:
"CMAKE_C_COMPILER",
"CMAKE_CXX_COMPILER",
"QT_QMAKE_EXECUTABLE",
"QT_HOST_PATH",
"CMAKE_PREFIX_PATH",
"CMAKE_FIND_ROOT_PATH",
"CMAKE_PROJECT_INCLUDE_BEFORE",
"CMAKE_TOOLCHAIN_FILE"
will be checked to see if the existing values have the same values
from the initial cmake parameters list.
Only the CMakeCache.txt values that do not exist on the file system
will be updated.
If not, the updated value will be presented in the dialog for upgrade,
or marked as bold in the settings dialog.
CMAKE_PROJECT_INCLUDE_BEFORE is dependent on Qt Creator version / path
and needs to be updated.
Fixes: QTCREATORBUG-24443
Change-Id: I1eeb44df3a7914051084ef405af5f5621cc5a4e2
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The multi configuration generators (Visual Studio, Xcode) had an
empty "Build type" which caused failures to parse the CMake file-api
information.
Change-Id: I70ee4978cee4d43e980edf4cd512d1ca95275638
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
For single configuration projects if you change the build type
aspect you will change the CMAKE_BUILD_TYPE variable.
When switching the build directory the existing CMAKE_BUILD_TYPE
will be set as build type aspect.
Fixes: QTCREATORBUG-25451
Change-Id: I13519e95c316c556cc1348fba6121637d2fd4275
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
CMake's fileapi functionality will save the project structure in json
files in the .cmake/api/v1/reply directory.
When issuing a cmake command with -D variables CMake will update its
CMakeCache.txt file even if cmake will fail.
This commit will rename .cmake/api/v1/reply as .cmake/api/v1/reply.prev
and make a copy of CMakeCache.txt before starting CMake, and if
something fails, replace the existing files with the previous values.
Also make sure the changed values are not dissappearing when the
old .cmake/api/v1/reply gets parsed.
Fixes: QTCREATORBUG-24593
Change-Id: I82141786fea7068699e0f761a8978ba1f3203e47
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Adds the signing settings to iOS configurations.
Adds placeholders for signing flags to the initial CMake arguments, and
updates the CMake configuration when signing settings change.
The new configuration doesn't get automatically applied. Only the "Apply
Configuration Changes" button gets enabled and the user has to press
that explicitly. This seems to be a more general issue affecting the QML
debugging setting too, though.
Task-number: QTCREATORBUG-23574
Change-Id: I3e8d45f565347e1ad2ac274a21b1552f1510e8f4
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
CMake has multi-config generators like:
* Visual Studio
* Xcode
* Ninja Multi-Config
The first two have different special targets for "all", "install",
"package", "test" namely: "ALL_BUILD", "INSTALL", "PACKAGE",
"RUN_TESTS".
All of them need to get the build type passed via "--config <build-
type>" and not via "CMAKE_BUILD_TYPE".
The multi-config generators will use only one build directory.
Fixes: QTCREATORBUG-24984
Change-Id: I8aa7ff73ce2af1e163b21a6504d26fcf95530edf
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The CMakeCache.txt file has CMAKE_HOME_DIRECTORY pointing to the
project source directory used to configure the project.
When importing a cmake build the CMAKE_HOME_DIRECTORY from
CMakeCache.txt might not point to the same CMakeLists.txt that was
opened as a project.
qt-cmake-standalone-test from Qt6 uses a CMake template project which
does a add_subdirectory with the test source directory, which will not
work if opened standalone.
Normally this is a user error though, so ask the user if this was
intended, before actually importing the build.
Task-number: QTBUG-88776
Change-Id: Ifdd5e1d1cb8a1ef9955d22493eba3a1a55dc689f
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The latest libClang gives us following warning:
cmakebuildconfiguration.h:104:18: warning: unqualified friend
declaration referring to type outside of the nearest enclosing namespace
is a Microsoft extension; add a nested name specifier
Deleting is the right fix.
Change-Id: I4ccccf286044ca45ec78b0ea03a4ce8d979f06b4
Reviewed-by: hjk <hjk@qt.io>
Classes involved are BaseAspect and some derived classes,
LayoutBuilder and VariableChooser.
This is mostly mechanical, with various include/using changes
to make it compile.
Change-Id: I624a457f3555f102e541c4c71e33a9423af32250
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
In most cases they are used directly, so there's not much Base* in that.
Added the old name as alias as porting help for a while.
Change-Id: I494a8a560b8996bcf74915ea3570b504df6a6b4c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Get rid of magic configuration handling in the CMakeProjectManager.
* Use CMakeCache.txt as the sole source of truth, do not keep
a shadow copy of configuration in the .user file
* Have initial CMake arguments that are easy to edit in batch
(Fixes: QTCREATORBUG-18179) used whenever no CMakeCache.txt
file is in the build directory. These allow for any thing that
can be passed to CMake on the command line.
(Fixes: QTCREATORBUG-16296)
* Ask when changes to CMake configuration were not applied
(Fixes: QTCREATORBUG-18504)
* Run cmake with arguments effecting its configuration only when
the CMake settings are changed in the UI, run CMake without any
special arguments in all other cases.
* Get rid of the confusing dialog used to keep settings in sync between
what is in CMakeCache.txt and Creator (Fixes: QTCREATORBUG-23218)
Change-Id: I26d55be7df733f084f5691ecf7d7b4352f58b8e7
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The BuildDirManager was used to switch between different
BuildDirReaders. Now that only the FileApiReader is left, that
infrastructure is no longer needed.
Change-Id: I2d339a3407bb633cff6a8f7502b7b09094f63fef
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Keep internals internal, remove some unnecessary includes, add
some that should have been there.
This reduces the number of files that get rebuild when working
on CMake internals from over 1000 to about 200.
This patch also moves some code around that ended up being
in the wrong file.
Change-Id: Icd7366ac760dc85031040720418fbb16336dce9b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
I can't spell occurred:-/
Similar typos in 3rd party code (sqlite) has been left in place.
Change-Id: I7cfa9911fc434d42ce3df8e9c7ccb83dc00401e8
Reviewed-by: hjk <hjk@qt.io>
There should not be a need to have the linkQmlDebuggingLibrary Q_PROPERTY
anymore. The property is added for the benefit of the DebuggerAspect, which
can just check relevant BuildConfigurationAspect directly.
Change-Id: Ic47ca9e26911e096564fe77bd14bebe959b4f116
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The current implementation does not help the user and is not in sync with isEnabled(),
so it is not helpful to have.
Change-Id: Iddde1ac3da24d50e8a16d2bd4c6aa56eef34ef50
Reviewed-by: hjk <hjk@qt.io>
