Consider generating Build_* modules for more than just test-suite targets

[sgraf812]

I'm hijacking the purpose of cabal-doctest somewhat by using it to initialise a GHC API session to compile stuff to Core (on which then I run a custom strictness analysis). I've been using cabal-toolkit before, but I realised I need cabal-doctest for my doctests anyway, and using it for my test suite to initialise the GHC API seems to work quite well. The only problem is that I can't use it to compile my benchmarks, because it's not a test-suite.

As I said in #59, this is probably not how you imagined cabal-doctest to be used, but it seems like a waste of maintenance effort to just target doctesting in particular. So maybe just put the Build_* module in global-autogen?

[phadej]

Sorry, but I'm strictly against of promoting build-type: Custom. There should be at least some plan to get rid of cabal-doctest in that use case too^†

^† cabal v2-doctest is on the horizon, and I'm very sloooowly working towards it.

[sgraf812]

That's understandable, but given that you are quite knowledgable in the field: What alternative would you propose for my scenario? I.e. I'm looking for a way to set up a GHC API session that has enough packages installed (base, transformers, containers, array, ...) that I can elaborate and analyse simple nofib benchmarks like kahan.

Should I create a fake cabal project for the proper environment? Is there some shortcut to do so?

[phadej]

If it's standalone thing (like nofib), that I'd recommend using some way (e.g. https://github.com/phadej/cabal-extras#cabal-env / cabal install --lib) to set up a package environment, and then call ghc -package-env=kahan-benchmark-env (I guess that's possible with GHC API too).