2 ms·
I wonder if the author has read the paper "Build Systems A La Carte" [1], which defines a taxonomy of build systems (of which Excel is part!) and their fundamen
by AceJohnny2 4y ago
I wonder if the author has read the paper "Build Systems A La Carte" [1], which defines a taxonomy of build systems (of which Excel is part!) and their fundamental concepts.
This:
> I have to use hacks like .PHONY to mark rules as virtual.
makes me think not (.PHONY is required because fundamentally Make uses the filesystem as the "Store", or cache, for what is built, and rules just define Store targets)
It's been 5 years since the paper, and I'm still hoping for a a production-ready project that leverages its lessons to create an agnostic, distributed build system.
Nevertheless, excellent work in Knit! I'm always happy to see interest in the build system space. I particularly appreciate the use of Lua as the scripting layer. Make's scripting layer is certainly... limited. Also, great to see consideration for generated dependencies (like extracted header files)!
[1] https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems.pdf https://www.microsoft.com/en-us/research/uploads/prod/2018/0...
- AceJohnny2 4y agoOh and tangentially, because it's amusing: why does Make use tabs? Because the original Lex was troublesome and it was convenient in the prototype. Then, there were dozens of users and it was too late to change! https://beebo.org/haycorn/2015-04-20_tabs-and-makefiles.html https://beebo.org/haycorn/2015-04-20_tabs-and-makefiles.html
- zyedidia 4y agoThanks! Perhaps I shouldn't have characterized phony rules as a hack, but just that I think it is cleaner to express that information directly in the rule rather than in a separate rule. The paper you link is great, and I should read it in more depth -- are there any particular lessons or insights from it that you think Knit or other build systems could benefit from?
- AceJohnny2 4y agoIt's been a while, but one of the more powerful insights I remember, in this era of compute farms, is abstracting out the Store to be cloud-aware (kinda like ccache, but integrated in the builder. I think Bazel does this?)
- irq-1 4y agoIf you haven't seen it: https://github.com/rochus-keller/BUSY https://github.com/rochus-keller/BUSY > BUSY is a lean, statically typed, cross-platform, easily bootstrappable build system for GCC, CLANG and MSVC inspired by Google GN It uses lua and config files that are mostly directories and filenames.
- aseipp 4y agoYou should look at Buck2. One of the coauthors of that paper (Neil) is one of the lead developers, and unlike Buck1 the buck2 binary exposes a very tiny API that consumers then build off of, and define all their rules, using Starlark for everything. This means that your build rules and your code exist together, as they should. And it recently started supporting the remote build API that Bazel does, so distributed builds and caching already work as they should. It's a very exciting project in the space.