6 ms·

What's New in Bazel 6.0

69 points by siggi 4y ago

simplotek 4y ago
From the announcement: > One of Bazel's most powerful features is its ability to use remote caching and remote execution. What's the value proposition of Bazel when build systems like cmake support this out of the box with third-party tools like distcc and ccache?
- en4bz 4y ago
  None, bazel's caching implementation is broken because they don't even know or specify what constituents a build hash/key. See this issue from 2018 that's still open [1]. [1] https://github.com/bazelbuild/bazel/issues/4558 https://github.com/bazelbuild/bazel/issues/4558
  - lopkeny12ko 4y ago
    Probably because building targets with tools outside of the workspace is an antipattern, as it violates hermiticity principles. In fact, Bazel generally makes it quite hard to do this, so anyone who ends up in this scenario must have jumped through many hoops to get there. I agree that the linked issue is legitimate, but I'd argue that this isn't a problem Bazel itself needs to solve--you should fix your build to be fully hermetic.
    - en4bz 4y ago
      Non-Hermetic is the default for C/C++. And if you plan on using system provided libraries to support multi OSes then you can't use it.
      - lopkeny12ko 4y ago
        That is precisely the point--using system-provided libraries in your Bazel project is an antipattern that should be avoided.
        en4bz 4y ago
        It's literally the default. How can the default be an anti-pattern. I doubt you're using C/C++ because you don't seem to understand the issue.
        lopkeny12ko 4y ago
        Learn to take others seriously without asking for credentials. Whether or not I use C/C++ is irrelevant. Bazel is flexible, and you can use it however you want, correctly or incorrectly. The principles I've mentioned above are language-agnostic, and are recommended best practice regardless of whatever programming language you are building. https://bazel.build/basics/hermeticity https://bazel.build/basics/hermeticity > When given the same input source code and product configuration, a hermetic build system always returns the same output by isolating the build from changes to the host system. > In order to isolate the build, hermetic builds are insensitive to libraries and other software installed on the local or remote host machine. They depend on specific versions of build tools, such as compilers, and dependencies, such as libraries. This makes the build process self-contained as it doesn't rely on services external to the build environment. My overarching point is, you should fix your build rather than point blame to the tool's authors because you're using it in an unsupported way.
        joshuamorton 4y ago
        Many people believe that the "traditional" way of building C/C++ applications is an antipattern. Such a belief is, in fact, a core reason to adopt bazel. If you don't believe that, then bazel may not be for you. It is intentionally opinionated in a way that you aren't.
        en4bz 4y ago
        I'm assuming you're referring to the golang model of statically linking everything. That's not really doable when many popular libraries are (L)GPL'd like glibc and libstdc++. It also doesn't work if you want to provide a shared library and need to be compatible with every possible system. That's not my opinion it's just a deficiency of bazel.
    - emidln 4y ago
      Not that I'd recommend it, but if you symlink your system library into the bazel build area, as long as your sandboxing setup don't hose you (or you just turn it off), bazel will track system tools/library in the same way as everything else. Bazel's rules_cc even has a system_library.bzl you can import a `system_library` from that automates this for you. https://github.com/bazelbuild/rules_cc/blob/main/cc/system_library.bzl https://github.com/bazelbuild/rules_cc/blob/main/cc/system_l... I'd still recommend building everything from scratch (and understanding the relationships and graph of your dependencies), but if your build isn't that complicated and you want to role the dice on UB, this isn't that hard. As an aside, the most galling part of bazel's cache key calculations has to be that it's up to the individual rules to implement this how they see fit. The rules native to bazel written in java vary wildly compared to starlark-written rules. On thing you (or someone in your org) end up becoming pretty comfortable with while using bazel in anger is RTFC.
    - simplotek 4y ago
      > Probably because building targets with tools outside of the workspace is an antipattern, as it violates hermiticity principles. Nonsense. Nothing forces you to use tools outside of your workspace. CMake just requires you to set CMAKE_<LANG>_COMPILER_LAUNCHER[1] to point to a compiler launchers, which can be anywhere where you see fit, including a random path within your workspace. People try too hard to come up with excuses for design flaws. [1] https://cmake.org/cmake/help/latest/prop_tgt/LANG_COMPILER_LAUNCHER.html https://cmake.org/cmake/help/latest/prop_tgt/LANG_COMPILER_L...
- pests 4y ago
  It's not out of the box if you need third party tools is it?
