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>
CMake settings were split in two places, which complicates things.
Now they are both into one settings category, just like other build
systems Qbs, Meson.
Change-Id: I55f434d83604c9b3be111fc89014b720ee72b513
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@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>
* Added returning the Id after detecting CMake so it can be set in the autodetected kit
* Trying to keep autodetect from adding the same Qt installation twice if qmake is linked in /bin and /usr/bin
* Added FIXME for RunControlPrivate::runConfiguration as it is used after free in rare cases
* Fixed IosCompilerDetector to not just run if a device is set
* Fixed QnxCompilerDetector to not just run if a device is set
* Fixed auto-detected debuggers not being set as auto-detected, as they now can be removed from the device screen
Change-Id: Ia7772c454d70e147e4326efacc4a6a888fa26782
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
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>
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>
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>
Rename some constants to get a bit more consistency into the
naming scheme. I am so tiered of missing a constant due to it
not having _ in the expected places!
Change-Id: Ibb5e82ea4e25ccb559352839b96c8a64394f3085
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
It's what the base class wants, and follows run and deploy precedence.
Change-Id: I26eff43337851702417e7e4284fc390b904060f6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The possibly intented flexibility e.g. to have different project types
share the same idea of a common context was never used, in all cases
we had a 1:1 relation ship between project ids and ids that were used
as context. This led to oversights like the one fixed in 60fb35a2.
This patch here uses the project id unconditionally as context and
drops all context ids. If we'll ever have the situation where the
original flexibility was needed, Project::projectContext() could be
made virtual and overridden were needed.
Also, the context was never modified for any given project, so the
updating machinery is not needed.
Change-Id: I3f7fac0ed5e4704e126558987c48577f26082dfd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This in theory enables to fix QTCREATORBUG-16204, but for that the wizard needs logic to adapt
the required features for the listed kits. That is still missing.
Task-number: QTCREATORBUG-16204
Change-Id: Ia01c11bb8c8567a9fc65b06912d6836b70a0195c
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Project source tree is a same for all build configurations so it is
a good idea to keep it persistent between CMake runs, configurations
switches and so on. It safes a lot of time for big projects.
Move more operations to the scanner thread:
- Nodes filtering: skip .user files on top level of the project, skip
well-known extensions and octet-streams: In most cases these are not
required to be shown in the project tree.
- Nodes sorting
Fix small memory leak: we have .user in the scanner result. After this
node filtered out, but is not feed (old code at the
BuildDirManager::generateProjectTree()). Now .user file skips during scan
without memory allocation at all.
Allow user manually rescan project tree by call Build -> Rescan project
tree. It runs CMake and Tree Scanner together: in most cases only CMake
run requires but time to time (VCS update) full rescan also required.
Change-Id: I4a6e6c897202da557509291c79932dd7751860e5
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This allows to define snippets for CMakeLists.txt files. They can not
be used yet:-/
Change-Id: Iad68632798ecfe04018d08d284f9b5a8b0e564ee
Reviewed-by: David Schulz <david.schulz@qt.io>
Some CMake parameters changes requires to clear cache and run CMake
from scratch. Add ability to force it from the CMake configuration
dialog.
This change based on the work of Alexander Drozdov.
Change-Id: I21d8e12eec7e1f7bca560f44c43f25e4f333fcf0
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
This patch adds support for binding a specific CMakeTool to a Kit.
When creating a new Kit or loading a existing one without a valid
CMakeTool, the default CMakeTool will be set.
Change-Id: I28d0843a01c583c4b31fc680a0ec556b40cd9c0d
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Get rid of IFeatureProviders that are only telling the wizard factory
that a plugin was loaded.
Change-Id: Id12c669974a6ab98036f070e1adcae35b34ca376
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Since we want to treat them differently.
Task-number: QTCREATORBUG-12461
Change-Id: Ia72b8045390ceec693fa416f65010a4c4dbecce1
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Rationale:
a) For people not interested in CMake, the wizards unnecessarily
clutter the UI. If unhandled, this problem would get worse the more
build systems we support.
b) If such a wizard is actually used in the absence of the plugin,
nothing visible will happen after it has finished, which is guaranteed
to confuse users.
Change-Id: I070409d3185b11d2e04e33927a97843e60c657ff
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
On initial run we offer the user a choice between all the kits, which
are compatible with the cached generator. After the initial run, the
user can't change kits nor generators anymore.
Except if the builds into a new directory or adds a buildconfiguration,
then the user can choose between generators but not kits.
Task-number: QTCREATORBUG-7940
Task-number: QTCREATORBUG-7928
Change-Id: I9b663435cd2e021f7fe08379c1c487a6aebe8976
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Reviewed-by: Peter Kümmel <syntheticpp@gmx.net>
There seems to be no officially registered mime type for cmake,
so text/x-cmake is arguably "correct".
Change-Id: Ic1ddcd356fcf9f2f8d814b9f9ce32a96b78afeb2
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
Most of editors have "jump to file" or "follow symbol" actions. This
patch reduces amount of related boilerplate code.
New actions are made optional to prevent shortcut clash (both use F2).
Change-Id: I2af580ed9d6789df25f4487ba001f3b83887c504
Reviewed-by: hjk <qthjk@ovi.com>
This patch replaces generic context menu in CMakeEditor with
CMake-specific menu, containing action for file navigation
and line commenting.
Change-Id: I30c4ab5e517c77f801d2cc27561ded79dcf977a3
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
* Add a DeployConfiguration class to hold settings related
to deployment.
* Add BuildStepsList to hold a list of buildsteps
* Update BuildConfiguration to use BuildStepLists instead of
manageing lists of buildsteps itself.
* Update BuildManager to use BuildStepLists in its interfaces
* Fix fallout introduced by API changes
* Update .user file to new way of storing settings
Task-number: QTCREATORBUG-1427
Task-number: QTCREATORBUG-1428
Task-number: QTCREATORBUG-1811
Task-number: QTCREATORBUG-1930
