6 ms·

Lol, Googler here, I can't deny that I have he urge to force Bazel into the world. It's just, when I joined Google I found a build system I didn't hate. This

Lol, Googler here, I can't deny that I have he urge to force Bazel into the world. It's just, when I joined Google I found a build system I didn't hate. This was the first time. I don't actually love Bazel (Blaze internally), but I love that I don't hate it. Every time I have to learn a new build system in open source work I groan. Why are there so many systems for essentially the same thing?

carlmr 4y ago
Question for an insider. Bazel code coverage seems to be one of the roughest edges. At least when running C++ tests. Only lcov is supported, and due to the sandboxing it's impossible to get other tools working since they always spit out extra instrumentation data that's neither cached nor available on the next sandbox. Does blaze support code coverage properly? Does Google just not care about code coverage? Am I just missing some obvious thing in the documentation?
- bjackman 4y ago
  Hmm sorry I'm quite ignorant about that. Code coverage is pretty well supported in the internal ecosystem but I would not be surprised to hear this is because we designed Bazel around the system Google was already using for coverage.
  - simplotek 4y ago
    > Code coverage is pretty well supported in the internal ecosystem (...) What you're actually saying is that internally Google managed to get a single and very specific use case to work and forced all projects to either adopt it or have no code coverage.
- Game_Ender 4y ago
  You can get coverage working for almost anything by having each test convert its coverage data to LCOV before stopping, in the same sandbox as the test. I forget the exact details but I think you can do this with a custom run_under test wrapper used during coverage. The wrapper runs your test, with whatever custom coverage system you have, then afterwards it converts to LCOV. Sometimes this might require updates to language specific rules because the test runner itself needs to be configured. The bottom line is that Bazel upstream does not put a lot of attention into this, so it’s under developed outside of Google, because Google internal does not use the OSS rules.
  - carlmr 4y ago
    >I forget the exact details but I think you can do this with a custom run_under test wrapper used during coverage. The wrapper runs your test, with whatever custom coverage system you have, then afterwards it converts to LCOV. The testing is not all you need to modify. You need to modify every compile and link step, since you get byproducts of the instrumentation on every step. >Sometimes this might require updates to language specific rules because the test runner itself needs to be configured. That's what I found, too, however I feel like rewriting the C++ rules is a huge undertaking, since they're not defined in Starlark.
  - simplotek 4y ago
    > You can get coverage working for almost anything by having each test convert its coverage data to LCOV before stopping, in the same sandbox as the test. I have to call bullshit on this. With C or C++ you need to build the whole project with specific compiler flags to be able to generate code coverage reports. This is not something you implement by tweaking a setting in unit tests.
- sam_bristow 4y ago
  I've also struggled with the C++ coverage support in Bazel. It looks unloved since around 2018. The most useful leads I've found so far are: * The design doc for the (abandoned?) coverage framework [1] * A prototype of GCOVR support [2] * Comment on getting llvm-profdata working [3] [1] https://docs.google.com/document/d/1-ZWHF-Q-qCKf19ik-t33ie58BkNurrYYzKR4OLtcilY/edit https://docs.google.com/document/d/1-ZWHF-Q-qCKf19ik-t33ie58... [2] https://github.com/ulfjack/bazel/commit/e9f21bbf562c1f6006eb8615569359755a57dd11 https://github.com/ulfjack/bazel/commit/e9f21bbf562c1f6006eb... [3] https://github.com/bazelbuild/bazel/issues/8178#issuecomment-488390198 https://github.com/bazelbuild/bazel/issues/8178#issuecomment...
DarkNova6 4y ago
That begs the question: which build systems have you used before?
di4na 4y ago
Because the outside world is diverse and open source does not have the ressources to write bazel rules. Nor does it fit their history. There is definitely a need for better (and Meson is the foss answer, as well as Shake). But Bazel need a context that OpenSource do not have. Time and a clean slate of dependencies cooperating. Also noone fund tools for DX for OpenSource devs :) only for JS and even that...
- jmmv 4y ago
  > Because the outside world is diverse and open source does not have the ressources to write bazel rules. But the open source world has the resources to write new build systems (and ecosystems!) time and time again. This argument does not hold up.
  - cryptonector 4y ago
    Not really. Some open source projects go back a long long time and have a large enough build system that rewriting it would require a lot of effort. Other open source projects are small enough that the simplest build system the author(s) could build was good enough.
  - simplotek 4y ago
    > But the open source world has the resources to write new build systems (and ecosystems!) time and time again. What leads you to believe that writing new build systems is a popular hobby? I mean, cmake is the de facto standard for C++ projects and it has been for what? Over a decade? What does this tell you?
