icecream VS sccache

Related

https://github.com/icecc/icecream - another option that does what distcc does, but aimed at a somewhat different use case.

https://ccache.dev/ - a similar idea but provides caching of build outputs instead of distributing builds. You can use it together with distcc to achieve even better performance.

Of course! The github readme provides a lot of info - https://github.com/icecc/icecream

If you like distcc, did you ever give icecc a try?

https://github.com/icecc/icecream

I never had the time to set it up properly, but by the looks of it, it should be even better.

I would like to have a icecc setup I can vpn into. It seems that with normal configs the clients can talk to the scheduler, but the scheduler cant connect to the clients as it tries to connect to the device running the openvpn server not the one behind it. How could I make my openvpn clients appear almost as physical devices on the network, with unique IP's that local devices can connect to; or if that is unnecessary how could I solve this?

Glad to see a new release on this! I've read worrying news about the state of icecc, and the followup uncertain news on sccache, so I hope at least some part of the tooling is in a good shape.

I always wanted to try to use cmake-conan so I could let Conan grab all packages but have a neat cmake script being in charge of what gets built when. Also, this would allow me to easily switch between CMake fetchcontent and Conan packages that may or may not be stashed automatically on a local Artifactory server. Secondly, since now all build requirements are stashed on a server and binary reproducible, you could concider adding icecream and ccache into the mix. (Try running a node one of your buildservers for massive speadups with icecream) This however does require a reproducible build environment (by configure script) which conan again is really good in.

Worth noting that the first commit in sccache git repository was in 2014 (https://github.com/mozilla/sccache/commit/115016e0a83b290dc2...). So I suppose that what "happened" happened waay back.

If you have lots of shared dependencies, maybe try sccache?

I'm going to set up sccache [0] to use it tomorrow. We use MSVC, so EFS is off the cards.

[0] https://github.com/mozilla/sccache/blob/main/docs/S3.md

I think the primary benefit of pre-built procmacros will be for build servers which don't use a persistent cache (like sccache), since they have to compile all dependencies every time. But IMO improved support for persistent caches would be a better investment compared to adding support for pre-built procmacros.

Checkout https://github.com/mozilla/sccache

https://github.com/mozilla/sccache is another option which addresses the use cases of both icecream and ccache (and also supports Rust, and cloud storage of artifacts, if those are useful for you)

That being said a compilation cache, eg the de-facto standard for Rust: sccache (https://github.com/mozilla/sccache) will help to compile and store some of the build artifacts centralized - still for each crate version + build profile (RUSTFLAGS) combination.

That's definitely not my experience. Never had any issue running Rust on Windows. You just download and run rustup-init.exe, then updating is simply a matter of rustup update. Documentation generation is built in (cargo doc) and just a case of annotating code with triple-/ markdown comments and then running that command. sccache works fine for me (just need to set RUSTC_WRAPPER=/path/to/sccache). And the error messages from rustc are by far the best of any compiler I've used. Not sure how they're unhelpful, they tend to explain step-by-step what the problem is and how to fix it.