Inplace build profiles, to avoid clobbering old build products when you change some settings

[ezyang]

Here are a number of situations, all with something in common:

1. If you cabal new-build, and then cabal new-repl --ghc-option=-fobject-code, the REPL dumping out object code will clobber the originally built code from new-build
2. If you cabal new-build --disable-optimization, and then decide you do want to build with optimization, changing the flag is insufficient; you have to blow away the old build products. (And there is no way to maintain the unoptimized and optimized build trees simultaneously)
3. If you decide you want to enable some debugging Cabal flag, and then disable it later

In all of these situations, there is some parameter which Cabal knows about, but then when it comes to the actual build products Cabal stuffs them all in the same directory; thus, when one of these flags changes, Cabal blows away the old build products (without considering the possibility they might be useful for later.)

Here's how I think we should solve this: instead of always assigning inplace packages an inplace package ID, we should compute a Nix-style hash for it. We can symlink the inplace directory to the most recently computed hash for a package. The Nix hash should not be complete (e.g. it shouldn't include any sort of hash of the source code); it should just track parameters which (1) the user is likely to want to build their project with under both permutations, and (2) would require most of the package to be rebuilt.

[dcoutts]

Hmm, and how do we limit bloat of built artefacts?

[ezyang]

GC, I suppose. #3333. Alternately, we can do your plan which you detailed on IRC, which is for there to be a limited set of profiles which get separate build trees. (An added benefit is that their paths would be predictable.)

[ezyang]

Here are all the things we want to distinguish inplace builds by:

• pkgHashCompilerId. See also Don't overwrite build artefacts when switching ghc version #3011
• pkgHashPlatform (with the previous, this is $abi)
• pkgHashFlagAssignment? This one actually needs to be user-configurable, because there many different ways flags can be used. If a flag is used to enable a debug build, we want
• pkgHashOptimization (this should include -fno-code mode, although it doesn't)
• pkgHashSplitObjs though arguably this is a corner case

I don't think profiling is necessary as Cabal's build system builds both the non-profiled and profiled versions of code.

The trouble with profiles is it's not altogether obvious how the naming should work. Compiler and platform is easy enough: dist-newstyle/build/$abi/$pkgid/$cname, but then you need a mechanism for generating names for the other types. Maybe we can do dist-newstyle/build/$abi/$pkgid/$cname/$slug where $slug is a concatenation of a set of tokens which identify the rest, e.g. O1-split-fdebug (in some deterministic order.)

[ezyang]

Compiler and platform is in HEAD, optimization is PRed. Maybe won't bother with the rest until we get general build profiles.