- fsociety 4y ago
  The standard suite of open sourced Bazel rules are powerful enough for 99% of use cases. I have seen people argue this isn’t true, or that a rules package is fundamentally broken, but then learn that they are holding it wrong. And that holding it wrong reveals some glaring issues with how they setup their build system. It’s not solely the user’s responsibility to hold it right. But Bazel is and has been developed in the “open source context” for long enough now that your argument doesn’t hold up imo.
reitanuki 4y ago
on the other hand, there are some of us that really dislike Bazel. Try compiling something for ARM and then realising you can't find a build of the build tool for ARM... That was a special level of pain. Tools commonly available in distros are typically much easier to use for outsiders.
- Game_Ender 4y ago
  FWIW Bazel now ships linux (and Mac and Windows) arm64 binaries: https://github.com/bazelbuild/bazel/releases/download/6.1.1/bazel-6.1.1-linux-arm64 https://github.com/bazelbuild/bazel/releases/download/6.1.1/... Definitely a ton of rough edges on Bazel but the passage of time is rounding them, even if progress uneven and frustratingly slow.
- dilyevsky 4y ago
  I’m cross-compiling c++/rust/go project to linux arm target from mac hosts. Took 2hrs to setup. > Tools commonly available in distros are typically much easier to use for outsiders. Which part about autotools or ninja is easier?
fsociety 4y ago
I think Bazel is actually a good build system, but the issue is that they lack good educational resources. Then others adopt it at smaller companies without a team to manage Bazel and without investing time to onboard others into understanding how it works. There are some new talks coming out external from the Bazel maintainers which do a better job of this, but you still have to hunt for them. This is made worse because each of the rules packages, which are super useful, have their own idiosyncrasies which only make sense with a solid foundation in what problems Bazel solves, how it works and how to write/read rules. My other wishlist for Bazel was an easier time setting up a hermetic sandbox without having caveats. This is improving, so I am optimistic on this front. For context, I am not a Google (or ex-Google) engineer and I’ve had to work with a ton of different build systems on different levels of the stack.
- HervalFreire 4y ago
  Not just that it doesn't integrate well with external tools. Cmake works better here. We had a googler at our company switch everything to bazel and it just slowed everyone down. There really is something about Google engineers, this sort of subtle arrogance that the Google way is superior to everything else is existence. Maybe I'm the ass hole but I wonder if anyone can relate?
  - simplotek 4y ago
    > We had a googler at our company switch everything to bazel and it just slowed everyone down. I'd love to hear if anyone can make a case for Bazel knowing that cmake+build cache tools like ccache buy far better performance improvements than any full or incremental build.
    - fsociety 4y ago
      If I want near-instantaneous compile times with my build system I'll just make a bash script or Makefile and use a single compilation unit (which Rust does not really do). When I use Bazel it is because: - I want to build nearly everything from source in a controlled hermetic environment. No more "well it works on my machine"... only to learn the developer's libs leaked into the build environment. - I want to do this with a single build system that works across many languages, and to build libraries which are used in many different languages. - I want to do this within a sandboxed environment for peace of mind when compiling thousands of dependencies. - I am willing to pay the money and time to setup remote executors to keep performance acceptable.
malkia 4y ago
This was my fist experience with blaze too. First it was, wtf is this shit, and theze blaze-bin/etc folders. Then after I left Google I realized how much I miss it. No Make is not a replacement, or ninja.
- simplotek 4y ago
  > No Make is not a replacement, or ninja. Why? The world has been running on make for decades, and it runs just fine. Meanwhile, does Bazel support basic stuff like shared libs or vended libs that are not deployed system-wide? Last time I checked, it didn't.
  - jvolkman 4y ago
    Yes, Bazel supports both of those things.
    - simplotek 4y ago
      You have people in this discussion claiming otherwise, and I also know for a fact that in the past it did not supported either. Can you actually provide a working example?
      - jvolkman 4y ago
        Not sure if this is what you're looking for exactly, but: https://github.com/jvolkman/bazel-ex-20230324 https://github.com/jvolkman/bazel-ex-20230324
