Can Cabal generate distinct unit-ids for executables?

ocharles · December 8, 2023, 9:48am

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?

ocharles · December 8, 2023, 9:50am

I found this commit which seems to talk about passing -this-unit-id for executables - is this perhaps what I need?

github.com/haskell/cabal

Add support for loading multiple components into one repl session

haskell:master ← mpickering:wip/no-configure

opened 04:53PM - 02 Feb 23 UTC

mpickering

+1663 -377

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!

ocharles · December 8, 2023, 10:30am

Woohoo easy solution - just build master! All works perfectly now, thank you @mpickering, assuming the linked commit is the one I needed!

mpickering · December 8, 2023, 11:38am

Yes, cabal-install will now provide unit-ids for all the components it builds (including executables, testsuites and foreign librarys). Happy hacking!