I was just diagnosing a build where there was a long chain of targets. One of the 'internal' targets errors out, stopping the build. Here is a simplified diagram
A
| _ B
| _ C -> Errors out, stopping the build
| _ D
| _ E -> Actual target requested by the build
In the log viewer, I can easily see the results of targets A, B, and C, including a nice link between C and B (and B and A) that shows the dependency relationships. However, the final result of my investigation was that D should not have been called at all, but the log viewer didn't (or wasn't able) to show be why C was triggered (and so on, why D was triggered), because the error at C stopped the rest of the build processing.
Does this information exist today? If so, how should/could it be displayed?
I was just diagnosing a build where there was a long chain of targets. One of the 'internal' targets errors out, stopping the build. Here is a simplified diagram
In the log viewer, I can easily see the results of targets
A,B, andC, including a nice link betweenCandB(andBandA) that shows the dependency relationships. However, the final result of my investigation was thatDshould not have been called at all, but the log viewer didn't (or wasn't able) to show be whyCwas triggered (and so on, whyDwas triggered), because the error atCstopped the rest of the build processing.Does this information exist today? If so, how should/could it be displayed?