simplotek 4y ago
> Every time I have to learn a new build system in open source work I groan. Why are there so many systems for essentially the same thing? I'd love to hear what leads you to believe that adding yet another build system in the form of Bazel would solve that problem for you.

carlmr 4y ago

Question for an insider. Bazel code coverage seems to be one of the roughest edges. At least when running C++ tests. Only lcov is supported, and due to the sandboxing it's impossible to get other tools working since they always spit out extra instrumentation data that's neither cached nor available on the next sandbox. Does blaze support code coverage properly? Does Google just not care about code coverage? Am I just missing some obvious thing in the documentation?

bjackman 4y ago
Hmm sorry I'm quite ignorant about that. Code coverage is pretty well supported in the internal ecosystem but I would not be surprised to hear this is because we designed Bazel around the system Google was already using for coverage.
- simplotek 4y ago
  > Code coverage is pretty well supported in the internal ecosystem (...) What you're actually saying is that internally Google managed to get a single and very specific use case to work and forced all projects to either adopt it or have no code coverage.
Game_Ender 4y ago
You can get coverage working for almost anything by having each test convert its coverage data to LCOV before stopping, in the same sandbox as the test. I forget the exact details but I think you can do this with a custom run_under test wrapper used during coverage. The wrapper runs your test, with whatever custom coverage system you have, then afterwards it converts to LCOV. Sometimes this might require updates to language specific rules because the test runner itself needs to be configured. The bottom line is that Bazel upstream does not put a lot of attention into this, so it’s under developed outside of Google, because Google internal does not use the OSS rules.
- carlmr 4y ago
  >I forget the exact details but I think you can do this with a custom run_under test wrapper used during coverage. The wrapper runs your test, with whatever custom coverage system you have, then afterwards it converts to LCOV. The testing is not all you need to modify. You need to modify every compile and link step, since you get byproducts of the instrumentation on every step. >Sometimes this might require updates to language specific rules because the test runner itself needs to be configured. That's what I found, too, however I feel like rewriting the C++ rules is a huge undertaking, since they're not defined in Starlark.
- simplotek 4y ago
  > You can get coverage working for almost anything by having each test convert its coverage data to LCOV before stopping, in the same sandbox as the test. I have to call bullshit on this. With C or C++ you need to build the whole project with specific compiler flags to be able to generate code coverage reports. This is not something you implement by tweaking a setting in unit tests.
sam_bristow 4y ago
I've also struggled with the C++ coverage support in Bazel. It looks unloved since around 2018. The most useful leads I've found so far are: * The design doc for the (abandoned?) coverage framework [1] * A prototype of GCOVR support [2] * Comment on getting llvm-profdata working [3] [1] https://docs.google.com/document/d/1-ZWHF-Q-qCKf19ik-t33ie58BkNurrYYzKR4OLtcilY/edit https://docs.google.com/document/d/1-ZWHF-Q-qCKf19ik-t33ie58... [2] https://github.com/ulfjack/bazel/commit/e9f21bbf562c1f6006eb8615569359755a57dd11 https://github.com/ulfjack/bazel/commit/e9f21bbf562c1f6006eb... [3] https://github.com/bazelbuild/bazel/issues/8178#issuecomment-488390198 https://github.com/bazelbuild/bazel/issues/8178#issuecomment...

DarkNova6 4y ago

That begs the question: which build systems have you used before?

di4na 4y ago

Because the outside world is diverse and open source does not have the ressources to write bazel rules. Nor does it fit their history. There is definitely a need for better (and Meson is the foss answer, as well as Shake). But Bazel need a context that OpenSource do not have. Time and a clean slate of dependencies cooperating. Also noone fund tools for DX for OpenSource devs :) only for JS and even that...

jmmv 4y ago
> Because the outside world is diverse and open source does not have the ressources to write bazel rules. But the open source world has the resources to write new build systems (and ecosystems!) time and time again. This argument does not hold up.
- cryptonector 4y ago
  Not really. Some open source projects go back a long long time and have a large enough build system that rewriting it would require a lot of effort. Other open source projects are small enough that the simplest build system the author(s) could build was good enough.
- simplotek 4y ago
  > But the open source world has the resources to write new build systems (and ecosystems!) time and time again. What leads you to believe that writing new build systems is a popular hobby? I mean, cmake is the de facto standard for C++ projects and it has been for what? Over a decade? What does this tell you?
