I've been using distcc for quicker distributed builds without issue for many years. What extra features does sccache bring to the table other than it being rewritten in Rust?
distcc is great, and as I mentioned in that Reddit comment some of my colleagues are using icecream to great success.
I won't repeat my entire comment from Reddit, but one other notable point is that tools like ccache/distcc don't generally support MSVC, and we build Firefox for Windows with MSVC, so that's pretty important to us. And frankly, our Windows builds are slow enough that we can use all the build time wins we can get.
Color me surprised. As a developer, the number of times "Windows support" or "MSVC" is the special case that requires you to go through contortions.. shrug
It's been very frustrating on multiple open source projects I've worked on, people proposing to change entire build systems of projects just so that MSVC can be included as a build target. I hope the new Bash-on-Windows stuff will eventually make supporting MSVC a little simpler from various Unix-oriented build tools.
Supporting Windows is often a pain (although in this case Rust hides a lot of that pain, honestly), but the main driver of the original sccache implementation was not Windows support, but the ability to share the compilation cache across our many ephemeral build machines. My colleague Mike Hommey (who wrote the first implemenation) has some nice graphs demonstrating this in his original blog posts on the topic:
https://glandium.org/blog/?p=3079
Yeah, I'm especially bitter because I just spent my entire weekend getting colors and tty detection to work consistently in Windows. It was unbelievably hard. (The central difficulty is that you need to support both native Windows consoles like cmd.exe and cygwin terminals like mintty.)
It's worth it though. There are lots of people on Windows! And thankfully, most of the other pieces (like the build system) in Rust are cross platform by default. :-)
Meanwhile, GCC works fine on Windows. (Mingw builds normal non Cygwin programs.) There's no need to bow to cl.exe just because you want to build for Windows
If you're shipping binaries to end users Microsoft's optimizer is pretty fantastic, especially if you build with PGO. Plus MinGW sometimes lags behind with things added in newer Microsoft SDKs, so there can be some friction there. I think things are getting better with clang-cl, so that might be a feasible direction in the near future.
Their reddit comments are not consistent with my experience using distcc. I can attest it is indeed a distributed ccache and works quite well. For a while I was even using distcc with a GCC cross compiler on Windows nodes to speed up my Linux app builds.
If there's a sccache maintainer reading this thread please consider explaining the advantages of using sccache over distcc in the README.
> I can attest it is indeed a distributed ccache and works quite well.
The distcc readme says nothing of the sort? It seems to specify that it shares header files and compiles cpp files (which are all presumably sent back to the source as object files, which links them together)
It seems to work with ccache, but if you're spinning up fresh instances all the time ccache will need to be synchronized somehow, and it doesn't seem to drive that (whereas sccache seems to do so)
distcc is not a cache. It doesn't keep the output of the compiler around after it builds things. It (only) distributes running the compiler around (and to do that handles some details of preprocessing, in certain modes) and then gets the output back to the requester of the compilation task.
At that point, the requester could cache that output, should they want to.
