> If you need to chase a bug into a more fundamental library, say libc, libpng, or your stack's favourite JSON library, iterating on that code with plain nix ("

> If you need to chase a bug into a more fundamental library, say libc, libpng, or your stack's favourite JSON library, iterating on that code with plain nix ("package-based non-incremental builds") will now take 20 hours per recompilation. With an incremental build system, it takes seconds, which is obviously a game changer. I see the point but the '20 hour' build seems to me over-exaggerated. - Builds in Nix can be parallelized both on single node (multi-core, multi-socket) and multi-node without problems - Parallel builds 'just works' in Nix with the Nix's sandbox system and the hash-based package identification mechanism. Nothing related to the bug mess that can be a distcc deployment or parallel builds in Bazels. - Binary cache give a pretty efficient way to reuse any successful past build without problem - Modifications in "base" packages generally do not happen everyday scenarios. - Iterations and debugging without majors recompilations can be done with the nix shell directly. Full rebuild are required only for binary shipping. > I've had to do this multiple times in the past, and had to employ big hacks to get around this limitation. I had to recompile entire software stack ( > 1500 software ) for exotic archs (U.S supercomputers) in the past. My way was just to burst it on many nodes: compute time is cheap nowadays (and nodes are not missing on supercomputers :) ) . My time however is not cheap and most incremental builds system are sensible to side-effect (including Bazel) and not as reproducible as they claim to be: Debugging that is in my experience time consuming, much more than a bit a build time. I do see the interest of incremental builds inter-components, but in the current state of the tooling, it is for me not worth the pain. Specially not the pain of Bazel that has a (very) long list of quirks.