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>
Started implementing common functions to add new and existing files to
a project, using the API provided by Qbs. Works for most use cases
already. However, this is still work in progress.
Change-Id: I36ea921c203bd7caad564a45cd40cda408c72b54
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Rename to runConfigurations() and remove the node argument which is
available as 'this'. Adjust const-ness of node argument in
RunConfigurationFactory::runConfigurationsForNode
Change-Id: Icb63e96a305152f90135a2656536de2581faafaf
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
So that the resource node can override it.
Task-number: QTCREATORBUG-11678
Change-Id: Id30d1b99ee23cc18fc29fc99cf0ad7ca919ed527
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
There may be more than one matching node, so these methods provided
a false sense of reliability.
Change-Id: I6471b74a1d2dd4e8afc7e836fec45355696a0741
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
The reason they were on ProjectNode is that the signals are emitted
on the projectnode, but since I moved addFiles and others to FolderNode,
this makes more sense.
Change-Id: I918ca4d93dab78c8bb93dff03f53d1a6fbe21340
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
By default this simply calls the parent's supportedActions.
Most changes are due to the enum moving.
Change-Id: I25bf21b712cca48450014dbb0f748ac0c461e029
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Changing it must emit the same signals as does setting path, since the
sorting might change.
Change-Id: Iaf29c0775387d623d2e611e202b63ab52e812140
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
