21–30 of 58 posts
> 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?
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, yo…
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/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…
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?
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?
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
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.
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/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…
Maybe check out justbuild [0], the main author used to be a bazel dev and wanted to combine it's strengths with the possibility of multi repos and more possibilities to interact with the dependency tree. Quite interesting and very responsive team. [0] https://github.com/just-buildsystem/justbuild
Earlier quoted context omitted.
0 and 1 have been supported for a while. See the "linkstatic" feature.
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.
Earlier quoted context omitted.
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.
This is true for any language ecosystem or build tool, whether it's bazel, maven, unrealbuildtool, Jenkins, cmake, gradle etc.
Bazel is kind of to the side everywhere.
Earlier quoted context omitted.
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
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…
Earlier quoted context omitted.
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.
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.