4 ms·

I use bazel at work heavily in a very large project. I’ve always worked with scripting languages so I’m much less familiar with build systems. I’m not sure I g

I use bazel at work heavily in a very large project. I’ve always worked with scripting languages so I’m much less familiar with build systems. I’m not sure I get what makes bazel so good. It seems pretty simple to me. You have a bunch of directories with BUIILD files that are each sort of like Makefiles. Am I missing something? It kind of just seems like a hodgepodge of scripts. I don’t dislike it, but I’m also not seeing anything amazing.

afthonos 7y ago
My experience is that I realized the value when I switched to a project that didn’t use it. Especially when I wanted to use other Google technologies like protos, or when I wanted to incrementally rebuild dependencies. Disclosure: I work at Google, with Blaze, but not on it, or on Bazel. All opinions mine.
klodolph 7y ago
I’ll take a stab at it, since I’ve done some migrations to Bazel (and also away from Bazel). The comparison to Make and makefiles is good because Make, unlike some other build systems, is mostly declarative. Most of your makefile is going to declare what the inputs and outputs are. If you use Make long enough, there are some obvious improvements you want. Multiple outputs, rebuild when options change, and easier cross-compiling are the top ones. Various build systems attempt to add these features. In my mind, Ninja is the only build system that added these features well, and it worked because Ninja removed all the other features to focus on just the build process (as opposed to specification / configuration). If you think about these problems with Make, you realize that it kind of boils down to one big thing: you want your build system to always rebuild when necessary, and you want it to almost never rebuild when unnecessary. (Plus the bit about cross-compiling.) Other build systems rely on the developer writing the build scripts to just “get it right”. Bazel is different because it sandboxes the rules to enforce hermeticity. In Make, I can include "pear.h" which includes "orange.h", but let’s suppose that "orange.h" is actually a generated source file… now, try writing this out in a Makefile (if you’re a masochist, say you’re cross-compiling). Yes, "orange.h" should be declared as an input to anything that includes "pear.h", but in practice, developers are going to screw it up. At that point you can end up with a build that uses two different versions of "orange.h". Bazel sandboxes the commands so that any rule not declared to depend on "orange.h" will not be able to open "orange.h" at all. The process won’t see the file at all. This opens the door for all sorts of optimizations and query features that are simply unreliable if you have to trust that human developers are writing the rules correctly. These optimizations, for large projects, result in radical build time improvements. For most build systems, a shared build cache would come with a risk of bad cache entries, but with Bazel, the risk is substantially lower. It’s also easier to get reproducible builds, which make it substantially easier to do certain types of auditing.
- dickeytk 7y ago
  Great explanation, thank you!
- boris 7y ago
  Bazel (and Bazel-derivatives/alikes) is not unique in fixing all of these problems. For example, there is build2, which is arguably a lighter-weight and closer to make (in spirit, not in syntax) solution (no Java dependency, etc). Here is an intro, if anyone is interested: https://build2.org/build2/doc/build2-build-system-manual.xhtml#intro https://build2.org/build2/doc/build2-build-system-manual.xht...
  - skybrian 7y ago
    I did a quick skim and it doesn't seem to sandbox the build steps like Bazel? Maybe I missed something.
    - boris 7y ago
      It doesn't do Bazel's style sandboxing where your entire compiler toolchain is part of your build system. It does what we call high-fidelity builds: it tracks changes not only to inputs but also to compile options, compiler itself (checksum), environment, etc., and if any of these auxiliary dependencies change, it triggers a rebuild. There are advantages and disadvantages to both approaches with build2's being lighter weight.
      - rienbdj 7y ago
        I don't see how build2 can be in the same spirit as Bazel when it misses the main advantage of Bazel
        boris 7y ago
        I never said build2 is "in the same spirit" as Bazel (whatever that means). I said it fixes the same problems as OP listed.
