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

41–50 of 58 posts

Re: What's New in Bazel 6.0

#41

Post by en4bz »

emidln wrote: post #38
en4bz wrote: post #30

Earlier quoted context omitted.

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.

You're assuming you have control over all the deps and can set `linkstatic` on them.

Re: What's New in Bazel 6.0

#42

Post by emidln »

en4bz wrote: post #39
emidln wrote: post #36

Earlier quoted context omitted.

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.

*You are the consumer.* You are consuming it in foo. Are you building some straw man consumer who might want to delve into my build and rearrange my libraries with no work at all? You can even do that if you want. Remove the linkstatic line from qux. Now it has two outputs: `libqux.a` (default) and a `libqux.so` (implicit). If you want to ship both of them in a release artifact, you can. If you want to mark some binaries `linkstatic = True` and statically link them you can. If you want to dyanmically link some binaries, you can do that too.

I was demonstrating that you can force some libraries to be only static and still partially link some things static and some dyanmic. If you want to get really into the weeds, you could even affect the link line and individually pick dependencies in a custom rule (that is fully compatible with the rest of the bazel tooling). Almost nobody ever needs to do that, but maybe you want to make only every other dependency dynamic to satisfy some weird slide in a talk.

Re: What's New in Bazel 6.0

#43

Post by emidln »

emidln wrote: post #38
en4bz wrote: post #30

Earlier quoted context omitted.

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.

> You're assuming you have control over all the deps and can set `linkstatic` on them.

In bazel you have complete control over all of your deps. Ultimate power and ultimate responsibility. Even an external BUILD.bazel can be patched when you bring it in (bazel has provisions for patching stuff from http_archive if you supply a patch). You can even ignore an existing BUILD.bazel and write your own if you only care about part of an external thing. If it's a target in your graph, you can certainly modify it. If there is some internal process that prevents you from modifying your own code, I can't help you. Maybe fix that or go somewhere that gives you the authority to do your job.

Re: What's New in Bazel 6.0

#44

Post by en4bz »

lopkeny12ko wrote: post #37
en4bz wrote: post #29

Earlier quoted context omitted.

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.

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.

Re: What's New in Bazel 6.0

#45

Post by en4bz »

emidln wrote: post #43
emidln wrote: post #38

Earlier quoted context omitted.

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.

> You're assuming you have control over all the deps and can set `linkstatic` on them. In bazel you have complete control over all of your deps. Ultimate power and ultimate responsibility. Even an external BUILD.bazel can be patched when you bring it in (bazel has provisions for patching stuff from http_archive if you supply a patch). You can even ignore an existing BUILD.bazel and write your own if you only care abo…

> bazel has provisions for patching stuff from http_archive if you supply a patch

That's a hack.

Re: What's New in Bazel 6.0

#46

Post by lopkeny12ko »

en4bz wrote: post #44
lopkeny12ko wrote: post #37

Earlier quoted context omitted.

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

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.

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

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

Re: What's New in Bazel 6.0

#47

Post by bradhe »

lalaland1125 wrote: post #15

The main change here is that Bazel now has a package repository that people can pull/push external dependencies to: 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.

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?

Re: What's New in Bazel 6.0

#48

Post by joshuamorton »

en4bz wrote: post #44
lopkeny12ko wrote: post #37

Earlier quoted context omitted.

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

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.

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.

Re: What's New in Bazel 6.0

#49

Post by en4bz »

joshuamorton wrote: post #48
en4bz wrote: post #44

Earlier quoted context omitted.

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.

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.

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.

Re: What's New in Bazel 6.0

#50

Post by tadfisher »

en4bz wrote: post #44
lopkeny12ko wrote: post #37

Earlier quoted context omitted.

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

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.

Non-hermetic is non-reproducible. I can only produce the same build outputs as you if I use the same toolchain, which essentially implies I must run the same OS and patch level, among a host of smaller impurities that can change the output of a build.

Sometimes this is desirable; for example, if you are packaging for a Linux distribution. But that's not the use case Bazel was invented to serve.

Post reply on HN