I find Neil Mitchell's categories of small[1], medium[2], and huge[3] build systems useful. Blaze is absolutely fantastic as a huge build system, as it can correctly specify the exact semantics of systems with lots of components and complexities such as cross-language bindings, autogenerated files, etc. If you are building a huge system, then a small or medium build tool just won't be up to the task. At that kind of scale, somebody is going to be responsible for the build system working, possibly as a full time job, and it makes sense to tap somebody who understands how Bazel works and knows how to put those ideas into practice.
Conversely, as many comments here observe, it is terrible as a small build system. There, you want to be able to get started quickly and pull in dependencies without thinking too hard. A simple but easy to understand approach (even one based on make) might work. This is just a different problem than what Bazel solves.
My personal opinion (and I should emphasize, I am absolutely not speaking for anyone here, least of all Google) is that the best way forward is to take the ideas of Bazel (hermetic and deterministic builds) and package them as a good small build system, perhaps even compatible with Bazel so you don't have to rewrite build rules all the time. I also think compilers and tools can and should evolve to become good citizens in such a world. But I have no idea how things will go, it's equally plausible the entire space of build systems will continue to suck as they have for decades.
I completely agree with this, having spent an awful lot of time with both Bazel and Make. There is a much tighter, cleaner, simpler build system within Bazel struggling to get out. A judicious second take at it with a minimal focus, while taking some of the best ideas, could be wildly successful I think.
It's on my list of things that I will inevitably never get to.
> the best way forward is to take the ideas of Bazel (hermetic and deterministic builds) and package them as a good small build system, perhaps even compatible with Bazel so you don't have to rewrite build rules all the time.
Conversely, as many comments here observe, it is terrible as a small build system. There, you want to be able to get started quickly and pull in dependencies without thinking too hard. A simple but easy to understand approach (even one based on make) might work. This is just a different problem than what Bazel solves.
My personal opinion (and I should emphasize, I am absolutely not speaking for anyone here, least of all Google) is that the best way forward is to take the ideas of Bazel (hermetic and deterministic builds) and package them as a good small build system, perhaps even compatible with Bazel so you don't have to rewrite build rules all the time. I also think compilers and tools can and should evolve to become good citizens in such a world. But I have no idea how things will go, it's equally plausible the entire space of build systems will continue to suck as they have for decades.
[1]: http://neilmitchell.blogspot.com/2021/09/small-project-build...
[2]: https://neilmitchell.blogspot.com/2021/09/reflecting-on-shak...
[3]: https://neilmitchell.blogspot.com/2021/09/huge-project-build...