Even so, a build system migration of any kind being anything other than Bazel given the design goals of Bazel and the heritage of Chrome is an implicit indictment of Bazel itself.
Most likely Chromium needs to build on a system which doesn’t support Java. Like ChromeOS. That excludes Bazel, at least unless cross-compilation is supported (likely a monstrous headache for ChromeOS). It’s a good reason to rewrite Bazel in Rust.
Yeah, thats fair, but if I understood right- this is a custom built tool to be compatible with Ninja.
That work building “yet another build tool” could have gone in to programmatically generating bazel BUILD files. So, there was an active choice here somewhere; we just don’t know all the information as to why effort was diverted away from Bazel and toward building a new tool.
I trust them to make good decisions, so I would like to understand more. :)
Seems like Siso supports Starlark, so maybe its a step in Bazels direction after all.
There is a ton of tools and custom logic used by/with/for the GN ecosystem in chromium that I imagine would be difficult to port.
This tool is substantially less complex than Bazel, nor is it a reimplementation of Bazel. Ninja's whole goal in life is to be a very fast local executor of the command DAG described by a ninja file, and siso's only goal is to be a remote executor of that DAG.
This is overall less complex than their first stabs at remote execution, which involved standing up a proxy server locally and wrapping all ninja commands in a "run a command locally which forwards it to the proxy server which forwards it to the remote backend" script.
It reminds me of how Blaze (which became Bazel) was designed to be mostly compatible with the build files of a previous build system written in Python.
I say this as a fan of Bazel.