Kinda impressive and terrifying that Chromium needs its own build system. Kinda strange that Bazel was right there, also from Google, and they not only choose not to use it, but also reference it in the name of the new tool.
This is one area where I think it makes some sense to build your own. Most projects only use a fraction of the capability of a typical build system. The last time I did this I managed the whole thing in just 300 lines of code.
That's not my experience at all. Part of my job is to think about weird corner cases, I'm not sure why a build script should be any worse than what I normally deal with.
It isn't hard to create a basic build system. However there are a lot more rare corner cases than anyone who sets out to create one as a side project realizes and so in almost all cases their build systems work for the easy/common situations, but in lots of weird cases it doesn't work. Often those corner cases will happen on setups that make sense for one exactly person in the world but for everyone else is stupid. (think cross compiling on haiku-os for a vax running netbsd)
Which is to say if you want to create a build system that needs to be your only goal. You can maybe make the goal create the build system that some project needs (Chromium in this case) needs, but you won't be doing any hacking on the project (Chromium) itself because all your time will be spent on the build system.
Since everyone I know thinks of build systems as a side project they should just choose one that works. I use cmake, which works well despite the warts. I've heard good things about build2 and bazel, but I have no experience with either. I have used ninja as well (that is handwritten ninja files), but it isn't intended for that purpose and so in general I wouldn't recommend it.
I say this as a fan of Bazel.
It doesn't have any compiler in the distribution itself
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.
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.
Google did try that for Android (AOSP). They made a tool that generated thousands? of BUILD files to get AOSP building with Bazel.
But the migration to Bazel was aborted for unknown reasons.