After a re-parse, the existing IDocuments need to be updated with the
new QmakePriFile object, as the old one may no longer be valid and thus
cause a crash on the next re-parse.
Amends f3bd07efd1.
Fixes: QTCREATORBUG-24683
Change-Id: Ib03d3005cb7831f1e05cb116aa3cdfe6cf5e72ad
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... for which the original kit has turned up again. Otherwise we'd have
more than one kit with the same id.
Fixes: QTCREATORBUG-24589
Change-Id: I7ce16615694d3d2c5a5441f676ecb7dc85c2239c
Reviewed-by: David Schulz <david.schulz@qt.io>
This was broken in commit 37aecdd112, where we overlooked that a special
type of IDocument was used that triggers a re-parse of only the affected
part of the project tree. As a result, all changes to a .pri or .pro file
would trigger a re-parse of the entire project.
Fixes: QTCREATORBUG-24572
Change-Id: I480cff4e53cf86a17e1eaac0eb9b32901bc87051
Reviewed-by: hjk <hjk@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
(cherry picked from commit 430a33dcd9)
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The ClangTools and the AutoTest plugins use an internal
mechanism to load and configure a project when performing
their integrated unit tests.
Both assumed to have exactly one kit present for these
tests.
Make it possible to have more kits present when starting
with existing settings or if more kits get automatically
generated when starting with clean settings.
Change-Id: If2bc66320c4854f1d34a19d17107e8f0b7d64d39
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There are very few reasons to use mainWindow() directly.
Especially for modal dialogs, using dialogParent() is important, since
that guarantees the stacking order in case of other dialogs currently
being open.
Change-Id: I7ad2c23c5034b43195eb35cfe405932a7ea003e6
Reviewed-by: hjk <hjk@qt.io>
... when a kit disappears.
This can easily happen, for instance due to a Qt version update via the
installer, and until now resulted in the disappearance of all user
customizations of build and run configurations.
We now store some additional data when serializing a target, and use it
to recreate a kit of the same type upon restoring. While the resulting
configurations are not guaranteed to be functional, they should contain
all the customizations, which the user can then copy over to a proper
kit.
Fixes: QTCREATORBUG-23023
Change-Id: I659d52808b2f8a308e6aa094e8ef2ee60d586952
Reviewed-by: hjk <hjk@qt.io>
For extra safety, do not touch the project nodes if any build system of
any build configuration is currently parsing.
This is a bit of a stab in the dark, as I cannot reproduce the crash
described in the linked bug report.
Task-number: QTCREATORBUG-23597
Change-Id: Ie62a94232e89d8fba5866ea3572535e2ab209924
Reviewed-by: hjk <hjk@qt.io>
They are available in some cases as such, and consumed as such.
Change-Id: I9866c7d7bd817fb19a8b11a0efbe583ed55fe393
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This function was buggy and could erroneously un-watch all the project
files after the first update.
Change-Id: I528fd8da7f873598e08f4c0177757a052fbb97ef
Reviewed-by: hjk <hjk@qt.io>
Some listeners are only interested in a particular build system
instance, not all of one target.
Change-Id: Id89bd96c1f7f68bac13886bdc31cb899978d76ac
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Give the reason for a kit being disabled in the tooltip.
E.g. for a CMake project you will now get
"Kit is invalid: No CMake tool set."
instead of a generic error message about the kit being invalid.
Change-Id: Ic776dc24149d65ebf27163b605ec2e52a3a504a7
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
...into another target.
Using the same build directory in two different targets will likely lead
to errors.
Fixes: QTCREATORBUG-23462
Change-Id: I7daa510b3128a344adb51772d44a79415419acc3
Reviewed-by: hjk <hjk@qt.io>
Add a new project panel where users can set environment variables for
the current project in all configurations.
Fixes: QTCREATORBUG-21862
Change-Id: Id98c7f1cf579927a8004a63172f193f943556f44
Reviewed-by: hjk <hjk@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>
This is a hack, not a proper solution. In theory, this here should
serve as a lock.
We currently get start - start - finish - finish sequences when
switching qmake targets quickly, keeping the run button disabled.
The whole setup here is unfortunate. Parsing inherently depend on
more than the project alone, it's roughly per-Target. So keeping
track of it in the Project complicates it.
Change-Id: I57d361ce21088d8e1ec53ce75f83ff3bd04851e1
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>
This is used for parsing the project only, so reflect that in the name. Not all
projects have build configurations, so the old name did not make too much sense
for what this has been used for.
Eventually this code should move into the BuildSystem.
Change-Id: Iff766150b5fe370f2912b0b3b15348b1c1fad5b5
Reviewed-by: hjk <hjk@qt.io>
QTC_ASSERT that the filter passed to Project::files is valid before
calling it.
Change-Id: I17776fa4ab3e2aa21ac34db015fdbbb382439669
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The document is used to do file watching, which may or may not be
ideal. So make sure we do not leak the information how we watch
files into the API and its users.
The method is not used sensibly anywhere in creator, so it seems
safe to remove it entirely.
Change-Id: Ieed755bd5c852875378e4e96665dc906499975b0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Add a signal triggered by project files becoming dirty and add
a way to register more project files than just the default with the
project.
This change enables getting rid of filesystemwatchers in derived
classes.
Change-Id: If985b46edf7cb88dd49f1c574f35cf13b5ce82d4
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 listener left is the target's project, which is known at each
emitting location and can be called directly.
Change-Id: If07d2c1c43fcf5d2094c0b6d59f773d12b4f6d6b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Targets are different from {Run,Build,Deployment}Configurations,
both regarding the level in the ProjectExplorer hierarchy, and
also by the set of supported operations (e.g. aspects).
Change-Id: Ia8490e2280a9ecc518395c5e48ce2fd5d6d58fd2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... from the environment.
Fixes: QTCREATORBUG-17985
Change-Id: I9b54e550121cfcc0684a6e173337d59d235c6107
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
... to the bits that are actually used.
Change-Id: I39a6ed1f4136d75b776bb89eec6165479097a4ec
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
