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.
The proper solution appears to be to use a custom
Setup.hsto persist thewithPackageDBfield of theLocalBuildInfoafterconfigure.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/extraPkgConfis just a matter of callinggetGHCPackageFlags $(localBuildInfoQ).