SolarNet 7y ago
You get a lot of features for very cheap compared to other systems. That's the best way I can describe it. Bazel is basically cross platform out of the box if one is careful with it: that includes a consistent build organization across platforms, cross builds if configured, and so on. It can build a library declaration for mobile and desktop and embedded and web in a single workspace; try that with CMAKE. Bazel has a universal package system (e.g. download an archive or git repo) that allows for custom ecosystems (yes some of which are not great yet) to exist regardless of what is normal that ecosystem. This is especially notable for C++ where using CMAKE as a package system is a nightmare, with bazel I can just download any C++ repo off the internet and ignore it's CMAKE file for my own BUILD file. Also notably it's the first build system for C++ that hasn't required me to build or configure boost myself, someone can run bazel build against a repo of mine with boost in it without even knowing what boost is and it just builds. Which brings me to hermeticy and reproducibility. If one is careful running bazel it always uses the same code for a platform (I've never had or seen weird "on my machine" issues with it which is impressive; reverting/stashing changes has always gotten people a working build again). All of the sources are version pinned, and so on. Getting to hermetic takes some work, but it's possible which is nice. A side effect of all this is my instructions for a bazel project are usually: install bazel, run build; and it just works! Yes parts of the ecosystem suck and break this, but that's a work in progress. There are other features, like the query system, the test runner, the macro system, the local override idiom, the parallel build. The point is it really is a build tool for whatever needs to be built, however it needs to be built, and not just a scripting language useful for building things.

afthonos 7y ago

My experience is that I realized the value when I switched to a project that didn’t use it. Especially when I wanted to use other Google technologies like protos, or when I wanted to incrementally rebuild dependencies. Disclosure: I work at Google, with Blaze, but not on it, or on Bazel. All opinions mine.

klodolph 7y ago

I’ll take a stab at it, since I’ve done some migrations to Bazel (and also away from Bazel). The comparison to Make and makefiles is good because Make, unlike some other build systems, is mostly declarative. Most of your makefile is going to declare what the inputs and outputs are. If you use Make long enough, there are some obvious improvements you want. Multiple outputs, rebuild when options change, and easier cross-compiling are the top ones. Various build systems attempt to add these features. In my mind, Ninja is the only build system that added these features well, and it worked because Ninja removed all the other features to focus on just the build process (as opposed to specification / configuration). If you think about these problems with Make, you realize that it kind of boils down to one big thing: you want your build system to always rebuild when necessary, and you want it to almost never rebuild when unnecessary. (Plus the bit about cross-compiling.) Other build systems rely on the developer writing the build scripts to just “get it right”. Bazel is different because it sandboxes the rules to enforce hermeticity. In Make, I can include "pear.h" which includes "orange.h", but let’s suppose that "orange.h" is actually a generated source file… now, try writing this out in a Makefile (if you’re a masochist, say you’re cross-compiling). Yes, "orange.h" should be declared as an input to anything that includes "pear.h", but in practice, developers are going to screw it up. At that point you can end up with a build that uses two different versions of "orange.h". Bazel sandboxes the commands so that any rule not declared to depend on "orange.h" will not be able to open "orange.h" at all. The process won’t see the file at all. This opens the door for all sorts of optimizations and query features that are simply unreliable if you have to trust that human developers are writing the rules correctly. These optimizations, for large projects, result in radical build time improvements. For most build systems, a shared build cache would come with a risk of bad cache entries, but with Bazel, the risk is substantially lower. It’s also easier to get reproducible builds, which make it substantially easier to do certain types of auditing.

dickeytk 7y ago
Great explanation, thank you!
boris 7y ago
Bazel (and Bazel-derivatives/alikes) is not unique in fixing all of these problems. For example, there is build2, which is arguably a lighter-weight and closer to make (in spirit, not in syntax) solution (no Java dependency, etc). Here is an intro, if anyone is interested: https://build2.org/build2/doc/build2-build-system-manual.xhtml#intro https://build2.org/build2/doc/build2-build-system-manual.xht...
- skybrian 7y ago
  I did a quick skim and it doesn't seem to sandbox the build steps like Bazel? Maybe I missed something.
  - boris 7y ago
    It doesn't do Bazel's style sandboxing where your entire compiler toolchain is part of your build system. It does what we call high-fidelity builds: it tracks changes not only to inputs but also to compile options, compiler itself (checksum), environment, etc., and if any of these auxiliary dependencies change, it triggers a rebuild. There are advantages and disadvantages to both approaches with build2's being lighter weight.
    - rienbdj 7y ago
      I don't see how build2 can be in the same spirit as Bazel when it misses the main advantage of Bazel
      - boris 7y ago
        I never said build2 is "in the same spirit" as Bazel (whatever that means). I said it fixes the same problems as OP listed.

SolarNet 7y ago

You get a lot of features for very cheap compared to other systems. That's the best way I can describe it. Bazel is basically cross platform out of the box if one is careful with it: that includes a consistent build organization across platforms, cross builds if configured, and so on. It can build a library declaration for mobile and desktop and embedded and web in a single workspace; try that with CMAKE. Bazel has a universal package system (e.g. download an archive or git repo) that allows for custom ecosystems (yes some of which are not great yet) to exist regardless of what is normal that ecosystem. This is especially notable for C++ where using CMAKE as a package system is a nightmare, with bazel I can just download any C++ repo off the internet and ignore it's CMAKE file for my own BUILD file. Also notably it's the first build system for C++ that hasn't required me to build or configure boost myself, someone can run bazel build against a repo of mine with boost in it without even knowing what boost is and it just builds. Which brings me to hermeticy and reproducibility. If one is careful running bazel it always uses the same code for a platform (I've never had or seen weird "on my machine" issues with it which is impressive; reverting/stashing changes has always gotten people a working build again). All of the sources are version pinned, and so on. Getting to hermetic takes some work, but it's possible which is nice. A side effect of all this is my instructions for a bazel project are usually: install bazel, run build; and it just works! Yes parts of the ecosystem suck and break this, but that's a work in progress. There are other features, like the query system, the test runner, the macro system, the local override idiom, the parallel build. The point is it really is a build tool for whatever needs to be built, however it needs to be built, and not just a scripting language useful for building things.