4 ms·
> It seems to me that all build systems are just DAGs Yeah, well, it's a little bit more than that. Two things come to mind that don't neatly fit the DAG ment
by ur-whale 3y ago
> It seems to me that all build systems are just DAGs
Yeah, well, it's a little bit more than that.
Two things come to mind that don't neatly fit the DAG mental framework:
- dynamically generated dependencies (e.g. when you compile a C++ file only to discover that it #includes something and therefore has a dependency on that thing, and therefore the DAG has to be updated on the fly). Creating them by hand is horribly tedious, and/or borderline impossible (#includes that #include other #include ad infinitum)
- reproducible builds, where a build system is capable of rebuilding a binary from scratch down to having not a single different bit in the final output assuming the leaves of the DAG haven't changed. A desirable feature that is darn near impossible to do unless you pair the DAG with something else.
- mike_hock 3y ago- detection/management of external dependencies - defining different build types (debug/release) - optionally building and running tests - incremental builds (detecting what has changed) That doesn't necessarily run counter to the concept of a DAG, but the organizational structures to manage this is what makes the build system. Topologically sorting the dependencies isn't the hard part. That's why make isn't a build system. It is the generic DAG runner, but that's not sufficient.