Re: FW: GHC API: Problems with implementing ":reload" for "ghc --make"
Hi Brian, Sorry for the delayed response.
My goal is to write a program GhcRemake that works like "ghc --make." However, instead of terminating after compilation is done, I want the program to stay open and wait for me to hit <ENTER>. When I hit <ENTER>, GhcRemake rebuilds the project, just as if I had called "ghc --make" again with the same arguments. The benefit of such a program is that GhcRemake should be able to cache a lot of data in memory between invocations and hopefully be able to do the subsequent re-makes much faster.
Nice idea!
My program seems to work fine when run on itself and when run on Cabal. But, these two packages seem to be too small to notice any reduction of building time. So, I decided to test my program by building the GHC API with it. Unfortunately, it seems like every build after the first one in the session does the dependency analysis badly, and things get recompiled unnecessarily.
It looks like the problem is caused by recursive module imports. I've added a bug (#1027) with a smaller example of it. Thanks Ian
On 11/24/06, Ian Lynagh
However, instead of terminating after compilation is done, I want the program to stay open and wait for me to hit <ENTER>.
<snip>
building the GHC API with it. Unfortunately, it seems like every build
after the first one in the session does the dependency analysis badly, and things get recompiled unnecessarily.
It looks like the problem is caused by recursive module imports. I've added a bug (#1027) with a smaller example of it.
Thanks. That was my suspicion as well. I currently have this utility on the back burner while I am working on a different project. I had previously filed issue 934 which is related to this issue. However, the workaround I offered in 934 resulted in my program having poorer-than-expected performance--with my patch applied, issuing two GHC.load's in the same session was not significantly faster than it was without the patch applied. Subsequently (and for other reasons than just performance), I started to investigate a way to split up the pipeline into separate requests: x <- parseAndRename session y <- typecheck session z <- compileBytecodes session z' <- compileViaC session However, I got discouraged from doing this because of the way errors are handled in the renamer: when the renamer detects an error, it is likely to stop without doing the rest of the renaming. However, I need the opposite behavior: do as much renaming as possible, then return any naming errors, then typecheck and return any type errors. This is the behavior an (fully automatic) etags generator would want, which is more-or-less what I was and will be building. But, it is not appropriate behavior for a the compiler itself, so perhaps it is better to not use the GHC API for this program. - Brian
Ian Lynagh wrote:
Hi Brian,
Sorry for the delayed response.
My goal is to write a program GhcRemake that works like "ghc --make." However, instead of terminating after compilation is done, I want the program to stay open and wait for me to hit <ENTER>. When I hit <ENTER>, GhcRemake rebuilds the project, just as if I had called "ghc --make" again with the same arguments. The benefit of such a program is that GhcRemake should be able to cache a lot of data in memory between invocations and hopefully be able to do the subsequent re-makes much faster.
Nice idea!
BTW, when I get around to addressing #276 http://hackage.haskell.org/trac/ghc/ticket/276 then you'll be able to compile to object code inside GHCi, so to do you what you want above you would just fire up GHCi and type :r to recompile each time. GHCi will cache the interface files between recompilations. Cheers, Simon
participants (3)
-
Brian Smith -
Ian Lynagh -
Simon Marlow