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 FilePaths 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 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 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 ResolvedCradles ordered by prefixes, which can easily be consulted
by the cabal multi-component cradle to map FilePaths back to component
names when needed.
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
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 rawFilePath
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
andmultiAction
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 mapFilePath
s back to component names when needed.