Allow --make and --fno-code

[duncan]

Loading a largish project in ghci is roughly twice as fast as using ghc --make (and hugs is roughly 6 times faster than ghci). Presumably the majority of the extra time that ghc --make takes compared to ghci is down to generating object code, though some will be serialising .hi files.

So the feature request is to let us use ghc --make -fno-code. The purpose is to check the code for errors, it would of course write out .hi files so that re-running ghc --make -fno-code only recompiles the changed files, like :reload in ghci.

[simonpj]

Another reason that this would be a Good Feature is that currently if you use -dsuppress-uniques (to get regression-test output that wobbles less), you need -fno-code else the assembler bleats about duplicate labels. But since -fno-code is currently incompatible with --make, that makes -dsuppress-uniques incompatible too, which is a pain.

Simon

[simonmar]

I think it might be just a bug in the front end that the combination is disallowed. The GHC API certainly supports this mode of compilation, and indeed Haddock uses it. However, in this mode we don't currently generate .hi files. That is fairly easy to change, but apparently there's a need for both modes, so perhaps we need a flag.

The main problem with -fno-code is that Template Haskell code cannot be compiled this way, for obvious reasons. Haddock has to go back and compile things to object code if TH is needed (I don't recall how it figures out that it needs to do this, though).

Simon: perhaps -dsuppress-uniques shouldn't apply when generating code?

[duncan]

Replying to simonmar:

The main problem with -fno-code is that Template Haskell code cannot be compiled this way, for obvious reasons. Haddock has to go back and compile things to object code if TH is needed (I don't recall how it figures out that it needs to do this, though).

Does it have to be object code? Could it not compile things to bytecode, either pre-emptively or just in the case of -XTemplateHaskell?

[simonmar]

Replying to duncan:

Does it have to be object code? Could it not compile things to bytecode, either pre-emptively or just in the case of -XTemplateHaskell?

It could, but not everything can be compiled to byte-code: arbitrary unboxed tuples, which I think is why Haddock uses object code.

[simonmar]

Done:

Tue Apr 27 13:28:51 BST 2010  Simon Marlow <marlowsd@gmail.com>
  * --make is now the default (#3515), and -fno-code works with --make (#3783)
  If the command line contains any Haskell source files, then we behave
  as if --make had been given.
  
  The meaning of the -c flag has changed (back): -c now selects one-shot
  compilation, but stops before linking.  However, to retain backwards
  compatibility, -c is still allowed with --make, and means the same as
  --make -no-link.  The -no-link flag has been un-deprecated.
  
  -fno-code is now allowed with --make (#3783); the fact that it was
  disabled before was largely accidental, it seems.  We also had some
  regressions in this area: it seems that -fno-code was causing a .hc
  file to be emitted in certain cases.  I've tidied up the code, there
  was no need for -fno-code to be a "mode" flag, as far as I can tell.
  
  -fno-code does not emit interface files, nor does it do recompilation
  checking, as suggested in #3783.  This would make Haddock emit
  interface files, for example, and I'm fairly sure we don't want to do
  that.  Compiling with -fno-code is pretty quick anyway, perhaps we can
  get away without recompilation checking.