
Building a Build System: Bazel Reaches Beta - laurentlb
http://google-opensource.blogspot.com/2015/09/building-build-system-bazel-reaches-beta.html
======
varikin
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.

~~~
GauntletWizard
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.

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

~~~
adonovan
(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
Is "Blaze" something else or an autocorrect/typo of "Bazel" (topic of this
post)?

~~~
e98cuenc
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
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.

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

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

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