fsociety 4y ago
The standard suite of open sourced Bazel rules are powerful enough for 99% of use cases. I have seen people argue this isn’t true, or that a rules package is fundamentally broken, but then learn that they are holding it wrong. And that holding it wrong reveals some glaring issues with how they setup their build system. It’s not solely the user’s responsibility to hold it right. But Bazel is and has been developed in the “open source context” for long enough now that your argument doesn’t hold up imo.

reitanuki 4y ago

on the other hand, there are some of us that really dislike Bazel. Try compiling something for ARM and then realising you can't find a build of the build tool for ARM... That was a special level of pain. Tools commonly available in distros are typically much easier to use for outsiders.

Game_Ender 4y ago
FWIW Bazel now ships linux (and Mac and Windows) arm64 binaries: https://github.com/bazelbuild/bazel/releases/download/6.1.1/bazel-6.1.1-linux-arm64 https://github.com/bazelbuild/bazel/releases/download/6.1.1/... Definitely a ton of rough edges on Bazel but the passage of time is rounding them, even if progress uneven and frustratingly slow.
dilyevsky 4y ago
I’m cross-compiling c++/rust/go project to linux arm target from mac hosts. Took 2hrs to setup. > Tools commonly available in distros are typically much easier to use for outsiders. Which part about autotools or ninja is easier?

fsociety 4y ago

I think Bazel is actually a good build system, but the issue is that they lack good educational resources. Then others adopt it at smaller companies without a team to manage Bazel and without investing time to onboard others into understanding how it works. There are some new talks coming out external from the Bazel maintainers which do a better job of this, but you still have to hunt for them. This is made worse because each of the rules packages, which are super useful, have their own idiosyncrasies which only make sense with a solid foundation in what problems Bazel solves, how it works and how to write/read rules. My other wishlist for Bazel was an easier time setting up a hermetic sandbox without having caveats. This is improving, so I am optimistic on this front. For context, I am not a Google (or ex-Google) engineer and I’ve had to work with a ton of different build systems on different levels of the stack.

HervalFreire 4y ago
Not just that it doesn't integrate well with external tools. Cmake works better here. We had a googler at our company switch everything to bazel and it just slowed everyone down. There really is something about Google engineers, this sort of subtle arrogance that the Google way is superior to everything else is existence. Maybe I'm the ass hole but I wonder if anyone can relate?
- simplotek 4y ago
  > We had a googler at our company switch everything to bazel and it just slowed everyone down. I'd love to hear if anyone can make a case for Bazel knowing that cmake+build cache tools like ccache buy far better performance improvements than any full or incremental build.
  - fsociety 4y ago
    If I want near-instantaneous compile times with my build system I'll just make a bash script or Makefile and use a single compilation unit (which Rust does not really do). When I use Bazel it is because: - I want to build nearly everything from source in a controlled hermetic environment. No more "well it works on my machine"... only to learn the developer's libs leaked into the build environment. - I want to do this with a single build system that works across many languages, and to build libraries which are used in many different languages. - I want to do this within a sandboxed environment for peace of mind when compiling thousands of dependencies. - I am willing to pay the money and time to setup remote executors to keep performance acceptable.

malkia 4y ago

This was my fist experience with blaze too. First it was, wtf is this shit, and theze blaze-bin/etc folders. Then after I left Google I realized how much I miss it. No Make is not a replacement, or ninja.

simplotek 4y ago
> No Make is not a replacement, or ninja. Why? The world has been running on make for decades, and it runs just fine. Meanwhile, does Bazel support basic stuff like shared libs or vended libs that are not deployed system-wide? Last time I checked, it didn't.
- jvolkman 4y ago
  Yes, Bazel supports both of those things.
  - simplotek 4y ago
    You have people in this discussion claiming otherwise, and I also know for a fact that in the past it did not supported either. Can you actually provide a working example?
    - jvolkman 4y ago
      Not sure if this is what you're looking for exactly, but: https://github.com/jvolkman/bazel-ex-20230324 https://github.com/jvolkman/bazel-ex-20230324

simplotek 4y ago

> Every time I have to learn a new build system in open source work I groan. Why are there so many systems for essentially the same thing? I'd love to hear what leads you to believe that adding yet another build system in the form of Bazel would solve that problem for you.