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>
Configuring a project during build is a recipe for disaster.
Fixes: QTCREATORBUG-26606
Change-Id: I041d9bd76315647439100cadba809d6664d268fa
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>
Build related menu items are sorted by tasks, then configurations.
e.g.
+ Build
+ Build All Projects
+ Build All Projects for All Configurations
...
+ Rebuild All Projects
+ Rebuild All Projects for All Configurations
...
+ Clean All Projects
+ Clean All Projects for All Configurations
...
This patch changes the order to configuration > task like below
+ Build
+ ...
+ qmake / cmake
+ -
+ Build All Projects
+ Deploy
+ Rebuild
+ Clean
+ -
+ Build Project
+ Deploy
+ Rebuild
+ Clean
+ -
+ Build Subproject
+ Deploy
+ Rebuild
+ Clean
+ -
+ Build File
+ -
+ Build All Projects for All Configurations
+ Rebuild
+ Clean
+ -
+ Build Project for All Configurations
+ Rebuild
+ Clean
+ -
+ ...
Change-Id: I95844e51d2ae164ed9f29fdb1c51509611c514fe
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
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>
Flash when CMake is started, write all other output silently.
This avoids re-popping up the general messages pane all the time.
When an error occurs, that is put into the issues pane, so no need
to pop up the general messages pane for that either.
Task-number: QTCREATORBUG-24430
Change-Id: I07ae4182cbc43147fbb343b360baf9da7e65f224
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Add a command to trigger the parsing of a given CMake file-api
reply file. This is important to have to help with debugging file-api
issues like QTCREATORBUG-24044.
Change-Id: Iadaa5cf01b9b6ddddf4e6ad669bb05928c6f29a5
Reviewed-by: Tobias Hunger <tobias.hunger@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>
Including some random uses.
This mimics std::filesystem::operator/(std::filesystem::path).
Change-Id: I0b0f5cf0d962fd33d4cbb9be96645a0b4a21ee03
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>
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>
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 builds on top of 08677c0b01 and
fixes one more code path to go through a common entry/exit point.
Change-Id: I1d00fa9242f247028e5d3b0ef3b5fe1d3f4cb03d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
The directory tree scanner and the project parsing work independently of
each other. Add logic to combine these two sets of results into one
parsing state.
Change-Id: I46e94f0e866b40ee7225235c536c742cecf11b45
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
That's the only error that was ever checked for, in all nine
project manager. In the hypothetical case that we'll need something
else than the name of a file to identify a "project file", we'd
probably need to touch the signature anyway. Until then, remove
the duplication.
Change-Id: Iba00b8f71309a908e2d29c0a58c50b685eca0cae
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Can be done generically when creating projects. The only wart is
the use from BaseQmakeProjectWizardDialog::writeUserFile.
Change-Id: Ie98c9f88ec142e82443e204a0075e3ae9e163752
Reviewed-by: Tobias Hunger <tobias.hunger@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 will make it easier to introduce a new type of BuildDirManager
to accommodate cmake server-mode.
Change-Id: I989aab9df44dff1cfdff226ef97bb30bb092ffdd
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Setting CMake configuration to the provided by the Kit, drops all users
settings to the default one. CMAKE_BUILD_TYPE too.
Change-Id: I8be556f553376273933872a74e47937df5a74f30
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
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 is no longer needed now that the generator is a property of the
Kit.
Change-Id: Ife35fd9207c805a4ead1e067603df1bfc77e6855
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
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>
Do not leave out -Csomething (set by the kit) or the generator used
(set by the wizard).
Change-Id: I41cfb935da2877deaa26ae84bfdd96948fa20763
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
Reviewed-by: Tobias Hunger <tobias.hunger@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>
The information is contained in the BuildInfo, so there is no
need to provide it a second time.
Change-Id: I512d148e36996130fab6d8e007dd16d5acebaebb
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
* Make it work at all again for cmake configurations without a
preloadCache file
* Fix the KitInformation to provide the getters/setters like all
the other KitInformation do
* Use those setters consistently
* Remove useless conversion from QString to QByteArray and back
Change-Id: I8fc43b3531da2c04034c89b29915a29c331fe064
Reviewed-by: Cristian Adam <cristian.adam@gmail.com>
Reviewed-by: Benjamin Zeller <benjamin.zeller@canonical.com>
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Some time ago the all the wizards for the Plain C++ were coalesced into one wizard.
Since then the wizard asks first for the targets via a targetsetuppage and then
in the CMakeOpenProjectWizard asked for the kit again.
This patch clean thats up, by always using the TargetSetupPage for kit
selection and removing code from the CMakeOpenProjectWizard for kit selection.
It also adds more types of buildconfigurations
Offer: Debug, Release, ReleaseWithDebugInfo, MinSizeRelease with the
corresponding -DCMAKE_BUILD_TYPE parameters. That argument is saved
in the build configuration and used once for the first cmake run. (Subsequent
runs of cmake don't require passing that to cmake again.)
Also do not require running cmake on creating the buildconfiguraiton, instead
postpone that until the buildconfiguration is made active. With the current
cmake wizard, selecting multiple kits would show a dialog per buildconfiguration.
Change-Id: I3bb806113f4f529f8e291830647d2515a6c4df8a
Task-number: QTCREATORBUG-12219
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
The correct pattern is this: The actions in the build menu are supposed
to be for the startup project. They should use the global context and be
manually hidden/shown if the startup project changes.
This fixes a crash on assigning keyboard shortcut to the edit files
context menu action.
The slot connected assumed that the action could only be triggered via
the context menu. By using ProjectTree;:currentProject() the code now
works even if the project tree is not actually focused.
It also fixes that the "Run CMake" action was shown even in the build menu,
even though a non cmake project was the startup project.
Change-Id: I0bb8086d8b1078b4c71c3b5ba9d7f8596757e724
Task-number: QTCREATORBUG-14728
Task-number: QTCREATORBUG-14768
Reviewed-by: Eike Ziller <eike.ziller@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>
