3 ms·
> a clean rebuild While I'm less absolutist about the matter than dboreham seems to be, I feel the need to point out that a clean rebuild by definition doesn't
by a1369209993 4y ago
> a clean rebuild
While I'm less absolutist about the matter than dboreham seems to be, I feel the need to point out that a clean rebuild by definition doesn't have anything cached - that's what "clean" means. If the build environment has access to data from a previous build, it's not clean.
It's useful (perhaps because "something's wrong with the tool chain or its users", or perhaps for legitimate reasons) to have a cached build as a intermediate step between a incremental build and a full (and slow) clean rebuild, but it is between.
- yjftsjthsd-h 4y agoI don't think that's quite true. If you can perfectly encapsulate your compile environment and ensure that you explicitly capture all inputs, then you can store cached artifacts by the hash of their inputs and be confident that you will always build the exact same thing. Of course, at that point we're more talking about nix than *cache.
- encryptluks2 4y agoA clean rebuild doesn't mean that it can't used cached objects. If the cache is the same regardless, the final output will be the same.
- lttlrck 4y ago> If the build environment has access to data from a previous build, it's not clean. That strict definition makes using dependencies very hard. Pre-built libraries, npm, ...
- joshuamorton 4y agoWiyh reliable caching schemes you don't need "clean" builds. Bazel and co (used by Google, FB, Twitter, etc) all use distributed build machines w/ caches. The idea that you can't trust your incremental build and so need to discard it occasionally is a deep failure of how most incremental builds are done (mtime) and not a fundamental flaw in caching.