Hacker News Reader

Comment by lima | Hacker News Reader

Historical reasons - when Chromium was first open sourced, they really wanted to use Blaze, but that wasn't open sourced yet, so they built gn. Bazel (an open source subset of Blaze) wasn't a thing until much later.

Fuchsia is really close to the Chromium team and inherited gn and most of the supporting repo management and build tooling.

gn is less strict than Blaze and Google probably doesn't want to maintain both Bazel and gn forever, so it stands to reason that gn will eventually be replaced with Bazel. That will be a really large effort so it's probably not happening anytime soon and will take a while.

Android, which uses yet another home grown Blaze-alike build tool - Soong - is already in the process of migrating to Bazel. Moving from Soong to Bazel is probably much easier than going from Ninja/Make to Soong due to how conceptually similar those are.

View on HN

Of course, Android moving from a build system called Soong will mean they lose the best possible name for their build system.

https://memory-alpha.fandom.com/wiki/Noonian_Soong

I wasn't on the Chrome team, but on teams adjacent to it that used the Chromium codebase and toolset, and my recollection is that before gn there was gyp. ("Generate your project"). Gyp was a lot less Blaze-like.

Also I should mention one big difference between Bazel/Blaze and GN (and Gyp) is that the latter doesn't do the actual build, it generates a build that Ninja executes, instead.

Blaze owns the whole thing, executes the toolchain, etc.

Blaze is also very much built for the monorepo model we had in Google3. Not that it won't work in other scenarios, but that's where it came from: one repo and when it comes to third party dependencies, one version, etc. And cross-compiling on it felt awkward. GN/Ninja support for multiple toolchains and cross-compiling felt more thought-through, by necessity.

It seems that with current level of Bazel toolchain support it becomes much easier to crosscompile.

Well, something I'll test hopefully somewhat soon, as I want to test bazel explicitly in very crosscompiling environment...

It is done by some teams at Google, so definitely possible to do it decently enough to ship something.

My goal is to build bazel support for Ada, including building of crosscompilation toolchains and platform runtimes. Will see how it will work out :)

> GN/Ninja support for multiple toolchains and cross-compiling felt more thought-through, by necessity.

I'd argue this is still the case right now, but toolchain support in Bazel is maturing quickly.

This is correct. Gyp came first, then Evan Martin built ninja as a faster make, then Brett Wilson built gn ("generate ninja") because Gyp wasn't intuitive or convenient for a lot of use cases. I don't know if Googlers had an internal Blaze back then - I'm an outsider :)

Yes, blaze predates gyp, AFAIK. Blaze had been around for a long time before I ever arrived there in 2011. But exclusively for Google3 projects. Later I was on teams that used it for iOS dev, but not sure if that was always the case.

How do the build requirements for bazel and fuschia compare? Last I checked, bazel required python and a JVM and that seems like a lot for bootstrapping an OS.

Bazel's single-binary distribution brings its own JVM, it has less dependencies than gn.

Most people use Bazelisk: https://github.com/bazelbuild/bazelisk

Beyond that, it was also easier to conceive of a path towards self hosting with GN since it's written in c++. Neither java nor python can run natively on Fuchsia even today. That said Fuchsia's build system has a fair bit of python scripts anyways these days.

Reply on news.ycombinator.com