Multi component repl #373
Multi component repl #373
Conversation
…eir own .ghci files.
… a separate build dir." This reverts commit 47b0dac.
| -- Compile to object code | ||
| :set -fwrite-interface -fobject-code |
There was a problem hiding this comment.
I’m being a bit opinionated in this file:
- I think we want to be able to quit the repl and relaunch it quickly.
- I think we don’t want it to load all of the code automatically, since we’re working in various projects.
- I think we especially don’t want it to import all of the code automatically.
I think those are fair statements for working on a variety of tasks, but if your particular workflow is made arduous by this, it’s worth revisiting.
| -- Write build products to dist-repl (so that we don’t clobber 'cabal build' outputs) | ||
| :set -outputdir dist-repl/build/x86_64-osx/ghc-8.6.5/semantic-0.8.0.0/build | ||
| :set -odir dist-repl/build/x86_64-osx/ghc-8.6.5/semantic-0.8.0.0/build | ||
| :set -hidir dist-repl/build/x86_64-osx/ghc-8.6.5/semantic-0.8.0.0/build | ||
| :set -stubdir dist-repl/build/x86_64-osx/ghc-8.6.5/semantic-0.8.0.0/build | ||
|
|
||
| -- Look for autogen’d files in dist-repl | ||
| :set -idist-repl/build/x86_64-osx/ghc-8.6.5/semantic-0.8.0.0/build/autogen |
There was a problem hiding this comment.
I figured out that you can convince ghci to build .dyn_o and .dyn_hi files alongside its usual .o and .hi files, and that this is enough to deal with the build errors I was seeing (cf haskell/cabal#6059). However, while this works well enough in fused-effects, it still ends up doing a lot of rebuilding (cf haskell/cabal#3565) in semantic, and the repl builds take longer too due to the added codegen.
Ultimately, I think we’re better off using a separate dist dir for the time being, tho it breaks my very heart.
| -- Bonus: silence “add these modules to your .cabal file” warnings for files we :load | ||
| :set -Wno-missing-home-modules |
There was a problem hiding this comment.
This one hits you for every :loaded file if you don’t turn it off.
|
Are we supposed to be able to see the packages/modules defined in |
Not sure what you mean? It doesn’t load them by default (because there’s no good way to anticipate what all you’ll need, there may be module name collisions in e.g. the tests, and you probably don’t want everything in scope), so you still need to |
|
@patrickt: I addressed your suggestions & also rewrote the relevant section of 💡ProTip!.md, so this is now ready for another glance, modulo #373 (comment). |
This PR adds
script/repl, which loads everything aghcisession with access to all of the packages’ sources, making it much easier to test stuff out without having to constantly quit & reload &c.