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>
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>
