cabal new-configure --disable-optimization has no effect if ghc-options in cabal file contain optimization flag

[arybczak]

As in the title. cabal new-configure --disable-optimization doesn't actually disable optimization if ghc-options in the cabal file have e.g. -O2. This works with the old cabal configure.

[23Skidoo]

Interesting, I had no idea that it worked that way, but makes sense to support this. There should be a warning as well about ignored ghc-options.

[lexi-lambda]

I bumped into this today, too. I put

package my-package
  optimization: 0

in my cabal.project.local file, but building was incredibly slow! I ran cabal new-build -v, and sure enough, ghc was being invoked with -O2 from a setting in the .cabal file, and it wasn’t being overridden by my local configuration.

Fortunately, ghc-options: -O0 seems to work fine as a workaround.

[phadej]

We should have proper design here, which may require changes to .cabal format.

Maintainers should not put blunt ghc-options: -O2 flags into their .cabal file. regex-tdfa is improved in 1.3.1.0, I guess there are aeson, statistics, math-functions with harcoded -O2 which are common in install plans.

I'm quite sure that for aeson it doesn't improve anything. statistics and math-functions are trickier, because there I can believe that -O2 might actually matter (otoh, maybe it doesn't either).

I think we should have more declarative way to express "user said no-optimisations, we should not force -O2 on them", but also "in default (optimizations on) mode, we actually want -O2 for ghc", that might look like

-- we actually benefit from extra work done by -O2 stuff
default-optimization: 2
if optimization
  -- and we benefit from exposing everything, it actually matters in our overpolymorphic code
  ghc-options: -fexpose-all-unfoldings

Similarly, we might want have switches for profiling, --enable-debug, and others.

Then, all will benefit, also stack with its --fast mode.

---

Yet, to repeat, I think first step is to try to convince maintainers not to use ghc-options: -02, but if it actually matters, guide their users that for production builds they might want to

package the-package
  optimization: 2
  ghc-options: -fexpose-all-unfoldings

etc. And I hope that other tools (i.e. not only cabal-install) would support such granular changes. stack could support that already on snapshot level. It will still benefit their --fast mode.