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>
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>
QtVersion to utils/cpplanguage_details.h which already contains similar
flags.
BuildTargetType to ProjectExplorer, next to BuildTargetInfo (but not in the
same header to not pull that in everywhere).
Removes dependency on ProjectPart from RawProjectPart.
Change-Id: I5791065e4266f20c2657ee4b1b594df04b238a1c
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
The feature to category files to ProjectFiles was used by the qmake
project manager to specify if the file is "active", and by the Qbs
project manager to avoid unnecessary MIME type checking.
Make these two different use-cases explicit in the API.
Change-Id: Ia5a7da37f100149366fc75060fe04687e15f2bd3
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@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>
Make all buildconfigurations disabled while the project parses.
This unifies how this is handled in different build systems.
Change-Id: I6afca3743ad1433529a4f9d3bfdf73042799e456
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The Environment class is supposed to support values with references to
other variables, but we failed to actually expand them in most places.
Fixes: QTCREATORBUG-22687
Change-Id: I108cb59d3b4571471423455240f6f4f1cf64bf05
Reviewed-by: hjk <hjk@qt.io>
Use setters/getters for the bool flags in
Project::needsBuildConfigurations() and
Project::hasMakeInstallEquivalent.
Change-Id: I5ce937c3a5e8e0db627cda02a9007f8c28ccda0c
Reviewed-by: hjk <hjk@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>
... to the bits that are actually used.
Change-Id: I39a6ed1f4136d75b776bb89eec6165479097a4ec
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Avoid copying the entire list of files known to a project just to
filter out a couple of files from it.
Change-Id: I58b2e323f9678058ba482353eb777a55189fe05d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Parsing would not succeed anyway, and the pro parser can run into
assertions, e.g. in IoUtils::fileType().
Change-Id: I7fff466d858a2d3c9fd975246a20c92134963705
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This lets users build the executable corresponding to the currently
active run configuration. It's functionally equivalent to locating the
corresponding node in the project tree and choosing "Build" from the
context menu.
Fixes: QTCREATORBUG-22403
Change-Id: Ic2b729c7ce17f1ad944dc06746bb9d6db90b6c61
Reviewed-by: hjk <hjk@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
