The defining feature of Bazel is sandboxing build steps so that you can't accidentally miss edges in the dependency graph. This has enormous benefits:
1. Incremental/cached builds are reliable.
2. You can reliably avoid rebuilding/testing artifacts that cannot possibly be affected by a PR.
Neither of those are possible in build systems that don't do this sandboxing. If you're doing a big project you really need these, hence why Google came up with this technique.
I'm not sure there's much value in a new build system that doesn't even get that right. We already have dozens.
Yeah that's what I mentioned in the last sentence of my comment
The reason most build systems don't have it is because sandboxing is OS-specific
Bazel has sort of a complicated bootstrap/deployment for that reason.
I mentioned it a few times, but someone should extract the exec wrappers from Bazel as a separate project :) It's a small amount of code, though fiddly to build and distribute
There are few other strategies like bubblewrap, but last I heard bubblewrap is not installed by default on most distros. It needs setuid root so it's a bit fiddly and has security implications
But then you also need something totally different for OS X and Windows
The problem with Bazel is that a sandboxed build environment is useless unless you also have a hermetic runtime environment, and Bazel does nothing to solve this problem. While you may be able to consistently build, your runfiles tree can easily be un-runnable on any system except the one that built it.
When I was heavily using Bazel ~3 years ago we had made substantial changes to the Bazel source to try to support this, but ultimately couldn't get it across the finish line without making changes to Linux's dynamic loader. After talking to a few folks familiar with Blaze, it seems that's exactly what they've done inside Google to solve the problem.
Perhaps the situation has improved in the last 3 years, but my general experience with Bazel is that it made extremely lofty claims and delivered on very few of them.
I don't remember using runfiles much outside of tests in Bazel, even at Google. My guess would be that runfiles are packaged up into via MPM [1], which in open source world I would guess a container image is the closest equivalent? Then you get hermetic runtime environment, especially because k8s/containers seems to be the default deployment platform these days. I think the bazel OCI rules [2] should package runfiles too (I haven't checked)
I'm curious too. I'm guessing it's something to do with sonames & rpaths which often need fixing up during installation (CMake does this for example). I haven't ever used Bazel for distributing Linux binaries so maybe it just doesn't have that built in.
(I would go with statically linked binaries anyway tbh.)
1. Incremental/cached builds are reliable.
2. You can reliably avoid rebuilding/testing artifacts that cannot possibly be affected by a PR.
Neither of those are possible in build systems that don't do this sandboxing. If you're doing a big project you really need these, hence why Google came up with this technique.
I'm not sure there's much value in a new build system that doesn't even get that right. We already have dozens.