3 ms·

I think this view is too narrow; there is definitely need for fine-grained incremental build systems, even outside mono-repos. If you need to chase a bug into

by nh2 5y ago

I think this view is too narrow; there is definitely need for fine-grained incremental build systems, even outside mono-repos. 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've had to do this multiple times in the past, and had to employ big hacks to get around this limitation. My project also uses non-incremental nix, and an incremental build for our single-package top-level code. We just tolerate the waiting time, but it's not ideal. This works because our project is relatively small and updates to dependencies are not super frequent, so we can spend the time to build ad-hoc hacks to shortcut those builds each time. We find this better than any other currently available way, but it's not ideal. I'm not convinced that Bazel is the final answer to this (it focused almost entirely on its way to do things, ignoring the package-based world that makes up the open-source eco system). But there's definitely the need for something that addresses both sides, cleanly, and it hasn't been found yet.

adev_ 5y ago
> 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.

by nh2 5y ago

adev_ 5y ago

> 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.