Hacker News Reader

Comment by IshKebab | Hacker News Reader

In my experience the time this saves is generally outweighed by the effort of setting it up and the many hours lost when it goes wrong and you don't think to try a clean build. It's certainly better than ccache in that regard but you really need something like Bazel if you're going to be aggressively caching C++ builds like this (or impure Rust builds).

(And if you're using Bazel or one of its brethren then they generally have native remote caching and execution support.)

View on HN

Setting it up took hardly 5 minutes for me (for Rust). And it hasn't caused any issues so far. Forcing a fresh build of artifacts is also very easy.

Meanwhile, the only legitimate problem you mentioned is if it causes a build error and we don't immediately consider it as the source of the issue. But I use the check command so often that it is easy to suspect the cache if check succeeds and build fails.

When these things go wrong it often doesn't cause a compilation error; it can just cause inexplicable runtime behaviour.

You may be lucky and be building a pure or mostly pure Rust program, in which case it works pretty well. Throw in some C/C++ and it starts to degrade (though it's still better than with an actual C/C++ program because you aren't actually editing the C/C++ code generally).

And are you actually using remote caching/compilation? Because there's no way you can set that up in 5 minutes.

> And are you actually using remote caching/compilation? Because there's no way you can set that up in 5 minutes.

Who said anything about remote caching? You don't need it to benefit from it. It's useful if you build a lot of Rust code. A lot of packages turn up repeatedly as dependencies among several projects.

> You may be lucky and be building a pure or mostly pure Rust program, in which case it works pretty well. Throw in some C/C++ and it starts to degrade

You're making assumptions again. What is the issue with pure Rust code? Rust isn't like Python needing C or C++ support for process-intensive parts. And much of the C/C++ dependencies are dynamically-linked, with Rust wrappers. I haven't seen many projects that require Rust and C/C++ code to be built together and statically linked.

Besides, I haven't heard anyone complain about sccache that much. How prevalent is the degradation anyway?

After using sccache and Gradle with Buildless for months, years, I have literally never seen these tools mixup or use the wrong binary objects.

Knowing the internals of some of them, I’ve found that build cache clients are way more likely to miss with a cache key misalignment than they are to mixup two objects. I’m sure it’s possible, I’ve just never seen it happen in the wild, after extensive usage.

Generally speaking these tools are very conservative about two inputs matching: an identical file at a different path will cause a cache key change in sccache.

I keep reading this "When these things go wrong" - which is necessarily very intermittent. What is it that goes wrong with these?

ccache pretty aggressively scans for things like __DATE__ and has direct understanding of compiler flags so instances of bad caching are pretty rare, I think I've only had it happen twice in years of use and once was a GCC bug. Also since ccache supports s3 out of the box now remote caching is pretty fast to setup. Remote compilation is not handled by ccache at all. You need distcc or icecc for that.

> Setting it up took hardly 5 minutes for me (for Rust)

You're underselling it, honestly. For those who haven't looked into it, if you want to enable it for all Rust projects on your system, literally all you need is install the binary and then add this to ~/.cargo/config, and then it will be enabled whenever you invoke `cargo` (or even rustc directly iirc) from the user who's config file you modified)

    [build]
    rustc-wrapper = "/path/to/sccache"

I'm sure there are people with legitimate reasons not to wanting it enabled implicitly or who have multiple users they might have to set this up for, but for 90% of people it won't take any more time than it took to read this comment.

Reply on news.ycombinator.com