I’m trying to do some project analysis using HIE files, and currently I’m a bit stuck because Cabal states that all executables have modules in the main
unit. This means that in practice I end up with a whole bunch of stuff being a dependency of main:Main
, when in reality I have multiple Main
modules in distinct units. Is there a way to convince Cabal to use a fresh unit ID for each executable?
1 Like
I found this commit which seems to talk about passing -this-unit-id
for executables - is this perhaps what I need?
haskell:master
← mpickering:wip/no-configure
opened 04:53PM - 02 Feb 23 UTC
There are several parts to this patch which are logically distinct but work toge… ther to support the overal goal of starting a GHCi session with multiple packages loaded at once.
1. When a user writes "cabal repl <target>" then if the user is using a compiler > ghc-9.4.* then we will attempt to start a multi-session which loads the selected targets into one multi-package session of GHC. 1a. The closure property states that in order to load components `p` and `q` into
the same session that if `p` depends on `z` and `z` depends on `q`
then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
`z` exists then it is already made into an inplace package by
cabal). Therefore cabal has already engineered that there is source
code locally available for all packages which we will want to load
into a session.
2. It is necessary to modify `./Setup configure` to allow users to configure a package *without* having previously built the dependency. Instead, we promise to the configure phase that we will have built it by the time we build the package. This allows us to configure all the packages we intend to load into the repl without building any dependenices which we will load in the same session, because the promise is satisifed due to loading the package and it's dependency into one multi-session which ensures the dependency is built before it is needed.
A user of ./Setup configure specifies a promised dependency by prepending a "+" to a normal dependency specification. For example:
```
'--dependency=+cabal-install-solver=cabal-install-solver-3.9.0.0-inplace'
```
2a. The `./Setup repl` command is modified to allow a user to defer
starting the repl and instead instruct the command to write the
necessary build flags to a file. The option is called
`--repl-multi-file <FILEPATH>`.
`cabal-install` then invokes this command for each component which
will populate the session and starts a multi-session with all the
arguments together.
3. The solver is unmodified, the solver is given the repl targets and creates a build plan as before. After the solver is completed then in `setRootTargets` and `pruneInstallPlan` we modify the install plan to enforce the closure property and mark which dependencies need to be promised.
* Mark the current components as `BuildInPlaceOnly InMemory`, which indicates to the compiler that it is to be built in a GHC multi-session.
* Augment the component repl targets to indicate that components required by the closure property (in addition to normal targets) will be loaded into the repl.
* Modify the dependency edges in `compLibDependencies` to indicate which dependencies are the promised ones (which is precisely components which are `BuildInPlaceOnly InMemory` build styles). This is the field which is eventually used to populate the `--dependency` argument to `./Setup configure`.
---
Please include the following checklist in your PR:
* [ ] Patches conform to the [coding conventions](https://github.com/haskell/cabal/blob/master/CONTRIBUTING.md#conventions).
* [ ] Any changes that could be relevant to users [have been recorded in the changelog](https://github.com/haskell/cabal/blob/master/CONTRIBUTING.md#changelog).
* [ ] The documentation has been updated, if necessary.
Please also shortly describe how you tested your change. Bonus points for added tests!
Woohoo easy solution - just build master
! All works perfectly now, thank you @mpickering , assuming the linked commit is the one I needed!
1 Like
Yes, cabal-install
will now provide unit-ids for all the components it builds (including executables, testsuites and foreign librarys). Happy hacking!
6 Likes