Introduce a method that maps a RunConfiguration to the build system target
that created the executable.
Implement the method in all RunConfigurations where that makes sense (e.g.
no CustomExecutables).
Change-Id: Ifaac859c2cd9b2806a0d7c185b2239312a67752a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@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>
That information is used rarely, and is not too expensive to regenerate,
so there is no need to store and manage it for every node.
Change-Id: I2261853431cd4328ec447031de3b9f5d5347e796
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Use class enum to shorten the FileType to quint16. This frees up a couple
of bytes per FileNode and we can have many of those.
Change-Id: I3a9ae25059690fefa15305a4268269647d6dc1c9
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use a class enum with a type quint16 for the NodeType. Frees 2 bytes
per node that can be used for better things now.
Change-Id: Ib84bf8629e9f4a5fb0793355eff0f0d6302167dd
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Such products are not guaranteed to have a valid build directory.
Change-Id: I3e6ec211edb8fb9a13e3b785cd19b795f7adee12
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
That one was accidentally removed in 0b3abfcf6a.
Change-Id: I01d2654175260f9efd1d01e5997170ce0d1faf0e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
To HEAD of master branch. Also do the necessary API adaptations in
QbsProjectManager.
Change-Id: I4709b7a0f35537f5b6f9fd04f4d95be16aef2c8d
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
setupFolder is called recursively...
Change-Id: Ief1d1d45294a3821f5496d832a2130a8ff779f44
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Since a lot of derived classes can make use of those.
Change-Id: I051542e8d318476348d753de4d4c0a30b3a9ed62
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
If source files were located in a separate folder from their product
(e.g. the rather common case of a subdirectory), then the "Rename"
and "Remove" actions would not be available for them in the project
tree's context menu.
Change-Id: Ieecf5372619ab3fcf275a55d7850445e3aa44a0d
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
It does not make sense to add files to anything besides products and
groups.
Task-number: QTCREATORBUG-14286
Change-Id: Iced8cefc4eff3857e9a1a6d3a3a9311dcbb44f11
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
...when rebuilding the project tree.
Consider this product:
CppApplication { files: ["form.ui"] }
Now change it to this:
QtGuiApplication { files: ["form.ui"] }
The qbs file tags will now include "ui", so the Qt Creator
file type must change from "UnknownFileType" to "FormType". Therefore,
we need to replace the respective file node in the tree.
Change-Id: I6aa7e66d1af584e8ded2ffbb9b1215e8fc1135b8
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
At the moment, all source files get the type "unknown",
so certain code in other plugins that looks for e.g.
Qt resource files never finds any.
Task-number: QBS-762
Change-Id: I71b798980b7ca318f2b4e7871148ba72703f8d83
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
The idea behind NodesWatcher was that it was the central place
to catch node related signals, so that users didn't need to
connect to each individual node and the nodes didn't need to
be QObjects. Somehow Nodes ended up being QObjects anyway.
Both the recently added ProjectTree and the FlatModels consume
the signals the NodesWatcher sends. Unfortunately there's a
ordering dependency between the ProjectTree and the FlatModels.
This patch removes all NodesWatcher and instead makes the
ProjectTree singleton the emitter of various project tree
related signals. The ProjectTree also ensures that the ordering
between the FlatModel and itself is taken into account.
And it makes Node not derive from QObject, saving some memory
in that process.
Task-number: QTCREATORBUG-13756
Change-Id: I8b0d357863f1dc1d2d440ce8172502594138b9fb
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
To HEAD of master branch.
Also do the necessary adaptations.
Change-Id: I51830dee41341c9be294caf69fdb0459ed8c8bfe
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
- Identify products by the name/profile tuple instead of just the name.
- If the product's profile differs from that of the overall
project, add it to the visual representation.
Change-Id: I4a89db60911277977458370157e435472bbe428f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Root cause is trying to set the display name on a FolderNode that
is not in the tree yet.
Allow setting the displayname in the constructor and use that new
constructor where it makes sense.
Task-number: QTCREATORBUG-12897
Change-Id: I907e48cac837966e38524bfe88a87ef17d93f0b2
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Such build system files must be filtered out, as they do not appear on
the right-hand side of "files" properties and have completely different
remove semantics.
Change-Id: I3963aa853003f4d674392434529dab19749af25b
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
qbs::Group is a reference-counted value-like class, and it makes no
sense to hold it as a pointer. It makes even less sense to compare that
pointer when deciding whether a project node needs an update, as this
comparison will always be false (and technically undefined behavior as
well if the original qbs::ProjectData object no longer exists).
Change-Id: If188f83802bf6cffd04215d192667cf0200e25d3
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The qbsProjectData() member function always returned the top-level
project data, which messed up a couple of things, for instance
"build sub-projects" and the node tree updates.
Instead, return the project data corresponding to the node.
Change-Id: If40c441c62334f0069a5fe3cb4873cf973baf135
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The build graph is locked then. Disabling the action in the first place
is nicer than letting the respective qbs API call fail.
Change-Id: Icfb89b454a240253c9ddc7681b452d06ff0393dd
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Show build system files used by Qbs that are part of the project
hierarchy in the Projects Pane.
Change-Id: Ie7d1f1833fb00376f92c1436bd83e4f0518ae3ac
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
qbs knows the effect of adding and removing files. There is no need to
set up the project from scratch.
Change-Id: I8938c7cfb3e3ac2deb3fb0d2175f447391a669cb
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The current code keeps an instance of QbsProject and of qbs::Project in
every project node, with them being null/invalid everywhere except for
the top-level node. Instead, introduce a dedicated class for the root
node and hold a QbsProject only there. The qbs::Project is held in
QbsProject now.
As a nice side effect, this also fixes QBS-644, presumably because the
dubious-looking use of projectNode() has been removed.
Task-number: QBS-644
Change-Id: I5d36806745b9d67879db6f48aa56bc97868e4f17
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
If the operation fails, people currently don't get any hint as to what
the reason could be. For lack of a better place, log the error message
to the General Messages pane.
Change-Id: I19c48bbee0e0030b2d542425d43c089a29600756
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
