If the devices have not loaded yet, trying to restore
a remote cmake will result in errors.
Change-Id: I08a802441d64b203388334e5cbb6b962d1f0d213
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
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>
Avoids some roundtrips asking for ProjectTree::currentNode()
which traverses the project tree every time.
Change-Id: I650728eab5a47a7f4760cf88844a4b7106365255
Reviewed-by: Christian Kandeler <christian.kandeler@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>
... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
First step, move {DesktopQt,Qbs,CMake}RunConfiguration{,Factory}
into the same new files.
This only moves down to QtSupport, not ProjectExplorer, as there
are in all three cases direct dependencies on QtSupport. Long term
I would expect them to move further down.
Change-Id: Ib16b19df7f3f642ed7f7db89a1f6904601d976ba
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Add a "cmo" filter to the locator that will open the CMake target
definition in the editor.
Note that this is based on the target data extracted from cmake. For
tealeaf-reader and server-mode this information is guessed based on
the targets source directory (plus CMakeLists.txt). These modes will
just open that file.
For fileapi the information is accurate and based on the backtrace
that comes with the target information. "cmo" will open the exact
file/line from the backtrace here.
Task-number: QTCREATORBUG-18553
Change-Id: I4ee0eb25d1d763bd0d8033e506bf85cb2bc1f2dc
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Split up CMake's locator filter into a part that contains all
the logic to find targets and a part that handles the action.
This is so that the code used to search for targets can be reused
later.
Change-Id: Ife6c9fe6a6f1955bedaa1b9298630c052e17c33f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Make virtual function implementations final while touching the file.
Change-Id: I94c44ee3efbc9beb39789dd198ee607791a9a44d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
For consistency, it's straight forwards access, similar to
currentProject, not much to search and find.
Change-Id: I7ce696bdc24b6a8713d6f11e02443a6f94c605f6
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... of SimpleRunWorkerFactory.
This requires being explicit about the SimpleTargetRunner worker
default, but makes the template re-usable for current users of
RunWorker::registerWorker() which I would like to phase out now,
for less variations in the RunWorkerFactory setup.
Change-Id: I32638437e5bb29f143650f5fde706711ab25accf
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
CMakeToolManager instance must be created first to avoid connects
to a nullptr.
Change-Id: If8738a26d58c80ffc9a63193240895f1bc9a87ae
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and use in as replacement for RunConfiguration::addRunWorkerFactory.
It is still convenient to have a simple way to set up run worker
factories for the typical "just run for this configuration" case,
but it's even better if it follows the nowadays predominant pattern
of keeping factories in the plugin's pimpl.
Also, it turned out there were two copies of
QmlProjectRunconfigurationFactory code, one is enough.
Change-Id: I0b28c4ea18d0f52165a49f6133dc8687a3b9c7cf
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Also, construct the KitManager implicitly when the first
KitAspect is created. Ramp-down is still explicit and
somewhat odd.
Change-Id: If1506e1d0789ecabbaad2d8008851d0b42c5218b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@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>
That should save some memory per node, and since creator has a lot of nodes
(e.g. opening the LLVM project adds about 1 000 000 nodes) this should be
noticeable:-)
Calling update inside ProjectTree::currentNode() and rename it to
findCurrentNode() to make sure it is an still existing pointer.
Also, try to reduce the somehow more expensive currentNode() calls
and sprinkle some const around that usage.
Change-Id: I6a7c5db01a71d53d39544d3013cad557d5b96cdc
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
- Avoids the hassle of QRC files and manually registering mime types
- Avoids performance regressions because of mime types that are
registered after mime database has been used
- Makes it technically possible to detect that a disabled plugin could
handle a mime type if it was enabled
Change-Id: I373008b1b56e9c6b4853055f20b3eeb112a6eff9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
This discourages storing the pointers needlessly. The items
are still easy accessible by the static ProjectTree::currentNode()
Change-Id: I3c0cd019e9fdc382afacbc9d9de3b97d5f58ae1e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The old code was disconnecting all signals from CMakeProjectPlugin
to m_buildTargetContextAction. The result was more and more triggered
actions.
Change-Id: I8d7db5852c03d5388870a7460efb3a8a28fd0749
Reviewed-by: Florian Apolloner <florian@apolloner.eu>
Reviewed-by: Alexander Drozdov <adrozdoff@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
It crashed if the root project had some error
and I tried to build a subproject.
Change-Id: I13dc620402a5f79e507e7da3fedb5eb09a4112da
Reviewed-by: Alexander Drozdov <adrozdoff@gmail.com>
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>
Do not push the cmake running straight into the face of the user. Do it
in the background instead.
This needs some follow-up patches to become really useful.
Change-Id: I3457178b33e3f14bdeac25005a773d17abb73b65
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Add CMakeConfigurationKitInformation and supporting classes.
This KitInformation can hold CMake settings that are to be applied
for all configurations when this kit is used. It contains e.g.
the Qt version and toolchain configured in the kit by default, but
can be extended to hold more.
The UI will warn if the toolchain or Qt version set up in CMake
does not match up with those used by the Kit, but it will allow
the user to proceed.
Change-Id: I73f06a6535ce14de323130d74af83b9cb2ec0f0f
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com>
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
* Shorten header guards
* Use override and auto where possible
* Remove useless destructors, etc.
* Remove private slots sections, unify private: sections
* Use member initialization where it makes sense
Change-Id: I00eaf6d706adc16859176d1b68c631d3336bb39f
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
This patch adds support for plugins to register a callback/lambda
to autodetect CMakeTools that would not be found by the default auto-
detection function. Without this feature the CMakeToolManager would
drop autodetected CMakeTools otherwise on every start.
Change-Id: I23b146e5b9acc60018ac87ea4b6cc7573fa0dd30
Reviewed-by: Daniel Teske <daniel.teske@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>
This patch add the CMakeToolManager, a central repository for cmake instances.
One instance is always the currently used "default". By that its possible to
switch between different cmake installations. The next step will be adding
it to the Kits.
Change-Id: I310fdd805e0ed239077a5632303e891dbd1d9ea1
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com>
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
