Also, for my purposes (using both Windows and GNU/Linux at work), portability is a tremendous benefit.
With non-hermetic builds, it's much more difficult to verify the correctness of your build rules, which means that you might get non-reproducible builds or you might get incorrect incremental builds. With hermetic builds, it's always safe to do an incremental build, no matter what state the repository is in.
You then need to build that code using a consistent set of tools and libraries, which is where the chroot comes in.
One big chroot around your whole build system isn't enough, you can run into nondeterminism problems due to relative ordering of different build steps during execution. This is why it's nice that the new build systems make each individual step hermetic, because you can make a separate chroot for each individual step (Bazel executes each build step in a separate sandbox).
This allows you to cache all intermediate results, share the cache, and get the same results both for clean and incremental builds, repeatably. It's also easier to remove nondeterminism from individual build steps rather than looking at the whole build.
So you're saying this takes care of race conditions in the build where things may happen out of order even if you have a fixed environment?
- Bazel https://bazel.build/
- Buck https://buckbuild.com/
- Pants https://www.pantsbuild.org/index.html
- Please https://please.build/