tuscan
tuscan copied to clipboard
Identify the exact configure check that made configure die
During unsuccessful runs of configure, we should try to identify the exact command that made configure terminate. This might not necessarily be sub-invocations that didn't return 0, because sometimes configure creates checks that are expected to return non-zero. The check that made configure die is likely to be one of the 'last' checks.
This seems to be a difficult problem. In general, the configure process tree might be different from the vanilla one because configure will have taken different decisions based on the architecture and cflags etc. So it won't be enough simply to enumerate the differences to vanilla; we'll need to be more clever than that.
This is so that we can gain better insight into exactly what factors are killing builds. This issue depends on #99.