Merge handleParsingSucceeded and handleParsingSuccess as well as
handleParsingFailed and handleParsingError.
Change-Id: If4f84bdfa2f59cfa0037a941372a1929996be3bd
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
For this to work, we need to make sure no parsing is triggered before
the project is fully set up. Otherwise it would be QTCREATORBUG-23816
again...
Change-Id: If81f4c6b9c82283abdaa8a635f93ebe0bcaf8159
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Add a buildConfiguration method that returns the saved
BuildConfiguration or the active BuildConfiguration if none is
set.
Change-Id: I8af25aa1037f59a0091900bac7eb84fed9e5fbb0
Reviewed-by: hjk <hjk@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>
... and move context menu action handling there.
This is a temporary measure to be able to move that functionality
alongside the actual BuildSystem to the BuildConfiguration.
There is a lot to be cleaned up left, to keep the patch small.
Change-Id: If4b0820a13b376fc97b70785052924972ce22705
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>
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>