- gravypod 4y ago
  (Opinions are my own) I think that this is a problem with branding which unfortunately Bazel is using. I think remote caching and remote exec are not the best features that Bazel has to offer. First to answer your question: distcc and ccache are great but they offer a limited amount of flexibility in what can be distributed. Bazel's approach is generalized and operates on this basic set of steps: 1. Configure a "target" (define inputs and outputs) 2. Load the deps for the target into a sandbox. 3. Run a command in that sandbox. 4. Copy the outputs out of the sandbox. With this approach you can execute anything as it's just running a shell program with some args. For example: lets say you are building a game and you have a process where you take raw models from your designers and compress them into an efficient storage format. This can be a `genrule` in your BUILD file and instantly get rerun whenever anyone submits a new change to the models. Now that it's been run in CI all of your devs will not need to rebuild this on their machines. That's the goal. Basically: it is more generic than caching a specific language's data. You can cache everything. My favorite part of Bazel is the layer of abstraction. Rather than thinking of build steps, what args to gcc are getting passed, etc you are thinking about libraries, binaries, tests, and other artifacts. Also, this abstraction of inputs and outputs makes it so it's easy to eventually build higher level abstractions. For example, this should be possible at some point: cc_binary( name = "foobar", srcs = [...], hdrs = ["foobar.h"] ) # Automatically generates jni binding # for a C++ library just by reading the # header file and binding all types. java_cc_binding( name = "foobar_java", deps = [":foobar"], namespace = "::foobar", generate_class = "foobar.FoobarBinding", ) This doesn't yet exist but it could and it would be pretty amazing. Or, another example, imagine AWS publishing a `lambda_binary` rule which you could pass any `*_binary` and run your binary into which automatically generates a packaged and ready-to-go artifact which you could upload to AWS. I think the framework to allow others to build on this abstraction and make things take less effort overall is the huge value add.
nisa 4y ago
I'm still not sure if I should go the bazel route... recently found a long good explanation why anki switched away from bazel: https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4b202c08bd740c7bb37763 https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4... I'd love to have cachable builds but I wonder how much effort it takes to maintain such a setup - especially in a small team very far away from silicon valley or google were nobody saw bazel before. Would be a perfect fit for my former company but even there I couldn't convince my colleagues - they build a monster using maven which would be more elegant in bazel but maven integration worked different than the maven algorithm at least 2 years ago...so my PoC turned into reading source code of dependency resolution algorithm in the used scala tool coursier... in the end I had to give up after patching maven issues in several projects we build upon - something nobody is willing to do I guess - to be fair I tried to incorporate Alfresco ECM which is quite an enterprise Java monster on it's own. Also I couldn't find a good approach to use multiple git repositories almost all tutorials use a monorepo.
- actionfromafar 4y ago
  I've been meaning to try out XMake [0]. It has caching and distributed build and seems much easier to understand than Bazel. 0: https://xmake.io/#/getting_started https://xmake.io/#/getting_started
- ranting-moth 4y ago
  In my experience you need a Bazel expert on the team. When everything works it's amazing. When it doesn't or additional work is required the hope your local expert is online and willing to sort it out.
  - maccard 4y ago
    This is true for any language ecosystem or build tool, whether it's bazel, maven, unrealbuildtool, Jenkins, cmake, gradle etc.
    - oblio 4y ago
      The thing is, if you hire 20 Java devs, at least one of them will already be an advanced Maven user. Same for Python and poetry/pipenv, Javascript/npm, etc. Bazel is kind of to the side everywhere.
tinglymintyfrsh 4y ago
0. Does it do creating static libraries yet? 1. Does it do linking to a mix of static and dynamic libraries yet? 2. Anyone try buck2, sort of bzl-like?
- lalaland1125 4y ago
  0 and 1 have been supported for a while. See the "linkstatic" feature.
  - en4bz 4y ago
    No, they are extremely broken. You can only choose: - Link everything static. - Link everything dynamic. - Link user libs as static and system libs as dynamic. There is no easy way to link a single user lib static/dynamic without resorting to hacks/workarounds like re-importing the shared library or defining weird intermediate targets. It's completely broken.
    - lalaland1125 4y ago
      You can use the "linkstatic" feature on the cc_library level. Then that library will be linked statically while other cc_library's will be dynamically linked.
      - en4bz 4y ago
        The logic is backwards though. I may have multiple consumers of a library some of which may want static some of which may want dynamic. You need to create/import new targets to do this even though the original target creates both static and dynamic libs by default.
        emidln 4y ago
        This is just false. Bazel creates both static and dynamic libs by default for every cc_library. The default is to link static, but you can control this on a per-binary basis. You don't need parallel trees of targets or even to write custom rules to access the non-default output groups that contain the shared library. This all just works out of the box.
