Earlier quoted context omitted.
More of just a graph like: V: (0001, 0002) E: ([0001, 0002], [0002, 0001]) But really I was just being sarcastic. Builds are "just" DAGs with syntactic sugar just like programs are "just" DAGs with syntactic sugar. That's one possible abstraction and one that is inherently lossy, because what "sugar" is available is the actual meat that makes one build system useful and another terrible. And one actually awful limita…
Right, I understand the graph metaphor, my objection is that programs in a turing complete language do not seem like they can exhaustively modeled as DAGs. Graphs, sure; but AFAICT DAGs fail due to the halting problem (in some abstract sense). A build system modelling itself as a DAG, on the other hand, is very consciously taking on acyclicity as a feature. I am curious what builds would need to be cyclic. Artifact A…
> I am curious what builds would need to be cyclic.
Compilers, interpreters, kernels, and the things that depend on them. So lots.
> Does that happen in any well-designed build?
Whether or not it's 'well designed' is irrelevant, the question is 'does it need to be possible' because even if it's rare it's still present in a lot of foundational software, notably GCC.