... instead of the entire project.
This can speed up the development cycle by ignoring irrelevant changes
in the project, potentially at the cost of missing parts that actually
should be re-built (in particular with build systems where a product
does not have full knowledge of its dependencies).
Supported by qmake and qbs for now.
Change-Id: Ic7101aa243e92ba139798d13366d256c1919dcc3
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
That is, do not link to the qbscore library anymore. Instead, use the
JSON-based API.
Advantages:
- We can build Qt Creator with qbs support without qbs being present
on the build machine.
- Smaller memory footprint for Qt Creator, as the qbs build graphs
are now being managed by a separate process.
- Potential crashes in qbs will not kill the Qt Creator process.
Fixes: QTCREATORBUG-20622
Task-number: QTCREATORBUG-22904
Change-Id: If7d344b0ac65a99ff0a3a3db215d61b8d903e47e
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
Commit 81a643ec99, fixing QTCREATORBUG-22412, was too restrictive: UI
files in applications have access to resources of library dependencies,
so we must consider those. We now only exclude resources from other
applications.
Note that this will potentially list non-applicable resources, e.g.
those from libraries to which our product does not have access. This
cannot be reasonably prevented, because not all build systems provide
this information. It's also not as bad as missing resources.
Fixes: QTCREATORBUG-22909
Fixes: QTCREATORBUG-22962
Change-Id: I51a87402b43c156618982813c408060f300e4e58
Reviewed-by: hjk <hjk@qt.io>
First step, move {DesktopQt,Qbs,CMake}RunConfiguration{,Factory}
into the same new files.
This only moves down to QtSupport, not ProjectExplorer, as there
are in all three cases direct dependencies on QtSupport. Long term
I would expect them to move further down.
Change-Id: Ib16b19df7f3f642ed7f7db89a1f6904601d976ba
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Do not allow deletion or rename of files that are used
to define or manage projects.
This fixes issues of being able to remove or rename
pri and pro files of qmake based projects as well as
special files used by the GenericProjectManager.
Change-Id: Ib173abf04368f0625a9e481bb7290aa11933e62f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... from a project which are pulled in via wildcards.
Such files cannot be removed from a project file, because they are
not listed verbatim. This kind of failure should not be reported to the
user if the file is also deleted, as the file list will have the correct
state after the next reparse.
Fixes: QTCREATORBUG-22586
Done-with: Christian Kandeler <christian.kandeler@qt.io>
Change-Id: I3dc66fe9a6594be7d0b86f46d830cd099ee49fd7
Reviewed-by: hjk <hjk@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>
A product is a project node from which a target binary is produced, such
as a Product item in qbs or a .pro file in qmake.
Change-Id: I6a0e6bed6c02684cb03b2b18fed6a1b493fa78b2
Reviewed-by: hjk <hjk@qt.io>
Now we can use QtCreator to build, deploy, run & debug QBS projects.
[ChangeLog][Android][QBS] Add Android support for QBS projects.
Fixes: QTCREATORBUG-15573
Fixes: QTCREATORBUG-19880
Fixes: QTCREATORBUG-22182
Change-Id: I08b153a44dcf7ca178689c1c30fa2201c4cc0dbb
Reviewed-by: hjk <hjk@qt.io>
They were identifying the same set of nodes.
Change-Id: I3316cbc434ff740547bcf0baf9e5f1544f6e3f56
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Not the usual direction of change, but currently there are
several systems to identify or invoke node functionality.
Virtual functions are likely to stay in this context, so this
here attempts to help consolidation by reducing the influence
of the node type flags, hopefully leading to full removal
by making remaining functionality available through the
other mechanisms (virtual functions, asFooNode() 'casts',
less so the FileType flag).
Change-Id: I12a17ce30b3c8883995b29b4720408020ee0fa3e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's a ProjectExplorer::FileNode with a custom constructor.
Change-Id: I3057647a5843141ef9e55c97dd19255ea454479a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
So far only used and set with QBS, but conceptually usable more
generally, and harmless if not used.
Change-Id: I1d2d615f5613340690de22a1c7d716a193fb1f05
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to QbsGroupNode::showInSimpleTree(). It's the only subclass
that didn't re-implement it.
It's easier to reason about the actual value when the value isn't
flipped too often in the inheritance chain.
Change-Id: I61f6020acc95a3dc0383b44ad8d40ee39f923d0f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead of constructor arguments. This makes it clearer on the
user side which value is actually changed.
Change-Id: I63ae8cd139a49700996c8874098111aad89ace22
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use setter of base class, similar to setListInProject() before.
Change-Id: Id620f0084a5dec0410f29c80f8f6393a6bcd5050
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
- add a QString FileNode::buildKey(), returning the build key
for a build represented by that node, if any.
* for QmakeProFileNodes the build key is traditionally equal
to the file name, so use that.
* for QbsProductNode use the uniqueProductName()
- add a Project::findNodeForBuildKey(QString buildKey) convenience
function searching a Project(!)Node matching that build key.
That's the only use case there is right now, and I see no reason
yet to travers all files (yet).
Change-Id: I388c0e06c03111e12d630899d762448e974a5737
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... by default. The "New File" wizard, if not invoked from the context
menu, implicitly prefers Groups over Products, because the respective
nodes are tried first. Thus, we lower the priority of group nodes so
that their parent product will be a better match unless the group was
specifically selected.
Task-number: QTCREATORBUG-20480
Change-Id: I0c5b2dbf861065ee97ab957ec8bd86132295893e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This feature in question is the availability of the "Run" button in the
context menu of certain project nodes in the project tree to run
something presumably related to/build from that (sub)project.
Previously, the decision was made for certain qmake based projects
(those targeting Desktop, iOS and VxWorks) by some indirection
through the corresponding RunConfigurationFactories.
The patch lets the RunConfigurations decide themselves directly
and removes the indirection, potentially opening the feature for
other qmake based RCs, as well as other combinations (e.g.
PythonRunConfiguration could be associated with its .py file,
without the need to have a dummy project)
Change-Id: Ic489bd1dfa25fcd9102ffa4fa30125565dd2e40e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Add a helper method to request a directory icon with an overlay icon for the
project tree.
Change-Id: Idea2ea9ec2ea6790bf8d087723700364fbcafec6
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
That should save some memory per node, and since creator has a lot of nodes
(e.g. opening the LLVM project adds about 1 000 000 nodes) this should be
noticeable:-)
Calling update inside ProjectTree::currentNode() and rename it to
findCurrentNode() to make sure it is an still existing pointer.
Also, try to reduce the somehow more expensive currentNode() calls
and sprinkle some const around that usage.
Change-Id: I6a7c5db01a71d53d39544d3013cad557d5b96cdc
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This patch prepares for enhancing information stored inside
buildSystemTarget.
Change-Id: I5d81fd01ab6b06c162f47fd9536de697ddfd24a3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Getting the full list for a node can get quite expensive e.g. in
cases of recursive calls of QMakeProjectManager::findPriFile.
However, the FlatModel needs to decide quickly on whether an item
is editable to potentially allow renaming.
So split up QList<Actions> supportedActions() into individual
bool supportsAction(action) calls and make sure Rename is not
on the critical path.
Task-number: QTCREATORBUG-17953
Change-Id: I31841847f8aa7d7b94c63d76ce71efb1c930fa69
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
To HEAD of 1.8 branch, and adapt to changed API.
Change-Id: Ie180b114726134a06dfefe9dc3a6dc27997f246c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
At least the "build product" functionality was broken because of this.
Change-Id: Ia552e53ba783b2b037ce7289d554e4061ed62262
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Move closer to a setup where the project tree API can change.
This patch also makes sure "Generated files" will be below the
product file of each product and above any Groups/folders/files.
Change-Id: I728289372d40b809105f55adbe50fd424b19e0a0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Move code to set up the tree of project nodes out of the project
nodes themselves. This makes them easier to manage and will enable
creator to change to a less update-intense project tree.
Change-Id: I2d0702d257e87543f47ebfb456344423ebe4f871
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There is no need to call setupFiles on the QbsGroupNode before calling
update() on the root node. That will just redo the work anyway.
Change-Id: I54048395f87dd6fb5436f5d9d47b97e82460b568
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
No need to use two filters with a temporary list when the
task can be done in one go.
Change-Id: I96468099eb28c9698dbc637e432a38071d054e39
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
One step closer to direct use of Utils::TreeNode.
Change-Id: Icd0dfd2fa4d12c2572a68f61ae43c5e906956a0e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
