GHC incorrectly concludes rebuild unnecessary, even when ghc-options have changed

[edsko]

Steps:

1. Compile your program (using new-build). Realize it has a space leak.
2. Change cabal.project to:

package ingest
  ghc-options: -fno-full-laziness

1. Call new-build again:

# cabal new-build
In order, the following will be built (use -v for more details):
 - ingest-0.1.0.0 (lib) --enable-profiling (configuration changed)
 - ingest-0.1.0.0 (exe:ingest) --enable-profiling (configuration changed)
Configuring component lib from ingest-0.1.0.0
Preprocessing library ingest-0.1.0.0...
Configuring component exe:ingest from ingest-0.1.0.0
Preprocessing executable 'ingest' for ingest-0.1.0.0...

Note that although it detected "configuration changed", nothing actually got recompiled. The change only takes effect after I manually delete the dist-newstyle directory and rebuild again.

[ezyang]

Judging from the log output, it is likely we are invoking GHC, but GHC does not consider that recompilation is necessary. So technically this is an upstream bug. But that's not an excuse, we should do something here.

[edsko]

FWIW, with the traditional build this works just fine (and I use that all the time when debugging low level issues).

[ezyang]

OK, well, never mind then!

[edsko]

Hmmm, it seems I was wrong about ti working with traditional build. Not sure why I concluded that. It doesn't work with traditional build either :) Apologies.

[ezyang]

OK relabeled ;)

[phadej]

• 17:29 dcoutts phadej: ok, so what we discussed previously with hvr and others was that we need a distinction between options to programs that affect the outcomes (and so must be included in the hashes), and options that do not like logging verbosity, or RTS opts
• 17:35 dcoutts phadej: you'll see there's the existing program options which gets included into the elaborated package config, and into the package id hashes
• 17:35 dcoutts we'd want a separate set of options that live in the BuildSettings
• 17:36 dcoutts the BuildSettings is for things like -v -j etc that do not affect the outcome of the build
• 17:36 dcoutts so we'd keep a set of program options in there, so they don't get tracked as part of config
• 17:37 dcoutts and combine the two when invoking Setup.hs to build stuff
• 17:38 dcoutts and of course need a new name scheme for the CLI
• 17:38 dcoutts --${prog}-options vs ?
• 17:38 dcoutts phadej: and while you're at it, if you can make the prog options only apply to the local packages, like all other options, that'd be a very useful bug fix
• 17:39 dcoutts it's really annoying at the moment that --ghc-options accidentally applies to all deps
• 17:39 phadej it is
• 17:39 phadej I'll copy paste this log i

nto memo, and refine it into issue later today/tomorrow

[phadej]

E.g. atm it triggers the rebuild, but a bit too big one...

[ezyang]

@phadej, the conversation you pasted in this ticket is not relevant to the original issue of the ticket (which is a GHC bug.) Maybe a different ticket should be opened?

[phadej]

@ezyang it related to #3883, there cabal rebuild everything even not necessary, and here's the opposite.

[jneira]

This has been resolved by #7973, thanks all!

[jneira]

I misunderstood the linked pr which not affected the caching of ghc-options only made them be applied to local packages
sorry for the noise!