It has too many side effects.
Amends fcd6384f4d.
T_SYSTEM and E_SYSTEM are now treated the same.
Fixes: QTCREATORBUG-24551
Change-Id: Ib6df2762d329f2ddc0dd66190454159d446a9ac9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
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 coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@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>
Prefer source files from contexts where we know that they actually get
built and thus should have includes and compiler flags properly set up.
Also fix the qmake and qbs project managers to not mislabel any non-
application products as libraries.
Fixes: QTCREATORBUG-23394
Change-Id: I0d122c7b58e12d14d68a1ca7337df83074299cd7
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
Hide the parameters behind yet another macro to get a uniform layout
and avoid parameter evaluation in the normal non-traced case.
Change-Id: Iaf24b0f1b285c8f664f8b3476ae82c39c1a2d7dd
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The problem could be reproduced as follows:
- open any bigger qmake based project (e.g. QtCreator)
- de-activate all kits
- activate one kit
- wait until the first parse (e.g. Debug build finished)
- switch to Profile, and toggle the Shadow build button
The toggling re-starts the parsing. The parse guard will not be released
in decrementPendingEvaluateFutures() (arguably correct as the parsing as
a whole is not done). On enteringing incrementPendingEvaluateFuture()
due to the re-start, the guard still guards the parse, but a new guard
is created in guardParsingRun(). As this happens while the build system
isParsing() is true, the created parse guard will be "non-guarding".
On assigning to m_guard, the original guard object will fire and then
be replaced by the non-guarding guard, that never fires again, so the
the build system will never have hasParsingData(), which is a
condition for the run buttons to activate.
As a workaround for people running into this issue in 4.12.0:
Select 'Run qmake' from the menu (any subproject suffices), and let
it finish.
Change-Id: If7a55db56ec67bac2635fb9a745b9aaf6ca6a413
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For instance, the warning was potentially erroneously triggered with
examples distributed via the installer, as those are present only once
for different installations with the same version number.
Amends e4738904d9.
Fixes: QTCREATORBUG-23753
Change-Id: I0dbb296cd974a3530222661c4b8cecc2106f0ea5
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Among others, this removes the wart introduced in 4d3d2d0dfb.
Change-Id: Iafa63f6e4cca327a1d1dd6a8bbcfaa10032327db
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@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>
More a buildsystem than a node thing in general and removes
one use of activeBuildSystem and one use of the ProFileNode
-> ProFile back pointers.
Change-Id: Ie007fcd0db9e9294a08b3a1cd68f825c7d3dc9b8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
And add some logging to make the situation debuggable.
There are a lot of reasons that currently trigger (or attempt to
trigger) parsing, including two unconditional ones on build system
construction and fromMap. Some can be avoided, but keeping track of
which one will be the "needed" one gets tricky without additional state.
So turn it around and try to reparse "immediately" until such a parse
finished. The parser itself is robust enough to deflect repeated
runs before the first one finishes.
Change-Id: Ic992b8730fa3a09ca14532cdd9bdbab4c245cb41
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@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>
No need for two manager type classes talking mostly to each other.
Change-Id: I82a52385df08dc4cddac2d294661341a79b86a4d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It is currently only getting there if it's the active one, so it is
not a real problem, but distracting.
Change-Id: I1f83644a71a3f22e23f966e273c1a23cfc0cc6b7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Special accessors to the repeatedly used C and C++ cases to denoise
and slim down user code. Plus some code cosmetics nearby.
Change-Id: Iba4662bd4731d8c4256e658529f39d5c995691ce
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
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>
Instead, we keep the IDocuments as "extra project files" in the Project
class, like the other project managers do it.
This has two advantages:
- The document is no longer created in a parser thread
callback, improving Qt Creator responsiveness while
loading a project.
- The IDocuments no longer get needlessly destroyed
and re-created on a re-parse.
This is relevant because adding these objects to the DocumentManager
results in the creation of file watchers, which is expensive.
Task-number: QTCREATORBUG-18533
Change-Id: I49c03377974e6b33340234dbabbbd82b8d0c827c
Reviewed-by: hjk <hjk@qt.io>
When parsing larger qmake project, the callbacks from the parser threads
are currently overloading the UI thread, often rendering the application
non-responsive until the project is completely loaded.
This patch moves some expensive operations from the UI thread into the
parser threads, at the cost of a somewhat ugly two-stage setup for some
types of objects.
On my Linux machine, I measured that the time spent in parser callback code
went down by almost 50% when loading the Qt Creator super project.
Task-number: QTCREATORBUG-18533
Change-Id: If9624da5b07e81a50c180693580b20a70e1aaea7
Reviewed-by: hjk <hjk@qt.io>
For Compile, BuildSystem and Deployment. Unclutters user code and reduces
binary size.
Change-Id: Ia18e917bb411754162e9f4ec6056d752a020bb50
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Currently diverting to the original Project::setRootProjectNode.
Idea is to focus on the BuildSystem <-> generated tree relation.
Change-Id: I8b20173e364713f0919cf4f8b76a2f79ef8770bb
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>
At least the QML code model would like to know what application targets
are available, so that it can figure out where to look for app.qmltypes
files.
Change-Id: I638936a90a91193bb59bd9b6827786e25f4eaad3
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>
