Building a Build System: Bazel Reaches Beta | Hacker News Reader

Building a Build System: Bazel Reaches Beta

google-opensource.blogspot.com

70 pointslaurentlb16 comments

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.

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!

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.

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

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.

Go support is on the roadmap and is being tracked by this GitHub issue: https://github.com/bazelbuild/bazel/issues/79

(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.

Is "Blaze" something else or an autocorrect/typo of "Bazel" (topic of this post)?

Blaze is the Google-internal thing. Bazel is its Open Source clone.

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)

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.

From the faq (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.

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.

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.

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

(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.

Reply on news.ycombinator.com