[HN Gopher] Sccache - Shared Compilation Cache
       ___________________________________________________________________
        
       Sccache - Shared Compilation Cache
        
       Author : gjvc
       Score  : 41 points
       Date   : 2022-05-12 18:15 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | meinersbur wrote:
       | My first contribution to a Rust codebase was <https://github.com/
       | mozilla/sccache/commit/da2934fcc2ed2a4ae2...>. It is adding the
       | -fminimize-whitespace flag to the preprocessor command when
       | available (New in Clang 14, <https://releases.llvm.org/14.0.0/too
       | ls/clang/docs/ReleaseNot...>). The equivalent ccache patch is
       | still pending <https://github.com/ccache/ccache/pull/815>.
       | 
       | When using the disk cache, ccache is still faster on cache hits
       | due to also checking the hash of all input files (called a
       | manifest) before even executing the preprocessor. It also can
       | just clone/hardlink the file in the cache instead of copying it.
        
       | dboreham wrote:
       | For me the existence of "build caching" schemes is indicative
       | that something's wrong with the tool chain or its users and that
       | modularity hasn't been properly implemented.
        
         | jonstewart wrote:
         | Have you worked in a compiled language?
        
         | kazinator wrote:
         | While build caching could help mask problems caused by poor
         | modularity, such as the same source file being built multiple
         | times in different subdirectories of a build, rather than just
         | once, that's really not what its for.
         | 
         | It solves the toolchain problem that the toolchain doesn't
         | remember that it's already built something before; if you give
         | it the same inputs, it will compile them every time, taking the
         | same time as before.
         | 
         | Caching lets you do a clean rebuild in a newly spun up
         | environment with a new checkout of the source code, while
         | saving time by re-using pieces that have not changed from
         | another build (not necessarily identical to that one).
         | 
         | Yes, there could be less of a need for caching if incremental
         | builds were rigorously reliable. Every instance of a CI server
         | could then just update the same repository in-place with new
         | commits, and run an incremental build. But caching would still
         | help with that. For instance, if a commit happens to revert a
         | file to a prior state, caching will pick up on that and pull
         | out the prior object file for that.
         | 
         | When you use caching in a private repository where you have
         | reliable incremental builds, you still see an improvement. For
         | instance, when you throw away some experimental code, returning
         | files to a prior state, and run a build, the object files just
         | come blazing out of the cache.
         | 
         | When you do a "git bisect" to find a bug, same thing: the old
         | commits build really fast.
        
         | krimbus wrote:
         | Compilation can be a big overhead on C++ codebases even when
         | there is plenty of care in regards to modularity. Projects that
         | are heavy on templates usually benefit a lot from compile
         | caching mechanisms.
        
       | pianoben wrote:
       | I was a very happy user of sccache - it took some big CI builds
       | from ~10 to 1.5 minutes on average. We had to add an Azure
       | backend to it, but the code is very well-organized and it was
       | pretty easy to hack on.
       | 
       | I don't work in native languages these days, but if I do again
       | I'll definitely reach for this again.
        
       ___________________________________________________________________
       (page generated 2022-05-12 23:01 UTC)