Relocatable build tree

[LaurentRDC]

Describe the feature request

I often spin up a new worktree, branched off of some main branch, to work on a feature. The process I go through is:

$ # From master
$ git worktree add ../my-feature
$ cd ../my-feature
$ cabal build all

Then I can start to work.

In principle, I should be able to use the build artifacts from my main branch to avoid recompiling on my feature branch. Imagine this workflow:

$ # From master
$ git worktree add ../my-feature
$ # New: copy build artifacts
$ cp -R ./dist-newstyle ../my-feature
$ cd ../my-feature
$ cabal build all

Unfortunately, this results in a full rebuild, implying that the build artifacts in dist-newstyle aren't portable across directories. I'm not sure if this is a happenstance, or a design constraint.

Additional context

The cost of spinning up worktrees can be be substantial. Industrial codebases can take multiple minutes to compile local packages. There's a potential to save on rebuilds by copying build artifacts

[LaurentRDC]

I'm happy to work on addressing this if the maintainers think this is worthwhile

[ulysses4ever]

By all means. On top of the arguments mentioned, I will note that some of the new agentic workflows utilize worktrees heavily.

[LaurentRDC]

Something to be mindful of: plan.json both contains absolute paths, AND is consumed by other projects such as cabal-plan. So whatever the resolution is, it needs to not break anyone's code by default

[LaurentRDC]

@ulysses4ever There's a good chance that this needs to be opt-in.

Cabal has this --relocatable flag which is apparently nebulous. Are you OK if I re-purpose this flag?

[fishtreesugar]

might related to #5582

[TeofilC]

This is definitely worth fixing IMO, but until then, it might be possible to work around this by using Docker (or VMs, etc) and always bind mounting the folder to the same path in the container (and/or using overlayfs). Perhaps you'd want to use git clone --reference rather than worktrees in that case though

[LaurentRDC]

might related to #5582

Thanks for pointing it out. I would say that "relocatable build artifacts" is really a small, stop-gap measure on the way to tooling greatness, whereas #5582 is a wider, more useful change