I should really know this by now, but I don't. I'm often working on a Cabal-based package and have just run a successful cabal build
. Now I want to try some things out in GHCi. If I run cabal repl
, then GHC recompiles the whole package into bytecode and runs it in the interpreter. Not what I want at all! If I were just running GHCi directly, I'd use something like -O -fobject-code
, but that won't give me the package context. I just want "Give me a repl with the package as it's been compiled, compiling additional things only as necessary." How do I do it?
GHCi will discover which modules are required, directly or indirectly, by the topmost module, and load them all in dependency order. If you started up GHCi from the command line then GHCi's current directory is the same as the current directory of the shell from which it was started.
If you don't need a fully partitioned GHC environment and are happy with the installed versions on DICE, cabal might be the simplest way to install the Haskell packages you require. By default stack installs packages to ~/. cabal and ~/. ghc in your home directory.
stack ghci allows you to load components and files of your project into ghci . It uses the same TARGET syntax as stack build , and can also take options like --test , --bench , and --flag . Similarly to stack build , the default is to load up ghci with all libraries and executables in the project.
I don't know the right way, but I do know a workaround that can sometimes be useful. If the thing you care about is a library component, you can ask for a repl for an executable component.
I believe --repl-options -fobject-code
kind of does what you want:
cabal repl --repl-options -fobject-code --repl-options -O --builddir dist-repl
This will give you incremental building of compiled code as you work in GHCi. Caveats:
dist-repl
is an alternative directory for the -fobject-code
build objects. As of cabal 3.6.2.0 at least, trying to reuse the regular output from cabal build
leads to some unnecessary rebuilds and other strange behaviour, as reported at cabal issue #3565. That being so, it's better to compromise and use --builddir
to keep a separate set of build objects. Note that cabal clean
accepts the --builddir
option just fine.
Setting the optimisation level explicitly is necessary, as otherwise the default -O0
from cabal repl
will override your package setting.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With