I want a better build executor
27 points by polywolf
27 points by polywolf
Perhaps I missed this, but it looks as if this isn’t solving the big problem that Ninja has: the lack of support for dynamically discovering edges in the build graph. This is something that C++ modules require and is a big part of the reason language like Rust and Java pretend to be a single step to any outer build system. Even LaTeX has this requirement: if you run latex, you may discover you need to rerun latex to update cross references, you need to run BibTeX to update dependencies, and so on.
Ninja supports dynamic dependencies.
https://ninja-build.org/manual.html#ref_dyndep
The blog post calls out the dyndep files explicitly.
It would parse depfiles and dyndeps files just after they’re built, while the cache is still hot
I was looking so long for the Tomorrow Corporation Tech Demo, but could not remember the title.
Other than in the header, I don't see any mention of determinism and how it relates to the proposed architecture.
Like n2, ronin would use a single-pass approach to support early cutoff. It would hash an "input manifest" to decide whether to rebuild. Unlike n2, it would store a mapping from that hash back to the original manifest so you can query why a rebuild happened.
Hm, why not fork/contribute this feature to n2 ?
The main advantage of Ronin is that it can slot in underneath existing build systems people are already using—CMake and Meson—without needing changes to your build files at all.
It looks like n2 has some affordances here too, and I guess it uses the same syntax as ninja.
From https://github.com/evmar/n2:
n2 can emulate the expected CMake behavior when invoked as ninja. To do this you create a symlink named ninja somewhere in your $PATH, such that CMake can discover it.
The EDN format seems superfluous ... why not use ninja syntax, or a superset of it?
Hm, why not fork/contribute this feature to n2 ?
n2 says in its readme "I wrote n2 to explore some alternative ideas I had around how to structure a build system. In a very real sense the exploration is more important than the actual software itself, so you can view the design notes as one of the primary artifacts of this." I don't think Evan is interested in radically changing the design; I've been chatting with him and the conversation was very much about this as a new thing, not an incremental improvement.
The EDN format seems superfluous ... why not use ninja syntax, or a superset of it?
It's not really EDN but clojure, since it allows def and defn. Using a programming language allows many more kinds of things, and IMO using a "real" language is the core of the design here. Here are some things in my "sample action graph" that would not be possible as a syntax extension to ninja:
sh -c
list-tar-files example. anything that's possible to hack into ninja would worse than simply using a shell script or python IMO. i like these because they're a lot more portable than shell scripts and avoid process spawning overhead for small things, spawning sed all the time adds up.groups have completely different semantics and it would be weird to have both groups and phonies in the same file format.In general I don't think reusing code is useful for its own sake; code is cheap these days. The value comes from improving on the design, and from getting real-world experience that shakes out the bugs.