Open sgraf812 opened 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.
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?
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).
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 usingcabal-toolkit
before, but I realised I needcabal-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 theBuild_*
module in global-autogen?