5 ms·
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 s
by lima 5y ago
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.
- surajrmal 5y agoBeyond 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.
- humanrebar 5y agoHow 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.
- lima 5y agoBazel's single-binary distribution brings its own JVM, it has less dependencies than gn. Most people use Bazelisk: https://github.com/bazelbuild/bazelisk https://github.com/bazelbuild/bazelisk
- cmrdporcupine 5y agoI 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.
- cmrdporcupine 5y agoAlso 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.
- p_l 5y agoIt 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...
- cmrdporcupine 5y agoIt is done by some teams at Google, so definitely possible to do it decently enough to ship something.
- p_l 5y agoMy goal is to build bazel support for Ada, including building of crosscompilation toolchains and platform runtimes. Will see how it will work out :)
- lima 5y ago> 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.
- ckocagil 5y agoThis 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 :)
- easton 5y agoOf 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 https://memory-alpha.fandom.com/wiki/Noonian_Soong