You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if any preceding dependent tasks fail, then the process will be aborted altogether. In this example, if any tests fail, then check-clippy and check-rustfmt will never be run, which the user may desire.
Proposal
According to the unwritten rules of quake's dependency system, it would be permissible to run any of the subsequent dependent tasks after another has failed, so long as such a task does not also depend on the failed tasks. As such, the build runner algorithm could be reimplemented with a greedier approach, which attempts to run as many tasks as possible before exiting (or waiting, as in watch mode).
For when you're actually building something though, fast failure is generally preferred. As such, the choice of whether to fast fail should be left to individual tasks or dependency declarations. Ideally, this would be determinable based on arguments passed to the task, which leaves the choice of either:
Adding a DSL command for task declaration blocks (e.g. no-fast-fail)
Adding an equivalent flag to depends (e.g. depends --no-fast-fail(-F) <dep_id>, alternatively --fallible(-F)).
Using a $task variable (planned for the future) to do $task.fast-fail = false
I prefer the second approach, turning the above build script into:
Motivating example
Consider the following build script:
Currently, if any preceding dependent tasks fail, then the process will be aborted altogether. In this example, if any tests fail, then
check-clippy
andcheck-rustfmt
will never be run, which the user may desire.Proposal
According to the unwritten rules of quake's dependency system, it would be permissible to run any of the subsequent dependent tasks after another has failed, so long as such a task does not also depend on the failed tasks. As such, the build runner algorithm could be reimplemented with a greedier approach, which attempts to run as many tasks as possible before exiting (or waiting, as in watch mode).
For when you're actually building something though, fast failure is generally preferred. As such, the choice of whether to fast fail should be left to individual tasks or dependency declarations. Ideally, this would be determinable based on arguments passed to the task, which leaves the choice of either:
no-fast-fail
)depends
(e.g.depends --no-fast-fail(-F) <dep_id>
, alternatively--fallible(-F)
).$task
variable (planned for the future) to do$task.fast-fail = false
I prefer the second approach, turning the above build script into:
The final
-F
in this example is of course redundant, but is left in for aesthetic/practical reasons.The text was updated successfully, but these errors were encountered: