[ris]

> Have you tried Nix? It's like Bazel, but without incremental builds.

Well, depending on how granular you expect your incremental builds to be, it can indeed have "incremental builds". Any build step that produces a derivation that ends up in the nix store will be lazily evaluated and not regenerated if its input parameters haven't changed. You could go down the route of outputting each compiled object file as a derivation...

[benley]

> You could go down the route of outputting each compiled object file as a derivation...

You could, but I believe you would find that Nix becomes pretty inefficient in that scenario. There is a surprising amount of overhead involved in setup/teardown of network namespaces and the other various sandbox features, and that cost is incurred for each individual derivation. It's a reasonable tradeoff for Nix when used as a package-level build sandbox, but (assuming my understanding is correct and still current) for Nix to work well as a file-level incremental build system it would require some strategic changes.

Here's the github issue with a bunch of related discussion and details: https://github.com/NixOS/nix/issues/179

[ris]

Yes it's all interesting stuff.

But, one way of looking at it, that's just ("just") an implementation issue. No ideas fundamental to Nix would have to be changed to find a faster way of implementing derivation isolation, hopefully any solution to problems like this could be transparent to people who had written build systems in Nix and not require significant rewrites...?

Even so, incremental builds wouldn't be an all-or-nothing scenario. A project could be divided up into a number of separately buildable partitions, each built as a separate derivation. Deciding how granular to make your incremental..ism would just be a tradeoff of overhead vs. amount of rebuilding saved.