shake killing workspaces when something changes - benclifford/text GitHub Wiki

some tools have a cache dir (.stack-work, or whatever)

those caches are useful when rebuilding.

but sometimes I want to wipe that cache based on something changing in the environment - because I don't trust the tool to have done it right

with stack, -Werror being turned on, or warning flags being changed while -Werror is turned on - this changes the set of programs that build OK.

with stack, --fast being on/off doesn't cause a rebuild. building slow then fast don't care, but building fast then slow, I want the optimised output rather than a partially unoptimised cached version.

with ps build, don't trust it to manage its local cache right - when bower file is changed, want to wipe and rebuild that dir.

so "directory state" file that tracks whether the cache directory/cache state is compatible with the flags we are using.

can we do this in some kind of order rather than value, so that turning on --fast doesn't cause a full rebuild?

a build needing a cache requires its cache. and that cache requires the build options that might affect it. and to create that cache we can do an "rm" (and then eg a stack setup for stack, after the rm)

conceptually the cache is prepared for a particular set of build options (even it is as an empty directory) - and if we need a cache that is prepared for incompatible options, we must prepare a new empty one.

drop "corruption flag" files in - a directory is "optimisation safe" until we build it with "--fast" in which case we drop a corruption flag file into the directory. when we want to build optimised, we check for the non-existence of that corruption flag. flag doesn't even need to go into the cache directory itself - it can go into our .builder directory

That means we aren't checking if the "--fast"-ness has changed... we're checking something slightly different.