1

I have a test suite and a benchmark suite that uses the GHC API to compile modules to Core, so that I don't have to write Core 'by hand'.

I'm mostly using stack at this point, where I could just access the GHC_PACKAGE_PATH environment variable in the test suite (stack test) to find a package database which I can feed the GHC API with. Note that it's not so much that I care for any particular db, I just want to have modules from e.g. base available, compiled with a compatible version of GHC (e.g. GHC.Paths.ghc).

Everything works fine so far, tests are green. Now, if I do the same for the benchmark suite (stack bench), GHC_PACKAGE_PATH doesn't seem to be present at all.

Long story short, what is a reliable way to capture the path to the GHC package database the program was built with? I imagine some messing about with Setup.hs might get me where I want to be.

Edit: Here is something to play around with: https://github.com/sgraf812/ghc-package-path

stack test prints out the value of GHC_PACKAGE_PATH, whereas stack bench doesn't. An answer to this question should make it so that a path to some appropriate package database is printed out in either case.

Sebastian Graf
  • 3,602
  • 3
  • 27
  • 38
  • 1
    Thanks for the report, I've opened this issue: https://github.com/commercialhaskell/stack/issues/3462 – mgsloan Sep 30 '17 at 22:22
  • @mgsloan Thanks for fixing this! Nonetheless, I'm interested in a solution that also works for cabal-install. Looking at the code of ghc-mod, there probably isn't really a solution, I think, but I think this situation is really annoying and there should be some kind of package for this (like `ghc-paths`) if there is no standard among the ecosystem. – Sebastian Graf Oct 01 '17 at 07:57
  • @mgsloan So, what would be the best workaround? I dug through the `stack` source code and looked at how `mkGhcPackagePath` is called. seems like I have to get a hold on an `EnvConfig` to call `packageDatabaseLocal` et al. What would be the easiest way to do so? – Sebastian Graf Oct 02 '17 at 09:45
  • Maybe I'm better off just parsing the result of `stack path --ghc-package-path`? – Sebastian Graf Oct 02 '17 at 09:53
  • Yeah, parsing that seems like the best approach. – mgsloan Oct 07 '17 at 05:37

1 Answers1

0

The proper solution appears to be to use a custom Setup.hs to persist the withPackageDB field of the LocalBuildInfo after configure.

Lucky me found cabal-toolkit, of which I modified version 0.0.3 to also work with Cabal 1.24 (and GHC 8.0.2) to be found here until it's merged.

Getting the packageDBFlags/extraPkgConf is just a matter of calling getGHCPackageFlags $(localBuildInfoQ).

Sebastian Graf
  • 3,602
  • 3
  • 27
  • 38