# Why Bazel?

DevFeed: [Why Bazel?](<https://devfeed.tech/articles/why-bazel-21770.md>)

Original publisher: [Read original article](<https://enoent.fr/posts/creating-a-blog-with-bazel/03-why-bazel/>)

Author: Marc Plano-Lesay

Published: 2019-11-02T07:00:00Z

Content type: tutorial

Language: en

Sources: [Marc Plano-Lesay](<https://devfeed.tech/sources/marc-plano-lesay.md>)

Topics: [bazel](<https://devfeed.tech/topics/bazel.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>)

Tags: [bazel](<https://devfeed.tech/tags/bazel.md>), [build-system](<https://devfeed.tech/tags/build-system.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [caching](<https://devfeed.tech/tags/caching.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [reproducibility](<https://devfeed.tech/tags/reproducibility.md>), [toolchain](<https://devfeed.tech/tags/toolchain.md>)

## AI overview

This tutorial explains what Bazel is, how its hermetic and reproducible build model works, and why the author chose it. It demonstrates C++ library and binary targets, dependency-driven builds, caching, toolchains, and extensibility through Starlark rules.

## Source excerpt

In this post, we'll cover what Bazel is, how to use it, and why I chose to use it. What is Bazel? Bazel is a build-system released by Google in 2015. It actually is derived from the internal build-system Google uses internally for most of its own code-base, called Blaze. Building at scale Bazel has a huge focus on hermetic builds, and reproducibility. Every build step is, from a really broad perspective, defined as a list of inputs, tools, and outputs. This allows for efficient and robust caching (if no inputs nor tools changed, then this target doesn't need to be rebuilt, and this cascades through the whole build graph). Let's see a sample definition of a C++ library, as well as a C++ binary depending on it: BUILD cc_library( name = "my_feature" srcs = [ "feature_impl.cpp", "utils.cpp", ], hdrs = [ "feature.hpp", "utils.hpp", ], ) cc_binary( name = "my_app", srcs = ["main.cpp"], deps = [ ":my_feature", ], ) cc_library and cc_binary are both depending an implicit dependency on a C++ toolchain (I won't enter into any language-specific features in this post, but if you don't tell Bazel to use a specific C++ toolchain, it will try to use your system compiler - which is convenient, but loses a bit of hermeticity and reproducibility). Everything else is pretty obvious here: we defined two different build targets, one of them being a library called my_feature, and the other one a binary called my_app, depending on my_feature. If we build my_app, Bazel will automatically build my_feature first as you would expect, and then proceed to build my_app. If you change the main.cpp and re-build my_app, it will skip the compilation of my_feature entirely, as nothing changed. Bazel's cache handling is really reliable. During the past few months, I've done a lot of diverse things (writing my own rules, compiling a bunch of different languages, depending on third-party libraries and rules...), and never had a single time to run bazel clean. Now I didn't use a lot of other build systems