Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't wait until all tasks have failed before outputting error text #60

Open
jyn514 opened this issue Oct 13, 2021 · 1 comment
Open

Comments

@jyn514
Copy link
Contributor

jyn514 commented Oct 13, 2021

Due to Ekam's build model, it doesn't know whether a task will succeed later when more dependencies have finished building. As a result, it waits until all tasks have failed before outputting any errors. This is frustrating when the tasks take a long time to run (e.g. when one test out of several dozen fails), especially if the tasks are in fact independent.

I don't know if this can be solved in the general case, but #24 might help with the case where the tasks are independent since Ekam will know it doesn't need to wait for the other tests to fail.

@kentonv
Copy link
Member

kentonv commented Oct 15, 2021

This is tough, because it's hard for Ekam to know if rules that run later might produce a new artifact which changes the result of a previous rule.

  • We could maybe output the error if all dependencies were successfully resolved... but even that can theoretically be premature, as it's possible that an artifact generated later will be a more-exact resolution. For example, say someone has Cap'n Proto installed on their system, but is trying to build a new version from source... an include for <capnp/compan/byte-stream.capnp.h> might resolve to the system-installed copy early on, but the in-tree copy may be generated later, requiring the dependent to be rebuilt.

  • We could perhaps use knowledge of the dependency tree from a previous build to decide when we think all dependencies are done, but this could lead to incorrect results whenever the dependency tree has changed between builds (e.g. the developer added a new include).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants