Comment by evmar
12 hours ago
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.
12 hours ago
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.
Define “fixing.” If you’re building on ephemeral containers, an external cache is necessary for files that don’t change.
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.
I see, I might be confused by the terminology. "clobber" to me suggests intentionally trying to throw away cached results (clobbering what you have), but it sounds like you might just use it to mean builds where you don't have any existing build state already present.
What even is a 'clobber build'?
Sorry for being unclear. I'm using Firefox build system lingo without explanations. It's from the command `./mach clobber`, which is similar but not the same as `make clean`. I use 'clobber build' as "a build with no existing build state" and the qualifiers "cold" and "warm" to indicate if cache is empty or filled.
Ah ok, thanks