9 ms·

I've been using Bazel full time for over two years now to build Java/Go/Containers/gRPC and everything in between, and I must really say that it's one of the be

• klodolph 7y ago
  It really is that good. I’ve been using it only over a year, but I’ve done a lot of build system work with different tools and Bazel stands out. Most other tools seem to be competitors to Make (SCons, Jam, tup), souped-up scripting systems (Ant, Gradle), or configuration toolboxes (CMake). The ones that really stand out are the tools that tackle the problem of expressing builds in a way that’s both expressive and declarative. In my mind, these fall into two families: Gyp and Bazel (which includes Buck, Pants, Please.build, and that new custom thing Chrome uses). (And then there’s Ninja, which I appreciate for taking a good / useful subset of Make’s features and doing it really well.)
  • dickeytk 7y ago
    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...
    • 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.
  • ufo 7y ago
    In the topic of classifying build systems, there was a really interesting paper about that published at ICFP last year https://blogs.ncl.ac.uk/andreymokhov/build-systems-a-la-carte/ https://blogs.ncl.ac.uk/andreymokhov/build-systems-a-la-cart... They classify it based on how the build system detects what needs to be rebuilt and how the build system chooses the order things should be built in
    • kylecordes 7y ago
      I'd like to get a good grasp of the differences between Bazel and Buck. I've used the Bazel but not Buck - most descriptions of Buck describe it as being pretty similar to Bazel. (Also, that's a very interesting paper, will read in depth.)
      • gen220 7y ago
        From a historical perspective: Bazel is the open sourced version of Blaze, google's internal build system. Buck is Facebook's open source version of their own implementation of a Blaze-like system. Pants was built as an open source implementation of Buck, before Buck was open sourced. From a bird's eye view, knowing this history of their creators, I would guess that Bazel is more complicated internally, its API has a wider surface area, and ships with many optimizations included for the use case of building extremely large artifacts with many, many dependencies. Someone who's more familiar with both, feel free to add details or correct my over generalizations! I've used Pants professionally and tried setting up Bazel for personal projects, but found it was too complicated for my needs.
        • burakcosk 7y ago
          one of the biggest differences between buck and bazel is, when you want to write new build rules(to support your specific use case or to support an unsupported language etc): - in buck you should update the buck code itself(you should touch so many places in JAVA) - whereas in bazel, you can extend bazel with starlark(subset of python) language and do all sorts of things like supporting whole new language. without touching even a tiny bit into bazel core. This was the main reason my company is switching to bazel from buck