Oh my god. The Bazel website is "translated by Google" (into German in my case).<p>"Warum OBA?" - "Why OBA?": i have no idea what OBA might mean. It's not a common acronym.<p>But it gets better. "Fast, richtig". Yes, that means "almost correct". A great claim!
I have been using Bazel (4, then 5) as the build tool for a small Go monorepo with ~10 (and growing) Dockerized applications importing a handful of internal packages. The initial setup was a bit of a learning curve, and it is overkill for our current stack, but builds are very fast.<p>At the same time, I have been using NX for a larger (though not huge) Javascript monorepo. Javascript is my strongest language, so take this with a grain of salt, but at my org's scale I vastly prefer the NX experience over Bazel. I think the reason is that NX feels like an optimized, natural extension of normal Javascript build tooling, while Bazel requires an entirely separate set of knowledge.
A build system optimized for use at Google seems like it must be unavoidably badly pessimized for practically everyone else, as with Kubernetes. But I have not tried it.<p>I know that some people use Cargo for non-Rust projects. Curious about experience with that, vs. e.g. Meson. CMake is used for a lot of projects, but that experience has been almost as bad as Autotools, yet still better than SCons or WAF.
Now is actually not a horrible time to start at least being aware of Bazel. With their upcoming 6.0 release in a couple of months they are bringing in some much more sensible primitives to work with that make it much less intimidating than it has been to date.<p>Don’t get me wrong it’s still EXTREMELY power user and I imagine several years before it starts making a name for itself outside of mega corps like Google and Twitter because the ecosystem right now is a mess but I genuinely hope it can live up to its full potential where you can build basically any project from scratch with a single command and know that it was done right and with many other guarantees under the hood.
I have always been amused by their motto "Fast, Correct - Choose two". The more common idiom is something like "Fast, Correct, Cheap - Choose Two". I guess Bazel isn't cheap.
All of my clients use Bazel now, so I've started using Bazel. I like it a lot, but there are some kludges when you get into any non-trivial chain of dependencies.<p>First off, if you depend upon another Bazel project which has its own dependencies, you need to clone dependencies from its WORKSPACE into yours for any targets you are hitting. If they chose to include macros for importing their dependencies, you may use those, but this would be opt-in. This is not technically unreasonable; you have all the power you need to have everything in your project depend upon a single version of a shared library or potentially import multiple versions (depending on how tangled the tree is), but you have to use this power, even if you don't care. Compare this to a non-sandboxed, more naive build using whatever version of libraries was found in the environment. You have the means to tightly control what is in the environment, or not care. With Bazel you have to care.<p>The dependency chain has led to a problem in practice when I tried to use Google's protobufs and Cython at the same time. The protobuf generated Python bindings use a particular version of Cython and override Cython's own Bazel rules, which seemed like a very rude and unnecessary practice. This made it impossible for me to use Cython in the same project as protobufs. A bug report to protobuf was met with "PR welcome."<p>As far as I can tell there are no "best practices" or features in Bazel to ease this kind of degenerate dependency chaining. If there are, a popular Google library decided not to use them. I consider dependencies to be the best and worst thing about Bazel; when it works it just works, when it doesn't it really doesn't.<p>All that said, I would probably use Bazel over pretty much any other alternative for business software in C++. For one-offs and PoC it is overkill.
"sandboxed-execution: Bazel also runs every action in a "sandbox". You can think of sandbox as being akin to a lightweight container. All the declared-inputs are mapped into the sandbox, and the generated outputs are closely monitored. This is done for each action. If a dependency is missed in the input specification - that's a build failure."<p>This reminds me of how Nix[1] is doing things under the hood. Recently added Nix to on of our projects[2] which is still a build system using Nix to manage dependencies.<p>[1]<a href="https://nixos.org/" rel="nofollow">https://nixos.org/</a><p>[2]<a href="https://bob.build/docs/getting-started/package-management" rel="nofollow">https://bob.build/docs/getting-started/package-management</a>