4 ms·

Building a Build System: Bazel Reaches Beta

70 points by laurentlb 11y ago

kzhahou 11y ago
Surprised to not see mention of golang. Does anyone know if that's because even at Google scale, the simple "go build" command suffices?
- varikin 11y ago
  If I recall correctly, there was something about one of the main motivations in creating Go was to simplify build systems (partly reduce file reads of duplicate header files), so I imagine "go build" was designed to work at Google's scale. Also, apparently Bazel only contains like 10% of the build rules that Blaze has. Blaze being the internal version of Bazel. Some of those rules are Google specific, but I believe I read that some of them they would like to port (untangle from proprietary stuff) to Bazel, just haven't had the time to do so yet.
- cap_theorem 11y ago
  Go support is on the roadmap and is being tracked by this GitHub issue: https://github.com/bazelbuild/bazel/issues/79 https://github.com/bazelbuild/bazel/issues/79
- adonovan 11y ago
  (Former Blaze engineer and current Go tool builder here.) Blaze's support for building Go source code predates the existence of the 'go' tool and uses very different conventions for package naming, directory layout, testing, and project organization. As a result, most Google Go code cannot be built with 'go'. This can be a source of frustration at times.
  - defen 11y ago
    Is "Blaze" something else or an autocorrect/typo of "Bazel" (topic of this post)?
    - qznc 11y ago
      Blaze is the Google-internal thing. Bazel is its Open Source clone.
    - e98cuenc 11y ago
      Blaze is the internal name of Bazel in Google (I don't know if both projects are identical, or if Blaze was just the "inspiration" for Bazel)
      - asuffield 11y ago
        They refer to distinct things but share a lot of their code. Blaze doesn't contain anything that you would find useful, you need our infrastructure for its other features to work.
    - activez 11y ago
      From the faq (http://bazel.io/faq.html http://bazel.io/faq.html): Did you rewrite your internal tool as open-source? Is it a fork? Bazel shares most of its code with the internal tool and its rules are used for millions of builds every day. What's up with the word "Blaze" in the codebase? This is an internal name for the tool. Please refer to Bazel as Bazel.
varikin 11y ago
I looked into Bazel. I like it overall, but it makes a lot of assumptions about the layout of your projects. For example, the java_test rule looks for all classes under a java or javatests folder trying to figure out the package and full Java class name to feed into the JUnit runner. I understand this is a standard Maven layout, but we don't have a standard Maven layout (not using Maven). Instead of the java_test rule failing, it passes because no tests failed, but no tests were found either... It figure this out, I had to patch Bazel with printlns where tries to find all the tests. A coworker found a similar issue with assumptions around the project layout, but I can't remember what it was. Being that Bazel is was Alpha at the time, now Beta, I am not going to write it off yet. If nothing else, better documentation about assumed layouts would be great.
- skybrian 11y ago
  Actually, that's not Maven. In Maven, each project has its own java directory. With Blaze (and I assume Bazel), Java libraries from entirely different projects all live in the same giant java and javatests subtrees. Behold the glory of the monolithic repository!
- GauntletWizard 11y ago
  Bazel's opinionated nature is it's blessing and curse. If you follow it's rules (fairly simple, internally consistent, and well thought out), it's amazing, and you need think a lot less about "where does this file go?", etc. If you don't have all those rules in your head, or if you're inconsistent about them, it's a nightmare. Thankfully, it's a nightmare that can be fixed, and it behooves you to do so: Bazel's simple artifacts and build speedups are well worth the time you spend converting to it.
rough-sea 11y ago
how does this relate to chromium's gn project (https://groups.google.com/a/chromium.org/forum/#!forum/gn-dev https://groups.google.com/a/chromium.org/forum/#!forum/gn-de...)
- evmar 11y ago
  (Disclaimer: worked in this area, haven't in a few years, my facts are sketchy.) Bazel is open-sourcing of the build system used to build the majority of code within Google. Chrome (in part because it targeted Windows) didn't use the standard build system and instead has had its own series of custom replacements. gn is the latest iteration on that. As other commenters have mentioned, Bazel expects your code to be organized in the way Google code is, while gn likely makes similar assumptions related to how Chrome is organized.
malkia 11y ago
Still no menu :) - Just kidding! Kudos to the team! As someone who works at Google, I can only bow my head to the "bazel/blaze" team. After spending years with crude Makefiles, verbose .vcxproj/.sln files, and many other weird build systems I can say blaze works really good for me, and I hope to use for my pet projects outside.
Animats 11y ago
Yet another build system with built-in conventions about where everything should be. Of course, we now have Go and Rust, with different conventions and their own build systems, plus Github, which has its own preferred layout. A wall chart with all the directory conventions would be useful.

70 points by laurentlb 11y ago

Surprised to not see mention of golang. Does anyone know if that's because even at Google scale, the simple "go build" command suffices?

varikin 11y ago
If I recall correctly, there was something about one of the main motivations in creating Go was to simplify build systems (partly reduce file reads of duplicate header files), so I imagine "go build" was designed to work at Google's scale. Also, apparently Bazel only contains like 10% of the build rules that Blaze has. Blaze being the internal version of Bazel. Some of those rules are Google specific, but I believe I read that some of them they would like to port (untangle from proprietary stuff) to Bazel, just haven't had the time to do so yet.
cap_theorem 11y ago
Go support is on the roadmap and is being tracked by this GitHub issue: https://github.com/bazelbuild/bazel/issues/79 https://github.com/bazelbuild/bazel/issues/79
adonovan 11y ago
(Former Blaze engineer and current Go tool builder here.) Blaze's support for building Go source code predates the existence of the 'go' tool and uses very different conventions for package naming, directory layout, testing, and project organization. As a result, most Google Go code cannot be built with 'go'. This can be a source of frustration at times.
- defen 11y ago
  Is "Blaze" something else or an autocorrect/typo of "Bazel" (topic of this post)?
  - qznc 11y ago
    Blaze is the Google-internal thing. Bazel is its Open Source clone.
  - e98cuenc 11y ago
    Blaze is the internal name of Bazel in Google (I don't know if both projects are identical, or if Blaze was just the "inspiration" for Bazel)
    - asuffield 11y ago
      They refer to distinct things but share a lot of their code. Blaze doesn't contain anything that you would find useful, you need our infrastructure for its other features to work.
  - activez 11y ago
    From the faq (http://bazel.io/faq.html http://bazel.io/faq.html): Did you rewrite your internal tool as open-source? Is it a fork? Bazel shares most of its code with the internal tool and its rules are used for millions of builds every day. What's up with the word "Blaze" in the codebase? This is an internal name for the tool. Please refer to Bazel as Bazel.

varikin 11y ago

I looked into Bazel. I like it overall, but it makes a lot of assumptions about the layout of your projects. For example, the java_test rule looks for all classes under a java or javatests folder trying to figure out the package and full Java class name to feed into the JUnit runner. I understand this is a standard Maven layout, but we don't have a standard Maven layout (not using Maven). Instead of the java_test rule failing, it passes because no tests failed, but no tests were found either... It figure this out, I had to patch Bazel with printlns where tries to find all the tests. A coworker found a similar issue with assumptions around the project layout, but I can't remember what it was. Being that Bazel is was Alpha at the time, now Beta, I am not going to write it off yet. If nothing else, better documentation about assumed layouts would be great.

skybrian 11y ago
Actually, that's not Maven. In Maven, each project has its own java directory. With Blaze (and I assume Bazel), Java libraries from entirely different projects all live in the same giant java and javatests subtrees. Behold the glory of the monolithic repository!
GauntletWizard 11y ago
Bazel's opinionated nature is it's blessing and curse. If you follow it's rules (fairly simple, internally consistent, and well thought out), it's amazing, and you need think a lot less about "where does this file go?", etc. If you don't have all those rules in your head, or if you're inconsistent about them, it's a nightmare. Thankfully, it's a nightmare that can be fixed, and it behooves you to do so: Bazel's simple artifacts and build speedups are well worth the time you spend converting to it.

rough-sea 11y ago

how does this relate to chromium's gn project (https://groups.google.com/a/chromium.org/forum/#!forum/gn-dev https://groups.google.com/a/chromium.org/forum/#!forum/gn-de...)

evmar 11y ago
(Disclaimer: worked in this area, haven't in a few years, my facts are sketchy.) Bazel is open-sourcing of the build system used to build the majority of code within Google. Chrome (in part because it targeted Windows) didn't use the standard build system and instead has had its own series of custom replacements. gn is the latest iteration on that. As other commenters have mentioned, Bazel expects your code to be organized in the way Google code is, while gn likely makes similar assumptions related to how Chrome is organized.

malkia 11y ago

Still no menu :) - Just kidding! Kudos to the team! As someone who works at Google, I can only bow my head to the "bazel/blaze" team. After spending years with crude Makefiles, verbose .vcxproj/.sln files, and many other weird build systems I can say blaze works really good for me, and I hope to use for my pet projects outside.

Animats 11y ago

Yet another build system with built-in conventions about where everything should be. Of course, we now have Go and Rust, with different conventions and their own build systems, plus Github, which has its own preferred layout. A wall chart with all the directory conventions would be useful.