[emidln]

It's possible to use bazel to do this. You need to be very explicit (The Bazel Way(tm)), but in exchange, you can ask the graph for everything that is an rdep of a given file. This isn't always necessary in bazel (if you avoid weird integration targets, deploy targets, etc) where `bazel test //...` generally does this by default anyway. It's sometimes necessary to manually express due to incomplete graphs, tests that are not executed every time (for non-determinism, execution cost, etc), and a few other reasons but at least it's possible.

[deathanatos]

Yeah, bazel is sort of the exception that proves the rule, here. I wish it did not have such an absurd learning curve; I've found it next to impossible to get started with it.

[danpalmer]

Bazel is weird. I work at Google, and it's fundamental to our engineering, and I love it for that, but to me it's an internal tool. Nearly all Bazel code I work with is internal (most open source uses of it I see aren't doing enough customisation to be worth it in my opinion), it integrates into so many parts of our engineering workflow, and uses so many internal services like our build farm.

I'm not sure I see much point in using it outside of Google. Maybe if you're a company within 1/10th the size and have a lot of Xooglers? It seems like the sort of thing where most companies don't need it and therefore shouldn't use it, and those that do need it probably need to build their own that's right for them.

[emidln]

It worked well enough for my last company. It does require a team to teach it and to do the heavy lifting on custom rules and tooling. I'd rather do that than worry about whether my c++ that was exposing me to millions/billions of risk might have skipped some tests in our haste for an intraday release.

[esafak]

What would you use for a polyglot project outside of Google?

[pianoben]

Not only is it hard to get started with Bazel, it's hard to continue with Bazel even once you do. Unless you are using Google practices (say, vendoring and compiling all dependencies), you will certainly end up mired in poorly-maintained third-party tools that will cause no end of fun side-quests.

My work became a lot more, ahem, linear, once I moved us off of Bazel.

[Maxious]

Eg. 1 in 10 open source projects abandon bazel within 2 years. https://blogsystem5.substack.com/p/bazelcon-2024-recap