3 ms·

What do people here think of Bazel [1]? In my understanding it is an open-sourced version of the build system that Google uses internally. [1] https://bazel.bu

What do people here think of Bazel [1]? In my understanding it is an open-sourced version of the build system that Google uses internally. [1] https://bazel.build/ https://bazel.build/

zellyn 7y ago
Bazel is about as far from redo as you can get: they aim to solve very different problems. If you have a huge monorepo, and thus need distributed caching and distributed builds, and cross-language dependency tracking and incremental rebuilds, Bazel is for you. It has the advantage of being built _after_ Google understood all the places where lack of rigor or accidentally-too-capable build language features cause trouble.
- zellyn 7y ago
  (At Square, we currently use Pants for our Java monorepo. Don’t do that; we’re switching.)
  - csande17 7y ago
    What's wrong with pants?
    - zellyn 7y ago
      It's not widely used. Pure Java (rather than Scala) seems off the beaten track. The documentation is sparse. The IDE plugins are less capable, and less documented. It is sloppy about rigorously declaring needed files. It's slow just to start up. Actual Python rather than Starlark as a build language. The API from custom rules to internals is leakier (I believe). Bazel has a huge ecosystem of third-party rules to do all sort of things.
tbrock 7y ago
We’ve been using it to build and deploy a ~500k loc JavaScript monorepo and I have an unpopular opinion about it. While I see the benefits of it for google scale, for us it’s just been one headache after another. Reimplementation of python for build file language? No thanks. Reimplementation of package managers? No thanks. Reimplementation of Docker? No thanks. It’s just another thing to learn, worry about, and discover bugs in rather than something that just works. I already know how docker, yarn, and python work and that stuff works well, why are we boiling the oceans recreating and relearning all of this just to do it the “Bazel” way? What a waste of time and energy!
- elteto 7y ago
  Man, I'm sorry to hear about your experience :( I've used bazel in a different environment (C++) and it has been amazing (compared with other C++ build systems). Another comment below mentioned to stay away from bazel for anything else other than C++ (and maybe Java).
  - novok 7y ago
    Bazel is also the build system to use if you have large iOS swift applications, with it's networked HTTP build cache and so on. I've also seen it used with java android apps.
  - tbrock 7y ago
    Thanks! As you probably know, c++ is definitely unique in that there is no built in way to manage dependencies and no de facto package manager. I would definitely use it for a cpp project.
- kinkrtyavimoodh 7y ago
  Could you talk a bit about your experience? The two points you mentioned feel more like theoretical / principled opinions rather than on the ground experience / issues
  - tbrock 7y ago
    Everything feels beta. It crashes on about 10% of our builds with an inscrutable java error deep in the bowels of bazel. The solution, according to the bazel authors, is to rebuild, which works so our ci pipeline has an auto retry mechanism because bazel is so buggy. I’m not joking. On top of a that, everyone on my team had to learn skylark, their rules for docker, their rules for node, their... I’m exhausted just thinking about it... Why bother unless you’ve got google size? It’s good software written by smart people, but I know I made a mistake in choosing it for our build solution.
    - asdfasgasdgasdg 7y ago
darren0 7y ago
If you program C++ give it a shot. For all other languages stay far from it.
mehrdadn 7y ago
There are a lot of things I like about it, and I like how robust it is once it works. But what I don't like is probably more interesting: Getting it to work can sometimes be a pain in the rear (although I'm not sure other systems fare much better). I'm still trying to figure out some missing header file errors... some are obvious and easy to fix, but but some are confusing as heck. I also hate the fact that I have to specify header files redundantly, once in the source file and once in the build tool. Their documentation can also be painful to quickly find stuff in (e.g. try finding how to display the command line options passed to the C++ compiler); sometimes some flags are just spread out in the prose rather than in the normal table format. Their @// notation is not exactly intuitive; I'm still not sure I fully understand it. And lastly, there are lots of rough edges, e.g. there's no way to call an existing Makefile and pass it conditional compiler options, so good luck sharing your compile flags across the entire codebase in an elegant manner.
nagisa 7y ago
I have dealt with it as part of packaging and adapting tensorflow. Some of my opinions: * Bazel needs gigabytes of memory to run; * It needs minutes to bootstrap (which it will every time, because you don’t want a multi-gigabyte-sized daemon running around); * It breaks every second day. If you are building version X of $something, you better go and get the exact version of Bazel that the developers of $something were using when tagging X; * And when they fail to build there’s no chance you will be able to figure it out without spending days on it. Don’t use Bazel unless writing code that only you yourself can maintain is your goal.
majidfn 7y ago
We had a difficult experience with Bazel as well using it for a Go project. As mentioned it brings its own reimplementation of any compiler or package manager. So if there is a new feature from the language, you have to wait till the Bazel rules for that language gets updated, only then you can start using it. For a Go project which the whole build command is a single line of `go build`, it takes lots of config files and configuration, and tweaking till you get the exact same result. Only till there is an update and the whole build crashes and you have to figure it out why. To me m, Bazel is a great tool for Google or a project at the scale of Google projects. It is beneficial if you can benefit from distributed builds and caching layers. Only for a project big enough that those could make a difference. But for all other projects, Bazel, felt like brining an 18-wheeler to go to grocery shopping.

