[johnasmith]

There are build systems where this guidance isn't terribly valuable.

With Bazel for example, you typically have build files in each directory, and a test target for each test class in that build. But bazel allows you to select and run targets in a collection of directories, select targets recursively, or by a variety of other criteria. Your CI systems runs targets selected implicitly, while each build expresses the test targets explicitly.

[sam_bristow]

Some (not all) still applies. I just reworked the Bazel CI at $DAYJOB to simplify the entry points and just call `bazel build //...` And `bazel test //...` erc rather than a bunch of more specific targets. We've got caching etc effective enough that just testing everything is a viable default even in a tight dev loop.

I'm more concerned with duplication of config between the Build and CI configs. https://gregoryszorc.com/blog/2021/04/07/modern-ci-is-too-co...

[kldx]

Context: I tried and failed at convincing management in moving my work monorepo to bazel. We have around 5 core languages plus a bunch of dsls.

If you don't mind sharing, what languages do you build in your bazel workspace? Were you able to use hermetic toolchains for these languages without any major hiccups? Finally, do you use engflow or buildbuddy atop bazel?

Thanks!

[hamandcheese]

Not the parent, but at my previous job we used lots of JVM languages, plus some python and a tiny bit of JS. We were not particularly successful in getting truly hermetic builds with it - a big part of was a lack of headcount actually working on it.

My main takeaway is this: if you're the only one in the room asking for bazel, it's probably a bad choice. Bazel requires a lot of investment to stay nice to use, particularly in a polyglot environment. I've experienced endless friction getting things to work "in bazel" that would otherwise be simple using language-specific tooling.

In my opinion, the benefits (caching, build speed, a single build tool) did not outweigh the costs (nonstandard tool means you are always operating in hard-mode compared to using language-specific build tools, it's a ton of work to make actually hermetic, devs often aren't familiar with it and don't like writing BUILD files, editor support is extremely lacking outside of IntelliJ).

[paulddraper]

While I am a very happy user of Bazel at $DAYJOB, I agree that it signs you up for a different but very real set of problems.

[sam_bristow]

$DAYJOB codebase is mostly C++ and Python with a bit of custom configuration DSL for code generation.

Getting hermetic Python was pretty straight forward, hermetic C++ for cross-compilation to our target hardware was a bit more challenging but not too bad.

We also have VHDL which is built outside of Bazel for now. That's a job for 2024 and, I expect, will be a much bigger challenge.

We don't use BuildBuddy or EngFlow as we have some special requirements that made it not an option. I have a couple of personal projects using Buildbuddy though and it works well.

[Eridrus]

FWIW, I have had more luck with Pantsbuild rather than Blaze.

The fact that it does dependency inference has made adoption far easier. I've found the community pretty active on Slack too.

Using it to build Python/Java/Kotlin/Go/Docker; generally pretty happy with it, though the Python support is the best and the Go support is the weakest.

[dharmab]

Similarly, it's a common pattern to have a Makefile for each directory in a C project.

[IvanVergiliev]

Just an FYI in case you haven’t read this: Recursive Make Considered Harmful [1]

[1] https://aegis.sourceforge.net/auug97.pdf

[dharmab]

Yeah, I prefer a single top-level file myself.