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>
This was completely broken: Both The qmake-specific logic for enabling
the menu item and the generic code executing the action operated on the
wrong nodes.
Change-Id: Ic6af6f87999dfd3b939f185312be944750b21fa9
Reviewed-by: hjk <hjk@qt.io>
We check the child nodes of the current project and only add the new
file if it doesn't occur there already.
Fixes: QTCREATORBUG-19546
Change-Id: Ic784a117515eb7e433ebf1d08db1708da6cf5440
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... from ProjectNode::targetData and setTargetData, and rename them
to data and setData.
It was only used in the implementation to retrieve the right node,
instead move the responsibility to find the right node to the caller.
Current assumption is that the functions were always called on
the right node already.
Change-Id: I9ae7e8a7ed5c79b924b99fd9a6a652bad56d114a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This uses the same approach as in the previous patches: Have some
generic interface in the base classes (here ProjectNode::targetData()
setTargetData()) and implement on the qmake project side.
Implementation for Cmake/QBS is architecture-wise possible, but
not used right now, and left for later.
Change-Id: I3bbf66170020cf9027a894cd66db15ec7ffbf499
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... via base project node functionality.
Change-Id: Ifd9c5b149e11c1d104abed200881fdfe93749144
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... using a new base ProjectNode::targetApplications() function.
Change-Id: Id210683dce6bfa7ffbc89973423d326d76ac9309
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This moves most of the QmakeProject::applicationProFiles code
to its only user, the android side, and only uses the new
bool includedInExactParse() const hook on the qmake side.
Change-Id: Ica11127c4895be22cafe56757f4cecafa02583ef
Reviewed-by: Christian Kandeler <christian.kandeler@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>
This makes the using code a bit less dependent on qmake specifics
(qmake related ProjectNode specialization vs qmake-only class)
Change-Id: Ied6ced70694b3ac0665d88ec86c4a66577f3a672
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
These are not used during parsing but when operating on the items
in the project tree.
This loosens the ties between the qmake related parser and project
nodes.
Change-Id: I077356fcde240df56b466c71c902c821c4885f6d
Reviewed-by: Christian Kandeler <christian.kandeler@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>
It's not an *I*nterface anymore
Also, remove the in-all-but-one case unused QObject parent and the
object name that was only there for debugging purposes. The class
type serves the same purpose in the debugger.
Change-Id: I0dafb01e6b4fd7c7df04a63aaa3ef3e4bd693f6f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The project tree is static nowadays, and the QmakePriFileNodes hold
pointers to their corresponding PriFiles. This is fast, but not
entirely safe: The PriFiles are constantly updating as the project
is parsed.
So make sure not to rely on the stored pointer while the project
is parsing and go through Project::rootProFile() in that case.
Once the parsing is done, the project tree has been updated with
new data, that reflects the current QmakePriFile tree.
Task-number: QTCREATORBUG-19428
Change-Id: Ifaa3432cad7774142d562648d93104629736d478
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Finding the right pro-file was surprisingly slow. Make that fast again by
storing a pointer in QmakePriFileNode back to the QmakePriFile that created
it. This is save since the Nodes in the ProjectTree get nuked whenever the
tree of QmakePriFiles changes.
Task-number: QTCREATORBUG-19131
Change-Id: I4b5a8887cb13c36273a553f935a00d87cee4a7b6
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The patch broke defining the correct executable for qmake based
projects. Loading more complex projects (like QC itself) did
end up failing to run any executable out of the box as the
executable name was always wrong.
This reverts commit 21b0e7c37e.
Change-Id: I471c9963bd739b74e48286e1bde00f7222b90c8b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Finding the right pro-file was surprisingly slow. Make that fast again.
Task-number: QTCREATORBUG-19131
Change-Id: I4b5a8887cb13c36273a553f935a00d87cee4a7b5
Reviewed-by: Eike Ziller <eike.ziller@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>
Not checking the parentFolderNode triggered a crash elsewhere already, so
double check other uses of parentFolderNode and use QTC_ASSERT to make sure
no nullptr is going to be accessed.
This is necessary now that we have a forest of project trees and no longer
have a sessionnode anymore.
Change-Id: Ibc380c2ec9b12b983e709d2eeb03a8b741fe1058
Reviewed-by: Tim Jenssen <tim.jenssen@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>
The optional BuildConfiguration parameter is never used.
Change-Id: Ic5773616920702134848507ef2801a7723e8b65c
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use QmakeParserProFileNode::AsyncUpdateDelay instead of
QmakeParserProFileNode::AsyncUpdateDelay.
Change-Id: I6628e566ce0f289778d61d146df58ca31345cdd7
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>
It's only used in one code path, and the InternalNode contains
everything it needs.
Change-Id: I6bd4e2e3555b9a321bf0b93c56d5459f141be494
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
... and remove ProjectNode::removeProjectNode, as this was the
only remaining user.
Change-Id: I2c53392a8e9dacf956270d652525b62ba4c9e0a4
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Drop the list sorting and difference generation which is not
needed in the "build from scratch" setup.
This also removes some of the intermediately introduced
convienience functions and fixes a regression that led to
missing project files.
Change-Id: I39d1966324917f466fb347da3a52552393ca4a01
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
