Can you (err... buildcache) cache Rust proc-macros? I've been battling this with sccache and I'm now maintaining a 10-patch deep stack for the next.js build CI.
Windows builds were ridiculously poor on cache hits rates too because of non-determinism that was not able to figure out.
There was an experimental PR that treats proc macros as idempotent with the corresponding colpike speed up. I don't know what happened with it, and stabilization required a lot of design work to not break backcompat. But this is something in the team's radar.
Would it be possible to do somethign like editions for proc macros, or have crates establish "this is a v2 proc macro" or something? There are a lot of things I'd love to see change in a v2 but it'd all be breaking.
Idempotent as in if the token stream in the input doesn't change, the cached result of the previous macro expansion is used during incremental, instead of being pessimistic and rerunning the macro.
I’m not too familiar with Firefox builds. Why are clobber builds common? At first glance it seems weird to add a cache around your build system vs fixing your build system.
Though I'm not actively working with Firefox so can't speak for their use cases, one important use case for clobber builds is CI.
I'm the author of BuildCache, and where I work we make thousands of clobber builds every day in our CI. Caching helps tremendously for keeping build times short.
There are a few use cases for local development too. For instance if you switch between git branches you may have to make near full rebuilds (e.g. in C++ if some header file is touched that gets included by many files).
Another advantage as a local dev is that you can tap into the central CI cache and when you pull the latest trunk and build it, chances are that the CI system has already built that version (e.g. as part of a merge gate) so you will get cache hits.
37 comments
Windows builds were ridiculously poor on cache hits rates too because of non-determinism that was not able to figure out.
I'd be happy to test it out.
https://github.com/rust-lang/rust/pull/145354
Colpike as in compile typo.
I'm the author of BuildCache, and where I work we make thousands of clobber builds every day in our CI. Caching helps tremendously for keeping build times short.
There are a few use cases for local development too. For instance if you switch between git branches you may have to make near full rebuilds (e.g. in C++ if some header file is touched that gets included by many files).
Another advantage as a local dev is that you can tap into the central CI cache and when you pull the latest trunk and build it, chances are that the CI system has already built that version (e.g. as part of a merge gate) so you will get cache hits.
I understand that speed is relevant, but focusing on that strategy does not really work when dinosaur-like extinction is around the corner.