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

haskell / cabal

Official upstream development repository for Cabal and cabal-install

https://haskell.org/cabal

Other

1.63k stars 697 forks source link

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

Open edsko opened 8 years ago

edsko commented 8 years ago

Steps:

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

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

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 commented 8 years ago

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 commented 8 years ago

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

ezyang commented 8 years ago

OK, well, never mind then!

edsko commented 8 years ago

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 commented 8 years ago

OK relabeled ;)

phadej commented 8 years ago

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 commented 8 years ago

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

ezyang commented 8 years ago

@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 commented 8 years ago

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

jneira commented 2 years ago

This has been resolved by https://github.com/haskell/cabal/pull/7973, thanks all!

jneira commented 2 years ago

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!