If a build preset doensn't reference a configurePreset, the preset is
invalid but Qt Creator crashes.
Task-number: QTCREATORBUG-24555
Change-Id: Ibf5dd7f1bb165d8b7f392e6a1aaa043548bb0f7a
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@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>
... from Project to BuildSystem.
More direct and less use of Target::activeBuildConfiguration().
Change-Id: I148381d23be0f9ab0750ed1440e1b2b3e25aded0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
That's implicit in .onDevice() since c82e3cf6a8, doing it twice
is not good.
Change-Id: I8c1d5d31d155d3a7c4af8bd874fbba5ab3e8cf72
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
If a project fails to load it will be displayed with a warning icon.
If the CMake configuration fails and the backup configuration is
restored, the project is also marked with a warning icon.
Change-Id: I95ccc5d171f5b789fe317fbb1da9e13dcd81a5dd
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Qt Creator will do an update of run configurations after a project
configuration.
If an always created target was no longer existing, it shouldn't be
part of the run configuration.
For some reason this was not the case for CMake projects.
With this patchset if a target's name is changed, the previous target
name is no longer part of the run configuration.
Fixes: QTCREATORBUG-25906
Fixes: QTCREATORBUG-24914
Change-Id: I086a2540eaad9039e41fb48194d5901c7be22be8
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
When issuing cmake --build "." as an user I don't get to see which build
directory is being actually built.
To make things worse in project settings the build directory field is
disabled and cannot be copied.
Change-Id: Idf862ba1df68cde55e9785c934f67393da6c1616
Reviewed-by: Eike Ziller <eike.ziller@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>
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>
Even if the implementation allowed different lists than 'build'
and 'clean', that's the only set that has been used, ever.
If really needed, this could be re-instated, but for now having
them fixed removes part of the neeed for a two-phase construction
and helps to simplify user code.
Change-Id: I3df09a1829a7d020ef8963d358ea80f8d199ba13
Reviewed-by: Christian Kandeler <christian.kandeler@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>
... instead of creating the BuildSystem direct. This will help the
shift of BuildSystem owner ship as a Project will have potentially
multiple BuildSystem instances (one per BuildConfiguration), but
still be responsible for creating them with the Targets.
Change-Id: I2dd71c7687ed41af9e42c874b3f932ce704e7ee3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Doesn't have any dependencies into CppTools anymore, therefore moving it
reduces the dependencies of the project managers to CppTools as well.
Change-Id: Ibe728abe59eb88a8877943dca1f48a85163e27ac
Reviewed-by: hjk <hjk@qt.io>
Add a class to abstract out the BuildSystem from the Project.
Thie idea is to make a Project have-a BuildSystem, so that
it can stop being one.
The Projects in the different ProjectManagers will get much
simpler that way (and many will only consist of a constructor
with some setter calls) and handles all the interactions
between the rest of Qt Creator and the project.
The complex code to interact with the build systems is then
separate from that.
Change-Id: I3bbb000bb1aed91f0b547ac493f743ede8afb8cd
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Introduce BuildSystem to implement functionality common to all
build systems out there. This includes things like delaying the
parsing by 1s.
The actual CMake specific code is then moved into a derived
class CMakeBuildSystem.
Change-Id: I84f4344430f19a44e16534db294382c436169ed5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use setters/getters for the bool flags in
Project::needsBuildConfigurations() and
Project::hasMakeInstallEquivalent.
Change-Id: I5ce937c3a5e8e0db627cda02a9007f8c28ccda0c
Reviewed-by: hjk <hjk@qt.io>
The only user can also get this information from the relevant
CMakeBuildConfiguration.
Change-Id: I80e176ef0a8bc427f6adbf75b20e29f38d7b949f
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
When the filesystem scan takes longer than the cmake parsing, then
resetData() was called on BuildDirManager by the CMakeBuildConfiguration
before the CMakeProject had requested its data.
Move some code back into CMakeProject to resolve this issue.
Change-Id: Ib21bdd63fdca79c2ad39a7e060df438b456700b4
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
There is no need to reset a reader when e.g. the build directory changes
when the server-mode reader is *not* used. So the one case where having
separate reparse-options for the case where the reader changes and the
case where it stays the same is bogus.
So unify the flags into one set and simplify the code accordingly.
Change-Id: I9bcfcc6333d574d49513ef1256a9a8597bda4ec7
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Move code closer to the BuildDirManager that was moved into the
CMakeBuildConfiguration.
Change-Id: I21d7188e4a3b03a02b12b01c7dd3e46754d653f8
Reviewed-by: hjk <hjk@qt.io>
Handle environment changes in cmake better.
Server-mode will trigger an reader-change when the environment changes.
This has not been considered so far and a reader-change triggered by
an environment change was considered an error (and ignored).
Change-Id: I2d0baadbcfc86e04348c75d8e5997817bdc233a5
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This prodecure requires no further information from the specific project
managers, so we can start it from the ProjectExplorer itself.
Also wait until after project parsing has officially finished and the
run configurations have updated their "enabled" state. Otherwise,
RunConfiguration::isEnabled() will always return false, potentially
leading to the active run configuration getting switched
unintentionally.
Fixes: QTCREATORBUG-21692
Change-Id: I32f4f758b5baa6222329d07b811993568eff1ee3
Reviewed-by: hjk <hjk@qt.io>
... from the environment.
Fixes: QTCREATORBUG-17985
Change-Id: I9b54e550121cfcc0684a6e173337d59d235c6107
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Just use the target name as buildkey. This is unique in cmake projects, so
there is no need to mangle the source directory into the whole thing.
This is a problem since different readers might report different source
directories. That will then result in RunConfigurations getting duplicated
after switching the reader types.
Task-number: QTCREATORBUG-22129
Change-Id: I849ab68f221d732341e98faa9a4e757d3a495b2a
Reviewed-by: hjk <hjk@qt.io>
This should help to remove UI blocking by pointing to the costly
operations.
Change-Id: I8b3250e9ec5995c7b6a705337d60250554b77b53
Reviewed-by: hjk <hjk@qt.io>
Use the category in CMakeProject.
Change-Id: Idb19a92080884f1feff082d8e9db3ca5336b9249
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
When project parsing fails, then the project node might be non-nullptr but
empty. This case is handled in setRootProjectNode(...), where such a
node gets discarded (rootProjectNode() will return a nullptr afterwards).
In this case, do not use the project name that came in from the parser as
it might be wrong.
Change-Id: Iec11aa2d88cca7352d957f428aab24b0f1affd49
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
