Make the paths stored in precompiled-cache Stack-root relative

[da-x]

Because these paths always point inside the Stack root, better make them relative to the Stack root, making the Stack root more easily relocatable, in the future.

This change is backward-compatible.

[mgsloan]

Makes sense! Stack roots probably aren't going to be relocatable any time very soon though, unfortunately, cabal package build results have absolute paths.

This is a good change anyway, though. In the future this stuff could be relocatable, and this will save some bytes in the precompiled cache.

[da-x]

Apart from this, we have the Cabal conf files that you mentioned, the GHC pkgdb, some shell wrappers and RPATH in DSOs. All of these are easier and known formats that are easy to deal with. Only the precompiled-cache is very much Stack-specific.

BTW, I'm working on a 'stack relocate' command. I'm designing it to be used under rpmbuild mock chroot. @juhp

[mgsloan]

That's awesome! I'd love to be able to copy build directories for #1634 , but I'm not sure how this would get around binary dependencies on the Paths_* module (getDataFile). Still handy for those packages that don't depend on it.

See these stack issues on relocatable data files: #1262 #848

(compiled in absolute path dependencies on these data files is the issue)

Considerations that only apply to relocatable-work-dir not relocatable-root: Since stack causes .ddump-hi files to be generated, I think it actually would be theoretically feasible to remove all object files that have a dependency on the Paths_ module. Bonus points would also be to delete executables that have a dep on a Paths_ module. Rather tricky to trace back from obj file -> cabal component invalidation, though.

[da-x]

There's a partially working for binaries that assumes that the path you are relocating to is shorter or of the same length, and that there are no checksums or signatures. This is mostly the case in build servers, which tend to build under paths that are quite long, e.g. /build/rpmbuild/[sometimes-long-rpm-package-name-plus-version/build-root/..., verifiably longer than the usual install destination /usr. The trick is to assume null termination of the strings, pad the right side with zero characters, and do binary replacement inside the generated files. It's a bit nasty, though.

[mgsloan]

That's rather clever! Better hope some machine code doesn't magically resemble a filepath! :D

[da-x]

The package.cache file proved stubborn with the zero padding, but I've realized that for the UNIX case I can pad the beginning of the path with /, since /////usr is as valid a path as /usr. So now stack relocate works (implementation).