| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Long-running commands are handled already, but badly written project
files could still hang qbs with e.g. infinite JS loops on the right
hand side of a binding. Such code can now also be interrupted.
Change-Id: Ie0d114bd37d540e764d5ec5bb323c91bfd64a67a
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
| |
|
|
|
|
|
|
|
|
| |
At the moment, canceling a build waits for the current
command to finish, which means that a badly behaving process
or piece of JavaScript code can block qbs indefinitely.
Task-number: QBS-552
Change-Id: I8ac23f068dd6083905a9681097da6b970c0b646b
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The classes as they are now specify different signals for signaling
failure and finishing. Some of these error() signals are followed by a
finished() signal, others are not, which is just asking for trouble.
Under certain circumstances there can also be several error() signals
for one and the same process. In fact, there is almost certainly a race
condition there regarding executor job re-use.
This patch changes the design so that there is always exactly one
finished() signal that carries an error status. For some non-fatal
problems that higher-level code cannot sensibly handle, we now log a
warning instead of emitting an error signal.
Change-Id: I9e3df11564e7337ad766ca0d009303367d43c4ec
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These had several problems.
Firstly, the "changed files" case was implemented by setting all
artifacts to "Built" and then setting the ones to "Buildable" that were
reachable bottom-up from artifacts corresponding to the respective files.
This approach broke with the introduction of rule nodes, because
parent nodes do not necessarily exist yet at initialization time. This
was not caught due to the lack of an autotest.
Secondly, the logic behind the "build single file" functionality was
faulty. The assumption was that this could be implemented on top of the
"changed file" functionality, which is wrong: Consider the case where
you have several cpp files that have not yet been built. Now
marking one of them as changed and filtering by the "obj" tag will still
cause all of them to be compiled, as we cannot simply exclude all other
source files from being built, which would break the build for the
normal "changed files" case without tag filtering. Therefore we need a
dedicated list of input files by which we can filter transformers.
Task-number: QBS-537
Change-Id: I47e2ba6d0cbd073561064640eaf8f63c4e0b39fa
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
| |
|
|
|
|
|
|
|
| |
We must absolutely never do that, as it can mess with the state management,
leading to disastrous results.
In effect, this reverts commit ea269191f4.
Change-Id: Ib5ec6e00264312aaabd066ed9adedb65f315fdef
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
| |
|
|
|
|
|
| |
Transformers are what jobs work on, not artifacts.
Change-Id: Ib267ec247dd6d165347511f0a0fdb3db00c58832
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
| |
|
|
|
|
|
|
| |
Remove unused function and merge functions that were (nearly) doing the
same thing.
Change-Id: I33276068d5595456832ed44a0ff2d5705a87165a
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support different types of nodes in the build graph, we introduce
the base class BuildGraphNode. Artifact now derives from BuildGraphNode.
A RuleNode class is introduced that represents a rule in the build graph.
Rules are applied in the build phase and not in a pre-build phase
anymore.
The handling of moc has been revisited. The fixed automoc pre-build
phase is no more.
This is the squashed merge of a feature branch.
Task-number: QBS-370
Change-Id: If27cdc51cba8c9542e4282c2caa456faa723aeff
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
- Reduce the scope of some code only relevant to one respective
function.
- Introduce small functions for identifiable tasks.
As a result, the top-level build function becomes less cluttered and it
is easier to grasp what is going on.
Change-Id: I4a12ad0f3f94211630460d4e51cd0bdfec3c4166
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
| |\ |
|
| | |
| |
| |
| | |
Change-Id: I2c4aa7cb7ec7db58577ceac5cb56bc925ae9360f
|
| |/
|
|
|
|
|
| |
We have a canonical way to check whether to print debug messages.
Change-Id: I922559517b138bc31f55034529fe10ff35a9500e
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
| |
|
|
|
|
|
| |
Now the name reflects reality.
Change-Id: I3997b99de86819c973434240103d25d6915d838b
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
|
| |
|
|
|
| |
Change-Id: Ib39e49e896cbddf5a5bd851088500991d962355a
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
|
| |
|
|
| |
Change-Id: I7319a1deea008c9f4df077eaecf3147872fc4a21
|
|
|
Otherwise all changes to the implementation will have to be duplicated
in IDEs.
Change-Id: I61e6d4fa1ee9b724eb5d9de9f233dc915a6c8bc3
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
|
