That appears to only handle the distcc half. It looks like the main advantage of nocc is that it integrates the equivalent of ccache, in a way that works even when there are both multiple clients and multiple servers, without the ludicrous complexity of bazel-like tools.
Not true. icecream handles that case very well. Any machine in the network can trigger the build. And all the machines in the network can register themselves as build nodes. It also integrates with the ccache.
`ccache icecream` (like `ccache distcc`) only handles the "single client, multiple servers" case.
`icecream ccache` (like `distcc ccache`) only handles the "multiple client, single server" case.
`ccache icecream ccache` (like `ccache distcc ccache`) just means you're wasting even more disk space.
Now, if you configure `ccache` to use remote storage, and you can make it actually work, then that combination will compete with `nocc` (though admittedly it follows different models). But that's a lot more moving parts.
I am not sure I follow your argument. You said that icecream cannot work in multi-client multi-server case. I said that it certainly can, and it can. Perhaps you're arguing that in that multi-case scenario ccache is not usable? That I don't know but it definitely works when ccache is setup on the client machine and this client machine is using whatever number of server machines for the build jobs.
`ccache icecream` with default configuration means that the build servers have to duplicate work for the common case where multiple clients build the same artifact.
Now, maybe remote caching is reliable nowadays, despite its inevitable reputation (given that it wasn't designed for it). But it's still more moving parts, and the magic is in ccache not icecream too.
Did the authors also write their own operating system to avoid the “ludicrous complexity” of the Linux kernel? This project just looks like NIH syndrome and an unwillingness to read documentation.
[1]: https://github.com/icecc/icecream