Multi Component cabal support #409
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wz1000
force-pushed
the
wip/multi-component
branch
3 times, most recently
from
47da04a
to
b414480
Compare
wz1000
force-pushed
the
wip/multi-component
branch
2 times, most recently
from
9c78985
to
c86bc3b
Compare
new versions of cabal-install (>= 3.11) have support for starting multi-component repls which allow us to correctly load multiple components, cruicially including the correct transitive closure of all the components we need for correct HLS support. This works by passing multiple targets to `cabal repl`, i.e. `cabal repl target1 target2 ...` In order to do this, we must know all the previous targets we have loaded, so `runCradle` gets an extra `[FilePath]` argument so that this can be supplied. This is the only externally visible API change in this patch. `hie-bios` sometimes passes raw `FilePath`s as targets, and sometimes actual component names (lib:foo, test:foo, exe:bar ...) The latter happes when we have user configuration in the hie.yaml explicitly specifying component names. As downstream users of hie-bios have no concept of "component names", they only know about files which caused a particular component to be loaded, we must handle mapping back from `FilePath`s when starting a multi-component session. It was not easy to do this with the way the code previously work with multi-cradles and `getCradle` and `multiAction` being mutually recursive. So now we uniformly treat everything as a multi-cradle of sorts, resolving the configuration tree from hie.yaml (which I took care not to change) into a list of `ResolvedCradle`s ordered by prefixes, which can easily be consulted by the cabal multi-component cradle to map `FilePath`s back to component names when needed.
wz1000
force-pushed
the
wip/multi-component
branch
from
c86bc3b
to
6f4551d
Compare
8 tasks
wz1000
force-pushed
the
wip/multi-component
branch
from
75227d7
to
9ddbddc
Compare
fendor
approved these changes
Aug 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Support for cabal multi-component
new versions of cabal-install (>= 3.11) have support for starting
multi-component repls which allow us to correctly load multiple components,
cruicially including the correct transitive closure of all the components we
need for correct HLS support.
This works by passing multiple targets to
cabal repl, i.e.cabal repl target1 target2 ...In order to do this, we must know all the previous targets we have loaded,
so
runCradlegets an extra[FilePath]argument so that this can be supplied.This is the only externally visible API change in this patch.
hie-biossometimes passes rawFilePaths as targets, and sometimesactual component names (lib:foo, test:foo, exe:bar ...)
The latter happes when we have user configuration in the hie.yaml explicitly
specifying component names.
As downstream users of hie-bios have no concept of "component names", they
only know about files which caused a particular component to be loaded, we
must handle mapping back from
FilePaths when starting a multi-component session.It was not easy to do this with the way the code previously work with multi-cradles
and
getCradleandmultiActionbeing mutually recursive.So now we uniformly treat everything as a multi-cradle of sorts, resolving the
configuration tree from hie.yaml (which I took care not to change) into a
list of
ResolvedCradles ordered by prefixes, which can easily be consultedby the cabal multi-component cradle to map
FilePaths back to componentnames when needed.