[Fix #11850] Build dependencies of build tool on disk too

[Saizan]

This PR fixes #11850 by taking the simple approach of ensuring the build tool can be properly built.

Checklist:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

QA Notes

Calling cabal repl --enable-multi-repl exe:bar foo when foo has a build-tool-depends on exe:bar from the same project should build bar as an executable first, and also include it in the interactive session.

[Mikolaj]

Thank you for the PR. Please mention the issue it fixes in the PR descriptions and please mark the PR with review_needed label once ready.

[Mikolaj]

Oh, and please add the changelog snippet.

[Saizan]

@Mikolaj should be all there now, let me know if the changelog needs editing.

[Mikolaj]

The changelog is perfect, thank you.

What can go wrong? Does this impair performance in some scenarios? Can the location that is used for the build be read-only? Anything else?

[Saizan]

• The build of the tool can still fail for unrelated reasons (which is why it would be useful to have something like a "keep-going" switch that HLS could use to still have a session to load even if some things will fail/use a stale tool)
• We do build some dependencies on disk which we also load at the repl, so extra time is spent doing that, but I don't see a way around it. Will not impact resource usage of the repl itself though.

Can the location that is used for the build be read-only?

Like the subdirectory for the unit under $builddir ? I suppose so once the build is done, but will need writing once cabal realizes it's stale and needs building again. Does Cabal make such dirs read-only?

• Another concern will be to keep it so the repl doesn't pick up on the built on-disk version of the library, otherwise the repl won't be the same.

[fendor]

This PR would be great to get merged into cabal asap as it will considerably improve HLS behaviour for loading multiple components at once.

There is still potential for more improvements, as suggested in #11850, but this is a good start.

[fendor]

I confirmed manually that this patch allows us to run cabal repl --enable-multi-repl all on the HLS codebase which used to fail with cabal-3.16 series.

[Mikolaj]

Thank you. Please set the merge_me label.

[fendor]

LGTM, I reviewed the changes and they all make sense to me. There is some remaining risk since I am not sure I understand the consequences entirely.

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-08-31 08:07 UTC · Rule: default · triggered by rule Put pull requests in the rebase+merge queue
• ✅ Checks passed · on draft merge queue: checking #12084 on master (5969ad6) #12302
• ✅ Merged — 2026-08-31 10:15 UTC · at c213e1e9ae56fbde8c361fef583e9c3a56d5b253 · merge

This pull request spent 2 hours 7 minutes 8 seconds in the queue, including 1 hour 56 minutes 31 seconds running CI.

Required conditions to merge

• #review-threads-unresolved = 0 [🛡 GitHub branch protection]
  • [Fix #11850] Build dependencies of build tool on disk too #12084
• github-review-approved [🛡 GitHub branch protection]
  • [Fix #11850] Build dependencies of build tool on disk too #12084
• any of [🛡 GitHub branch protection]:
  • check-success = Doctest Cabal
  • check-neutral = Doctest Cabal
  • check-skipped = Doctest Cabal
• any of [🛡 GitHub branch protection]:
  • check-success = Meta checks
  • check-neutral = Meta checks
  • check-skipped = Meta checks
• any of [🛡 GitHub branch protection]:
  • check-success = docs/readthedocs.org:cabal
  • check-neutral = docs/readthedocs.org:cabal
  • check-skipped = docs/readthedocs.org:cabal
• any of [🛡 GitHub branch protection]:
  • check-success = Validate post job
  • check-neutral = Validate post job
  • check-skipped = Validate post job
• any of [🛡 GitHub branch protection]:
  • check-success = fourmolu
  • check-neutral = fourmolu
  • check-skipped = fourmolu
• any of [🛡 GitHub branch protection]:
  • check-success = hlint
  • check-neutral = hlint
  • check-skipped = hlint
• any of [🛡 GitHub branch protection]:
  • check-success = Bootstrap post job
  • check-neutral = Bootstrap post job
  • check-skipped = Bootstrap post job
• any of [🛡 GitHub branch protection]:
  • check-success = whitespace
  • check-neutral = whitespace
  • check-skipped = whitespace
• any of [🛡 GitHub branch protection]:
  • check-success = Check sdist post job
  • check-neutral = Check sdist post job
  • check-skipped = Check sdist post job
• any of [🛡 GitHub branch protection]:
  • check-success = Changelogs
  • check-neutral = Changelogs
  • check-skipped = Changelogs

[ffaf1]

[x] Manual QA notes have been included.

They were not. @Saizan could you please add them?

[Mikolaj]

Full disclosure: I marked the AI comments "Resolved" to unblock Mergify, but maybe @Saizan you wanted to answer them? No pressure for a bot-generated text, obviously. Or did you read them and the don't make sense?

[Saizan]

[x] Manual QA notes have been included.

They were not. @Saizan could you please add them?

@ffaf1 done, for some reason I thought they were needed only for breaking cli changes.

[Saizan]

Full disclosure: I marked the AI comments "Resolved" to unblock Mergify, but maybe @Saizan you wanted to answer them? No pressure for a bot-generated text, obviously. Or did you read them and the don't make sense?

@Mikolaj the comments seem sensible actually, haven't had the time yet and they are not major problems I think. I guess I can open a follow-up PR?

[ffaf1]

@Saizan Yesterday this PR popped up in cabal-dev meeting. We tried to brainstorm what could go wrong with it.

A question: what happens if we have no write access to disk? What would happen then?

(Apologies for asking questions after the PR was merged, I am trying to decide whether this can go into 3.18.2.0.)