ulidtko / cabal-doctest

A Setup.hs shim for running doctests
https://hackage.haskell.org/package/cabal-doctest
BSD 3-Clause "New" or "Revised" License
31 stars 24 forks source link

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

Open sgraf812 opened 4 years ago

sgraf812 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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