What do people here think of Bazel [1]? In my understanding it is an open-sourced version of the build system that Google uses internally. [1] https://bazel.build/ https://bazel.build/

zellyn 7y ago

Bazel is about as far from redo as you can get: they aim to solve very different problems. If you have a huge monorepo, and thus need distributed caching and distributed builds, and cross-language dependency tracking and incremental rebuilds, Bazel is for you. It has the advantage of being built _after_ Google understood all the places where lack of rigor or accidentally-too-capable build language features cause trouble.

zellyn 7y ago
(At Square, we currently use Pants for our Java monorepo. Don’t do that; we’re switching.)
- csande17 7y ago
  What's wrong with pants?
  - zellyn 7y ago
    It's not widely used. Pure Java (rather than Scala) seems off the beaten track. The documentation is sparse. The IDE plugins are less capable, and less documented. It is sloppy about rigorously declaring needed files. It's slow just to start up. Actual Python rather than Starlark as a build language. The API from custom rules to internals is leakier (I believe). Bazel has a huge ecosystem of third-party rules to do all sort of things.

tbrock 7y ago

We’ve been using it to build and deploy a ~500k loc JavaScript monorepo and I have an unpopular opinion about it. While I see the benefits of it for google scale, for us it’s just been one headache after another. Reimplementation of python for build file language? No thanks. Reimplementation of package managers? No thanks. Reimplementation of Docker? No thanks. It’s just another thing to learn, worry about, and discover bugs in rather than something that just works. I already know how docker, yarn, and python work and that stuff works well, why are we boiling the oceans recreating and relearning all of this just to do it the “Bazel” way? What a waste of time and energy!

elteto 7y ago
Man, I'm sorry to hear about your experience :( I've used bazel in a different environment (C++) and it has been amazing (compared with other C++ build systems). Another comment below mentioned to stay away from bazel for anything else other than C++ (and maybe Java).
- novok 7y ago
  Bazel is also the build system to use if you have large iOS swift applications, with it's networked HTTP build cache and so on. I've also seen it used with java android apps.
- tbrock 7y ago
  Thanks! As you probably know, c++ is definitely unique in that there is no built in way to manage dependencies and no de facto package manager. I would definitely use it for a cpp project.
kinkrtyavimoodh 7y ago
Could you talk a bit about your experience? The two points you mentioned feel more like theoretical / principled opinions rather than on the ground experience / issues
- tbrock 7y ago
  Everything feels beta. It crashes on about 10% of our builds with an inscrutable java error deep in the bowels of bazel. The solution, according to the bazel authors, is to rebuild, which works so our ci pipeline has an auto retry mechanism because bazel is so buggy. I’m not joking. On top of a that, everyone on my team had to learn skylark, their rules for docker, their rules for node, their... I’m exhausted just thinking about it... Why bother unless you’ve got google size? It’s good software written by smart people, but I know I made a mistake in choosing it for our build solution.
  - asdfasgasdgasdg 7y ago

darren0 7y ago

If you program C++ give it a shot. For all other languages stay far from it.

mehrdadn 7y ago

There are a lot of things I like about it, and I like how robust it is once it works. But what I don't like is probably more interesting: Getting it to work can sometimes be a pain in the rear (although I'm not sure other systems fare much better). I'm still trying to figure out some missing header file errors... some are obvious and easy to fix, but but some are confusing as heck. I also hate the fact that I have to specify header files redundantly, once in the source file and once in the build tool. Their documentation can also be painful to quickly find stuff in (e.g. try finding how to display the command line options passed to the C++ compiler); sometimes some flags are just spread out in the prose rather than in the normal table format. Their @// notation is not exactly intuitive; I'm still not sure I fully understand it. And lastly, there are lots of rough edges, e.g. there's no way to call an existing Makefile and pass it conditional compiler options, so good luck sharing your compile flags across the entire codebase in an elegant manner.

nagisa 7y ago

I have dealt with it as part of packaging and adapting tensorflow. Some of my opinions: * Bazel needs gigabytes of memory to run; * It needs minutes to bootstrap (which it will every time, because you don’t want a multi-gigabyte-sized daemon running around); * It breaks every second day. If you are building version X of $something, you better go and get the exact version of Bazel that the developers of $something were using when tagging X; * And when they fail to build there’s no chance you will be able to figure it out without spending days on it. Don’t use Bazel unless writing code that only you yourself can maintain is your goal.

majidfn 7y ago

We had a difficult experience with Bazel as well using it for a Go project. As mentioned it brings its own reimplementation of any compiler or package manager. So if there is a new feature from the language, you have to wait till the Bazel rules for that language gets updated, only then you can start using it. For a Go project which the whole build command is a single line of `go build`, it takes lots of config files and configuration, and tweaking till you get the exact same result. Only till there is an update and the whole build crashes and you have to figure it out why. To me m, Bazel is a great tool for Google or a project at the scale of Google projects. It is beneficial if you can benefit from distributed builds and caching layers. Only for a project big enough that those could make a difference. But for all other projects, Bazel, felt like brining an 18-wheeler to go to grocery shopping.