This is unfortunate and I don't like freeze files, as relying on them tends to
batch up major package version changes. But it seems that we are going to need
one in order to work properly with github caching.
Without a freeze file to incorporate into the cache hash, we very quickly
"successfully" load caches that refer to an older set of packages, which will
cause a full (or mostly full) rebuild by cabal. By incorporating the freeze file
and submodule hashes into the cache file name, we get a regenerated cache
whenever we need.
Unfortunately, this means that we won't ever be able to load a slightly out of
date cache and build on top of it, so any submodule update or freeze file update
will generate a totally fresh cache.
This is unfortunate and I don't like freeze files, as relying on them tends to batch up major package version changes. But it seems that we are going to need one in order to work properly with github caching.
Without a freeze file to incorporate into the cache hash, we very quickly "successfully" load caches that refer to an older set of packages, which will cause a full (or mostly full) rebuild by cabal. By incorporating the freeze file and submodule hashes into the cache file name, we get a regenerated cache whenever we need.
Unfortunately, this means that we won't ever be able to load a slightly out of date cache and build on top of it, so any submodule update or freeze file update will generate a totally fresh cache.