Add cabal build -O0 mode

[mightybyte]

Build times become a significant issue for larger Haskell projects. I frequently find myself encountering the following situation:

I build normally because I want to actually run my program and I want/need optimizations turned on. It spends 7 minutes building and it gets say 190 out of 200 modules built, then encounters an error. I start working on fixing these errors, but now I want to build in -O0 mode until I get them fixed because -O0 is MUCH faster and takes more like 1 minute. Once they are fixed I switch back to normal mode, but in the current system I will have to waste another 7 minutes rebuilding the 175 modules that built successfully the first time because all the build outputs were overwritten when I switched to -O0 mode.

I propose the addition of a "cabal build -O0" mode that has .o, .hi, and executable outputs, that are completely separate from a normal build's outputs. When you do "cabal configure", it should change the configured options for both -O0 and normal modes.

This feature is related to issue #1179 which adds a "cabal build --check" option that just does type checking. Ultimately I think we should have all three modes (--check, -O0, and normal) and they should have independent sets of outputs (although --check doesn't have as many outputs) so the user can conveniently switch between them without losing work done in the others.

[ttuegel]

The only way this seems to differ from #1179 is keeping the generated code. Can you explain why you want to keep the code generated with -O0 around? Otherwise, -fno-code will be faster (just no .o).

[mightybyte]

@ttuegel It differs from #1179 in that -O0 does generate an executable, but -fno-code doesn't. There are situations where you want the generated executable, but don't need optimizations. There are also situations where you need the optimizations though.

[andreasabel]

In v1-cabal, the OP can be easily realized with setting different --builddirs for different optimization levels. We do this in Agda development (would not survive without means to do quick compilation.)

In v2-cabal, I am not sure this works, since v2-cabal seems to want to rebuild all the dependencies when --ghc-options change.

[andreasabel]

There is cabal v2-build -O0 now (#7368 (comment)), so maybe this issue can be closed as fixed?

[andreasabel]

@Mikolaj: This issue can be closed.

[Mikolaj]

Agreed. Apart of cabal v2-build --disable-optimization, cabal now also keeps the old build results in paths that mention optimization level, so they should be reused in the use case mentioned in the ticket description.