Details
-
Sub-task
-
Resolution: Unresolved
-
P2: Important
-
None
Description
when configure probes are pulled in like other modules into the graph, their execution order is somewhat undetermined. however, it is desirable that all configure probes run as early as possible, to fail early on missing external dependencies. therefore it is necessary to prioritize some nodes during the topological sort.
another application of priorization would be injecting build phases that modify the graph, but cannot be (reasonably) represented via dependencies themselves. the "syncqt" step of the qt build comes to mind. it may be that this can be generalized to the c++ and qt scanners as well.
a notable difference between the configure and the syncqt case is the scope: the configure one should be global, i.e., no other build steps at all are executed while any configure nodes are still waiting, so that the configure results can be presented atomically. syncqt and the scanners otoh needs to block only a specific product.