lalaland1125 4y ago
The main change here is that Bazel now has a package repository that people can pull/push external dependencies to: https://registry.bazel.build/ https://registry.bazel.build/ This is a huge change as external dependencies used to be one of the big pain points with the Bazel pipeline.
- bradhe 4y ago
  Awesome but kind of a bummer to see yet another dependency management tool, especially in the C++ ecosystem. Didn’t read that much of the article, but wonder if there’s interop plans with VCPkg or Conan?
no_wizard 4y ago
NX is a very bazel like for frontend focused repositories. I think what I struggle with the most is the opinions of the rules / plugins. Either I use it as a core task runner (easy, but lots of config the team has to maintain setting up script entries in packages etc) or I have to write custom plugins for anyting not on the "happy path". I think thats my general frustration with these tools, they aren't terribly well built for SDK type consumption, they don't expose a core set of APIs directly, instead relying on a plugin system that can sometimes be very opaque
Leherenn 4y ago
We use Bazel at work for C++, and while defining targets and dependency is easy, I've really struggled with some stuff I would consider basic, like conditionally changing build flags, especially to external dependencies. Basically, I wanted to conditionally use sanitizers for a specific target and propagate the sanitizers compiler/linker flags to the whole dependency tree. For code you own, from what I could find, you need to duplicate each target and each dependency (and their own dependencies) for each possible sanitizer and then select the right one. And for external dependencies, you need to use "Aspects", if I understood correctly, to modify the build dependency graph and inject your flags. There's a question on stackoverflow about it, but the answer is very high level (presumably by a Bazel dev), and unfortunately I didn't have time to dig it further and just abandoned. I also had a lot of issues on an ARM Mac, including the linker issue that is apparently fixed (hooray) and recurrent crashes. Given we do not use any of best features of Bazel (remote/distributed compilation, multiple languages, and caching (because we basically spawn a new docker container for each build)), I think CMake would have made more sense.
- johntb86 4y ago
  I think you should be using user-defined transitions (https://bazel.build/extending/config#user-defined-transitions https://bazel.build/extending/config#user-defined-transition... ) to use sanitizers. They essentially duplicate the build graph, and you can set build flags on the transition so that all dependencies will be built with those flags.

69 points by siggi 4y ago

From the announcement: > One of Bazel's most powerful features is its ability to use remote caching and remote execution. What's the value proposition of Bazel when build systems like cmake support this out of the box with third-party tools like distcc and ccache?

en4bz 4y ago
None, bazel's caching implementation is broken because they don't even know or specify what constituents a build hash/key. See this issue from 2018 that's still open [1]. [1] https://github.com/bazelbuild/bazel/issues/4558 https://github.com/bazelbuild/bazel/issues/4558
- lopkeny12ko 4y ago
  Probably because building targets with tools outside of the workspace is an antipattern, as it violates hermiticity principles. In fact, Bazel generally makes it quite hard to do this, so anyone who ends up in this scenario must have jumped through many hoops to get there. I agree that the linked issue is legitimate, but I'd argue that this isn't a problem Bazel itself needs to solve--you should fix your build to be fully hermetic.
  - en4bz 4y ago
    Non-Hermetic is the default for C/C++. And if you plan on using system provided libraries to support multi OSes then you can't use it.
    - lopkeny12ko 4y ago
      That is precisely the point--using system-provided libraries in your Bazel project is an antipattern that should be avoided.
      - en4bz 4y ago
        It's literally the default. How can the default be an anti-pattern. I doubt you're using C/C++ because you don't seem to understand the issue.
        lopkeny12ko 4y ago
        Learn to take others seriously without asking for credentials. Whether or not I use C/C++ is irrelevant. Bazel is flexible, and you can use it however you want, correctly or incorrectly. The principles I've mentioned above are language-agnostic, and are recommended best practice regardless of whatever programming language you are building. https://bazel.build/basics/hermeticity https://bazel.build/basics/hermeticity > When given the same input source code and product configuration, a hermetic build system always returns the same output by isolating the build from changes to the host system. > In order to isolate the build, hermetic builds are insensitive to libraries and other software installed on the local or remote host machine. They depend on specific versions of build tools, such as compilers, and dependencies, such as libraries. This makes the build process self-contained as it doesn't rely on services external to the build environment. My overarching point is, you should fix your build rather than point blame to the tool's authors because you're using it in an unsupported way.
        joshuamorton 4y ago
        Many people believe that the "traditional" way of building C/C++ applications is an antipattern. Such a belief is, in fact, a core reason to adopt bazel. If you don't believe that, then bazel may not be for you. It is intentionally opinionated in a way that you aren't.
        en4bz 4y ago
        I'm assuming you're referring to the golang model of statically linking everything. That's not really doable when many popular libraries are (L)GPL'd like glibc and libstdc++. It also doesn't work if you want to provide a shared library and need to be compatible with every possible system. That's not my opinion it's just a deficiency of bazel.
  - emidln 4y ago
    Not that I'd recommend it, but if you symlink your system library into the bazel build area, as long as your sandboxing setup don't hose you (or you just turn it off), bazel will track system tools/library in the same way as everything else. Bazel's rules_cc even has a system_library.bzl you can import a `system_library` from that automates this for you. https://github.com/bazelbuild/rules_cc/blob/main/cc/system_library.bzl https://github.com/bazelbuild/rules_cc/blob/main/cc/system_l... I'd still recommend building everything from scratch (and understanding the relationships and graph of your dependencies), but if your build isn't that complicated and you want to role the dice on UB, this isn't that hard. As an aside, the most galling part of bazel's cache key calculations has to be that it's up to the individual rules to implement this how they see fit. The rules native to bazel written in java vary wildly compared to starlark-written rules. On thing you (or someone in your org) end up becoming pretty comfortable with while using bazel in anger is RTFC.
  - simplotek 4y ago
    > Probably because building targets with tools outside of the workspace is an antipattern, as it violates hermiticity principles. Nonsense. Nothing forces you to use tools outside of your workspace. CMake just requires you to set CMAKE_<LANG>_COMPILER_LAUNCHER[1] to point to a compiler launchers, which can be anywhere where you see fit, including a random path within your workspace. People try too hard to come up with excuses for design flaws. [1] https://cmake.org/cmake/help/latest/prop_tgt/LANG_COMPILER_LAUNCHER.html https://cmake.org/cmake/help/latest/prop_tgt/LANG_COMPILER_L...
pests 4y ago
It's not out of the box if you need third party tools is it?
gravypod 4y ago
(Opinions are my own) I think that this is a problem with branding which unfortunately Bazel is using. I think remote caching and remote exec are not the best features that Bazel has to offer. First to answer your question: distcc and ccache are great but they offer a limited amount of flexibility in what can be distributed. Bazel's approach is generalized and operates on this basic set of steps: 1. Configure a "target" (define inputs and outputs) 2. Load the deps for the target into a sandbox. 3. Run a command in that sandbox. 4. Copy the outputs out of the sandbox. With this approach you can execute anything as it's just running a shell program with some args. For example: lets say you are building a game and you have a process where you take raw models from your designers and compress them into an efficient storage format. This can be a `genrule` in your BUILD file and instantly get rerun whenever anyone submits a new change to the models. Now that it's been run in CI all of your devs will not need to rebuild this on their machines. That's the goal. Basically: it is more generic than caching a specific language's data. You can cache everything. My favorite part of Bazel is the layer of abstraction. Rather than thinking of build steps, what args to gcc are getting passed, etc you are thinking about libraries, binaries, tests, and other artifacts. Also, this abstraction of inputs and outputs makes it so it's easy to eventually build higher level abstractions. For example, this should be possible at some point: cc_binary( name = "foobar", srcs = [...], hdrs = ["foobar.h"] ) # Automatically generates jni binding # for a C++ library just by reading the # header file and binding all types. java_cc_binding( name = "foobar_java", deps = [":foobar"], namespace = "::foobar", generate_class = "foobar.FoobarBinding", ) This doesn't yet exist but it could and it would be pretty amazing. Or, another example, imagine AWS publishing a `lambda_binary` rule which you could pass any `*_binary` and run your binary into which automatically generates a packaged and ready-to-go artifact which you could upload to AWS. I think the framework to allow others to build on this abstraction and make things take less effort overall is the huge value add.

nisa 4y ago

I'm still not sure if I should go the bazel route... recently found a long good explanation why anki switched away from bazel: https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4b202c08bd740c7bb37763 https://github.com/ankitects/anki/commit/5e0a761b875fff4c9e4... I'd love to have cachable builds but I wonder how much effort it takes to maintain such a setup - especially in a small team very far away from silicon valley or google were nobody saw bazel before. Would be a perfect fit for my former company but even there I couldn't convince my colleagues - they build a monster using maven which would be more elegant in bazel but maven integration worked different than the maven algorithm at least 2 years ago...so my PoC turned into reading source code of dependency resolution algorithm in the used scala tool coursier... in the end I had to give up after patching maven issues in several projects we build upon - something nobody is willing to do I guess - to be fair I tried to incorporate Alfresco ECM which is quite an enterprise Java monster on it's own. Also I couldn't find a good approach to use multiple git repositories almost all tutorials use a monorepo.

actionfromafar 4y ago
I've been meaning to try out XMake [0]. It has caching and distributed build and seems much easier to understand than Bazel. 0: https://xmake.io/#/getting_started https://xmake.io/#/getting_started
ranting-moth 4y ago
In my experience you need a Bazel expert on the team. When everything works it's amazing. When it doesn't or additional work is required the hope your local expert is online and willing to sort it out.
- maccard 4y ago
  This is true for any language ecosystem or build tool, whether it's bazel, maven, unrealbuildtool, Jenkins, cmake, gradle etc.
  - oblio 4y ago
    The thing is, if you hire 20 Java devs, at least one of them will already be an advanced Maven user. Same for Python and poetry/pipenv, Javascript/npm, etc. Bazel is kind of to the side everywhere.

tinglymintyfrsh 4y ago

0. Does it do creating static libraries yet? 1. Does it do linking to a mix of static and dynamic libraries yet? 2. Anyone try buck2, sort of bzl-like?

lalaland1125 4y ago
0 and 1 have been supported for a while. See the "linkstatic" feature.
- en4bz 4y ago
  No, they are extremely broken. You can only choose: - Link everything static. - Link everything dynamic. - Link user libs as static and system libs as dynamic. There is no easy way to link a single user lib static/dynamic without resorting to hacks/workarounds like re-importing the shared library or defining weird intermediate targets. It's completely broken.
  - lalaland1125 4y ago
    You can use the "linkstatic" feature on the cc_library level. Then that library will be linked statically while other cc_library's will be dynamically linked.
    - en4bz 4y ago
      The logic is backwards though. I may have multiple consumers of a library some of which may want static some of which may want dynamic. You need to create/import new targets to do this even though the original target creates both static and dynamic libs by default.
      - emidln 4y ago
        This is just false. Bazel creates both static and dynamic libs by default for every cc_library. The default is to link static, but you can control this on a per-binary basis. You don't need parallel trees of targets or even to write custom rules to access the non-default output groups that contain the shared library. This all just works out of the box.

lalaland1125 4y ago

The main change here is that Bazel now has a package repository that people can pull/push external dependencies to: https://registry.bazel.build/ https://registry.bazel.build/ This is a huge change as external dependencies used to be one of the big pain points with the Bazel pipeline.

bradhe 4y ago
Awesome but kind of a bummer to see yet another dependency management tool, especially in the C++ ecosystem. Didn’t read that much of the article, but wonder if there’s interop plans with VCPkg or Conan?

no_wizard 4y ago

NX is a very bazel like for frontend focused repositories. I think what I struggle with the most is the opinions of the rules / plugins. Either I use it as a core task runner (easy, but lots of config the team has to maintain setting up script entries in packages etc) or I have to write custom plugins for anyting not on the "happy path". I think thats my general frustration with these tools, they aren't terribly well built for SDK type consumption, they don't expose a core set of APIs directly, instead relying on a plugin system that can sometimes be very opaque

Leherenn 4y ago

We use Bazel at work for C++, and while defining targets and dependency is easy, I've really struggled with some stuff I would consider basic, like conditionally changing build flags, especially to external dependencies. Basically, I wanted to conditionally use sanitizers for a specific target and propagate the sanitizers compiler/linker flags to the whole dependency tree. For code you own, from what I could find, you need to duplicate each target and each dependency (and their own dependencies) for each possible sanitizer and then select the right one. And for external dependencies, you need to use "Aspects", if I understood correctly, to modify the build dependency graph and inject your flags. There's a question on stackoverflow about it, but the answer is very high level (presumably by a Bazel dev), and unfortunately I didn't have time to dig it further and just abandoned. I also had a lot of issues on an ARM Mac, including the linker issue that is apparently fixed (hooray) and recurrent crashes. Given we do not use any of best features of Bazel (remote/distributed compilation, multiple languages, and caching (because we basically spawn a new docker container for each build)), I think CMake would have made more sense.

johntb86 4y ago
I think you should be using user-defined transitions (https://bazel.build/extending/config#user-defined-transitions https://bazel.build/extending/config#user-defined-transition... ) to use sanitizers. They essentially duplicate the build graph, and you can set build flags on the transition so that all dependencies will be built with those flags.