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.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).