Hadrian: Add ghci target which loads GHC into GHCi
This patch adds a new script hadrian/ghci
which can be used to load GHC into GHCi. It supersedes the utils/ghc-in-ghci
scripts.
There are also other small commits which were needed to fix dynamic linking and other aspects of hadrian. They should each be merged individually.
Old description
The patch works now but we need to cleanup the hacks. The following command loads the whole of GHC into GHCi in about 30 seconds on my very weedy machine.
ghci $(TERM=dumb ./hadrian/build.sh -j dump-args --build-root=_ghci -q) compiler/main/HscMain.hs
-
We have to build shared objects in case the user has a dynamically linked GHCi. However, the only way I could work out how to do this was to change the user setting to enable the dynamic way. This shouldn't be necessary but will probably need a lot of refactoring. Rules for .so
and.dyn_o
files should always be registered and selecting ways should justneed
different files rather than the current implicit way where they are all tied to the.conf
. -
The -rpath
hack that @DavidEichmann suggested looks quite dodgy, but why? It might be right. -
Dynamic objects need to be built with the stage0 compiler. At the moment the name of the .so
is wrong if you enable this so I have hard coded the name into a few places. -
Hacks like this need to be guarded by CPP or re-enabled if they work now. -
Whether -v0
is passed to cabal should be configured by an env var - !509 (diffs) -
Shake seems to output a control sequence to change the tab name even when -q
is passed which is why theTERM=dumb
env var has to be set.