We can't do that during parsing, as qbs::Project::buildSystemFiles()
might run into a race condition.
Change-Id: Iae3fd3000fdc71fec50c82d50fb3b4e3888351bc
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
So that recalculating the information is not O(n^2) but linear.
Change-Id: I69903e0b5ad321d071804d782ad634a3f300e71a
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
The current approach fails for all build systems where one project file
can define more than one executable.
Change-Id: Ieda413975709fbd6e7ea87b185aa962f63cb7c1f
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Prevent failures in situations where Qbs project files are still write
protected, like e.g. in Perforce VCS.
Change-Id: I2828546adcc314b7c6b0b6720e1cf96733d62fa5
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
This is in preparation for changes to the ProjectParts, where one part
can only hold files for 1 language.
Change-Id: If8a64895847806677d5cd51344ae774313798e00
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
If a qbs project gets closed (e.g. due to a session switch) while the
project is being loaded, the corresponding QFuture does not get deleted
and the progress bar will be around forever. This patch fixes that.
Note: The project resolving by qbs was already correctly canceled; this
is about the visual effect only.
Change-Id: If00aed949505088cfdb87d08e26f3b62ccea5fd1
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This already works for Desktop run configurations, because they get
special treatment for historical reasons. But it does not currently work
for targets such as RemoteLinux.
Change-Id: Iba5191538314146909567bc7b5993dcc0b9d21cd
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>
This fixes the bug that the "run" action fails if the project has not
been built before (because the path to the executable is still unknown
after the build due to the missing project data update).
Change-Id: I953cbb85051a1de78fcb0490abf58ebc9fcec6e7
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This removes qmakeprojectmanager and qmlprojectmanager dependency on
qmljstools.
Qmlprojectmanager still imports qmltoolsconstants.h for a constant
but that gives no runtime dependency.
Change-Id: Ifd2e76500a3b27a21937603925f03a70049900e1
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.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>
- Remove unneeded forward declarations (the header file is included
already).
- Move QVariantMap include from header to cpp file.
- Remove pointless "const" in front of function return type.
- In projectData(), return the stored value instead of fetching it again
from the project.
Change-Id: I9c8f4e8eaea070833953cd4d65e3452bae37998d
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
This differentiation complicates the code and duplicates checks
already done in qbs.
Just let the library reparse the project; if it turns out that nothing
has to be done, then the operation will be fast.
Change-Id: Ib6406f254e51541c69c948f275fff7877b65b4bd
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
That is, if qbs::Project::projectData() has changed. There are still
some false positives left (e.g. the project nodes will also update if
only the file paths of executables have changed), but we can deal with
those later.
Change-Id: Ifa18903aba41c21769bfe4cd0e4f6004f1a94f11
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Otherwise, if "save before build" is enabled and the user presses Ctrl+B
with unsaved changes to a project file, these would get ignored due to
the delay (and also if the delay were not there, because the file system
watchers trigger later than the "Build" action).
If there are no actual changes to any build file, the overhead caused by
this operation consists of loading (and possibly storing) the build
graph file.
Task-number: QBS-596
Change-Id: I1f837cc0fcdc77a249b423834f4b6711f5c0bc87
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The current code simply asserts when a new parse request comes in while
parsing. However, that condition is easily triggered, for instance if a
project file is saved to disk during a parse operation. Such updates
currently have no effect at all (other than triggering an error
message).
Instead, we now cancel the old parse job and start a new one.
Change-Id: If2eeb93b85b5163dcea99785a0fc89a254d082db
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
While it is true that additional information about target
artifacts can appear during a build, this data is already
present in the qbs::Project object and can simply be retrieved.
No reparsing is necessary.
The exception is when reparsing was requested while the build
was going on. In that case, we really need to do it after
the build has finished.
Change-Id: Ief3797782ad0ca5651974d4b5d3d64e1199ca9a5
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>
Instead of having two lists of paths, now only one list is used where
both include paths and framework paths can be mixed. This reflects the
way the compiler is invoked, and retains the (correct) search order.
Task-number: QTCREATORBUG-11599
Change-Id: I373953e3e305df5b7a0d10920e12d146584adf9f
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
And also in the qbs sub-project (for the qbs and qmake builds). This
becomes possible with the qbs submodule update that is part of this
patch.
Change-Id: I8347a8c04a52bcb0682f32d808fb61a90ef3ba72
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Qbs may update the buildgraph during the build, so this information
may be lost if we reparse at the same time.
Change-Id: Id52e42552736bbe842581cc87d837d0834ad0a2c
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
They are not (arch-independent) resources.
Task-number: QTCREATORBUG-10074
Change-Id: If257dfc3a8a866003c84331409162699b162eb19
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Currently ModelManager contains lot logic, but as it sits in QmlJSTools
it is not possible to use it in standalone tests.
Moving most of the logic to ModelManagerInterface (and cleanup)
to allow better testing, and refactoring.
This introduces a dependency of the qmljs lib on the cplusplus lib
Also a (small) part of the CppTool::ModelManagerInterface has been
moved to CPlusPlus::CppModelManagerBase to remove the dependency on
CppTools to gather the Qml types exposed from C++.
Change-Id: Icad7fe96dfd0f1a2b1058d82bd98c77c40aa5e9d
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
Includes some necessary adaptations to the QbsProjectManager plugin,
namely:
- Use the new library for setting up Qt profiles.
- Use per-profile preferences.
Change-Id: I0a639bd291d790c6da9cb4ade53841314310d5ef
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
This fixes the problem of Qt Creator not getting the cxxFlags set in
Qbs.
Task-number: QBS-481
Change-Id: Ie233123d62bcf89f3b8ebee1367ca6447b9ade3a
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
So we can ignore possibly problematic toolchain-defines, while can still
unconditionally apply project-defines.
Change-Id: I7cb96f35a963d080011fe888ef71bfc098dd33ef
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
... even if Qt Creator thinks all is well.
Change-Id: I40fa61d51c8e18a389bedf7d8afb927bbb88acd5
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
Looks like you need to do that after canceling it... This stops
"Evaluation" progress bars from sticking around.
Change-Id: Ie0a9f88ba96cba261939c210fddb11bc43779416
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
