Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's New in Bazel 6.0

buildbuddy.io

Post reply on HN
Print view View original

31–40 of 58 posts

Re: What's New in Bazel 6.0

#31

Post by jitl »

dbaupp wrote: post #13
nisa wrote: post #2

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…

We’ve had a good experience using Pants 2 ( https://www.pantsbuild.org/ ) and its dependency inference ( https://blog.pantsbuild.org/why-dependency-inference/ ) for Python. Although we are in a monorepo, rather than a “multi-repo”.

It's cool that Pants has enough community to evolve beyond being a Twitter-led project. It seems Twitter itself migrated from Pants to Bazel, and no longer works on Pants: https://groups.google.com/g/pants-devel/c/PHVIbVDLhx8/m/LpSK...

I find it hard to buy into one of these "mega build system" ecosystems because there are so many competing tools that descend from Blaze: Bazel, Pants, Buck, Buck2, etc. The migration path to these systems takes substantial effort, so I wouldn't want to bet on the wrong one and have to do it all again a few years later. I'm content to wait patiently for Bazel or Buck2 to clearly win before I invest.

Re: What's New in Bazel 6.0

#32

Post by jen20 »

dbaupp wrote: post #13
nisa wrote: post #2

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…

We’ve had a good experience using Pants 2 ( https://www.pantsbuild.org/ ) and its dependency inference ( https://blog.pantsbuild.org/why-dependency-inference/ ) for Python. Although we are in a monorepo, rather than a “multi-repo”.

Do you know what the current maintenance story for Pants is following Twitter's move to Bazel?

Re: What's New in Bazel 6.0

#33

Post by pests »

simplotek wrote: post #21

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?

It's not out of the box if you need third party tools is it?

Re: What's New in Bazel 6.0

#34

Post by dbaupp »

jen20 wrote: post #32
dbaupp wrote: post #13

Earlier quoted context omitted.

We’ve had a good experience using Pants 2 ( https://www.pantsbuild.org/ ) and its dependency inference ( https://blog.pantsbuild.org/why-dependency-inference/ ) for Python. Although we are in a monorepo, rather than a “multi-repo”.

Do you know what the current maintenance story for Pants is following Twitter's move to Bazel?

It seems to be quite active, with regular new releases. I’m lead to believe that https://www.toolchain.com/ is the main sponsor, but there are maintainers from other companies too. I do not know the details, though.

Re: What's New in Bazel 6.0

#35

Post by dbaupp »

jitl wrote: post #31
dbaupp wrote: post #13

Earlier quoted context omitted.

We’ve had a good experience using Pants 2 ( https://www.pantsbuild.org/ ) and its dependency inference ( https://blog.pantsbuild.org/why-dependency-inference/ ) for Python. Although we are in a monorepo, rather than a “multi-repo”.

It's cool that Pants has enough community to evolve beyond being a Twitter-led project. It seems Twitter itself migrated from Pants to Bazel, and no longer works on Pants: https://groups.google.com/g/pants-devel/c/PHVIbVDLhx8/m/LpSK... I find it hard to buy into one of these "mega build system" ecosystems because there are so many competing tools that descend from Blaze: Bazel, Pants, Buck, Buck2, etc. The migration…

I have the sense that migrating to any hermetic, cacheable build system will be more effort than migrating from one to another: once a project is “safe” to have everything run in sandboxes, the mechanisms for setting up those sandboxes is less important. For example, once one system has accurate dependency information, that can be used as a base for setting up the second system (and presumably this info can be exported for machine-assisted migration).

Of course, the details of each system differ enough that I imagine it’s not trivial.

Re: What's New in Bazel 6.0

#36

Post by emidln »

en4bz wrote: post #20
lalaland1125 wrote: post #18

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.

I don't know what you're talking about. This is trivial to accomplish using `linkstatic` as documented on `cc_library` and `cc_binary`. I uploaded a demo to github here: https://github.com/emidln/bazel_static_dynamic_c_demo/blob/m...

Try it out like this:

    # you'll need a c compiler installed, xcode is fine on macos
    git clone https://github.com/emidln/bazel_static_dynamic_c_demo
    cd bazel_static_dynamic_c_demo
    bazel run //:foo
    ldd bazel-bin/foo  # otool -L bazel-bin/foo if you're on MacOS

Re: What's New in Bazel 6.0

#37

Post by lopkeny12ko »

en4bz wrote: post #29
lopkeny12ko wrote: post #25

Earlier quoted context omitted.

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…

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.

That is precisely the point--using system-provided libraries in your Bazel project is an antipattern that should be avoided.

Re: What's New in Bazel 6.0

#38

Post by emidln »

en4bz wrote: post #30
lalaland1125 wrote: post #27

Earlier quoted context omitted.

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.

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.

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.

Re: What's New in Bazel 6.0

#39

Post by en4bz »

emidln wrote: post #36
en4bz wrote: post #20

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.

I don't know what you're talking about. This is trivial to accomplish using `linkstatic` as documented on `cc_library` and `cc_binary`. I uploaded a demo to github here: https://github.com/emidln/bazel_static_dynamic_c_demo/blob/m... Try it out like this: # you'll need a c compiler installed, xcode is fine on macos git clone https://github.com/emidln/bazel_static_dynamic_c_demo cd bazel_static_dynamic_c_demo bazel ru…

qux is now forced to be static. Consumers should be able to choose whatever they want. I don't know what end users want to do.

Re: What's New in Bazel 6.0

#40

Post by emidln »

lopkeny12ko wrote: post #25
en4bz wrote: post #24

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…

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_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.

Post reply on HN