Ccache – a fast C/C++ compiler cache

Re:Ccache – a fast C/C++ compiler cache by BenFrantzDale on Thursday November 24, 2022 @07:28AM (#33730549)

I use ccache and love it, but I keep wondering: wouldn’t it make more sense for compilers to do caching themselves? That would allow them to cache the results of much finer-grained operations than whole translation units. If two (or 500!) translation units generate the same template instantiations and then each optimize that code, that has to happen in each translation unit and ccache can’t help; couldn’t a compiler with internal caching do it once and be done with it forever? I’ve considered trying to add this to clang, but haven’t prioritized it.

[ Parent | on HN ]

Re:Ccache – a fast C/C++ compiler cache by jcelerier on Thursday November 24, 2022 @07:41AM (#33730646)

zapcc used to work exactly like this. Sadly it was never merged back in clang even after being open sourced.

https://github.com/yrnkrn/zapcc

[ Parent | on HN ]

Re:Ccache – a fast C/C++ compiler cache by Cloudef on Thursday November 24, 2022 @08:15AM (#33730956)

zig && zig cc does this + they are even planning to do incremental compilation with binary patching

[ Parent | on HN ]

Re:Ccache – a fast C/C++ compiler cache by kristoff_it on Thursday November 24, 2022 @09:00AM (#33731340)

Correct about the caching, but we don't plan to support in-place binary patching for C/C++ with the same level of granularity as with Zig.

[ Parent | on HN ]

Re:Ccache – a fast C/C++ compiler cache by Cloudef on Thursday November 24, 2022 @09:12AM (#33731434)

That's understandable

[ Parent | on HN ]

Re:Ccache – a fast C/C++ compiler cache by bjackman on Thursday November 24, 2022 @11:01AM (#33732821)

I think most of the requirements of this are fully orthogonal to the job of a given compiler, so it's best solved at the level of the build system.

Bazel does this, so instead of needing to reimplement this for each compiler it's automatically done across all your languages, and even any random one-off build rules based on a shell script.

You can share the cache with your team/build infra too: https://bazel.build/remote/caching

(Disclaimer: I've never used this with open-source Bazel, I work at Google and use the internal variant)

[ Parent | on HN ]

Re:Ccache – a fast C/C++ compiler cache by fatneckbeardz on Thursday November 24, 2022 @12:39PM (#33734003)

the time you spend pulling your hair out figuring out why your program stopped working due to some obscure problem with the caching mechanism, is alot more than the time you save by doing the caching. at least for a lot of people. for others it might make sense

[ Parent | on HN ]

Re:Ccache – a fast C/C++ compiler cache by tarranoth on Thursday November 24, 2022 @03:16PM (#33735736)

I think you are basically describing why people want modules to be implemented.

[ Parent | on HN ]

Re:Ccache – a fast C/C++ compiler cache by goombacloud on Thursday November 24, 2022 @03:47PM (#33736044)

I think the hard part is to know when caching is not allowed, and for that the compiler is a good point to manage such a cache because it could add metadata such as compiler version (maybe even patches?), compiler flags etc which a wrapper may miss. This disintegration of ccache and the compiler makes me not really trust it because these two could easily get out of sync and you would not easily notice when/why the result is wrong.

[ Parent | on HN ]

Re:Ccache – a fast C/C++ compiler cache by jansvoboda11 on Friday November 25, 2022 @11:24AM (#33743880)

You might be interested in this: https://discourse.llvm.org/t/rfc-add-an-llvm-cas-library-and...

[ Parent | on HN ]