[RainyDayTmrw]

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.

[tonyedgecombe]

>Kinda impressive and terrifying that Chromium needs its own build system.

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.

[bluGill]

I stronly disagree. While you use a fraction of the features you often mistake it works for it is right and to something subtle is wrong. You end up either not working or dedicating a lot of effort fixing weird corner cases that you didn't think of

[tonyedgecombe]

>You end up either not working or dedicating a lot of effort fixing weird corner cases that you didn't think of

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.

[bluGill]

Now that I'm on a real computer (keyboard) maybe I can elaborate a bit.

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.

[bluGill]

It isn't worse than other corner cases - but for almost everyone it isn't what their boss wants them to spend all their time on. Even if working for your own fun you probably want to do something else.

[operator-name]

If Android was anything to go by, migrating build systems is a risky endeavour. Miso claims compatibility with ninja, so I’m guessing this route was deemed easier to make incremental improvements.

[jinwoo68]

To be fair, Bazel didn't exist when Chrome started.

[dijit]

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.

I say this as a fan of Bazel.

[7e]

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.

[dijit]

ChromeOS is Gentoo based.

It doesn't have any compiler in the distribution itself

[7e]

I’ll wager if you try to emerge a JVM on ChromeOS, especially on ARM32, it will fail. Gentoo is… not great.

[arccy]

moving to bazel might be a lot more work vs a drop in replacement which is what siso looks like atm.

[dijit]

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.

[oldmanhorton]

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.

[intexpress]

> That work building “yet another build tool” could have gone in to programmatically generating bazel BUILD files.

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.

[skybrian]

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.

[jefftk]

Bazel didn't even exist when they moved from gyp to ninja.

[westurner]

Blaze (and gtest) did exist then, but it was integrated with Omega scheduler.

[jinwoo68]

IIRC even blaze didn't exist. The Chrome project existed before I joined Google (in 2007) but blaze came out after I joined Google.