Add GHC Unit ID store to cabal path output

[sgillespie]

This addds the GHC Project Unit ID store path to the cabal path output as "project-unit-id". The GHC "Project Unit ID" store path has been used in cabal-install since 3.12.1.0.

Example output:

compiler-flavour: ghc
compiler-id: ghc-9.10.1
compiler-path: /nix/store/367sp8xqvk70a050fm6f8a93lig0gx41-ghc-9.10.1/bin/ghc
compiler-store-path: /home/sgillespie/.local/state/cabal/store/ghc-9.10.1-be9a
cache-home: /home/sgillespie/.cache/cabal
remote-repo-cache: /home/sgillespie/.cache/cabal/packages
logs-dir: /home/sgillespie/.cache/cabal/logs
store-dir: /home/sgillespie/.local/state/cabal/store
config-file: /home/sgillespie/.config/cabal/config
installdir: /home/sgillespie/.local/bin

Note that the new value is "project-unit-id", although I'm not 100% this makes sense. Let me know if there's a better name.

EDIT: Changed name to "compiler-store-path"

---

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• 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!)

[fendor]

The value of project-unit-id looks to me like the store dir that is actually used for this particular project. So perhaps, project-store-dir or compiler-store-dir is more fitting?

[fendor]

Also, perhaps we want to print the compiler paired with its abi hash as well?

[sgillespie]

Also, perhaps we want to print the compiler paired with its abi hash as well?

Say, something like this?

compiler-abi-hash: ghc-9.10.1-b7a5c6aad95a5a3e4903ce2272ab85e0

[fendor]

exactly! Then the field compiler-store-path would be strictly speaking redundant, but that's fine, imo.

[sgillespie]

exactly! Then the field compiler-store-path would be strictly speaking redundant, but that's fine, imo.

Wait, am I doing abi-hash, as in ghc --abi-hash, or the abi-tag, as in Distribution.Compiler.AbiTag? If it is the hash, I can't seem to find an straightforward way to get that, what should my strategy be?

[fendor]

Ah, slight misunderstanding! I think adding the output of ghc --abi-hash is not necessary, as we provide the ghc executable path, and it is only one quick invocation of ghc away to get ghc --abi-hash.

Assuming /home/sgillespie/.local/state/cabal/store/ghc-9.10.1-be9a, I was referring to be9a, but if that's tricky right now to get out, I'd be fine with current change.

[ulysses4ever]

This is a small patch so it'd be a good addition to 3.16.1.0 but there's no reviews :-(

[fendor]

Could we add a test to cabal-testsuite/PackageTests/Path/Compiler/cabal.test.hs, roughly like:

void $ cabal "path" ["-z", "--store-dir", "fake-dir", "--compiler-info"]

As the output compiler-store-path should be affected by explicit configuration, iirc?

Perhaps it should even be a test in cabal-testsuite/PackageTests/Path/Config/cabal.test.hs, but I think it might be slightly more tricky to come up with a good test.

Otherwise, I think this is a good addition and Ill approve the PR, once the test has been added.