Stack silently swallows the ghc-options when it can't detect any changes in the project

[sjakobi]

First I thought this was just an instance of #1411, but it seems to be bit more:

~/s/stack (master) $ stack build
... snip regular build output ...
~/s/stack (master) $ stack build --ghc-options -O2
~/s/stack (master) $ stack build --ghc-options "-O2 -fforce-recomp"
~/s/stack (master) $ stack build --ghc-options -fforce-recomp
~/s/stack (master) $ stack build --ghc-options -wtf
~/s/stack (master) $ stack exec -- ghc -wtf
ghc: unrecognised flag: -wtf

Usage: For basic information, try the `--help' option.
~/s/stack (master) $ stack --version
Version 1.0.5, Git revision 57eb614df50826f38b923e1892cda904288a8ec9 (dirty) (3489 commits) x86_64 hpack-0.12.0

[mgsloan]

I actually forgot the details of how this works. Looks like the change to fix #1089 made --ghc-options only apply when rebuild-ghc-options is enabled.

So, basically, use ghc-options in the stack.yaml if you want it to apply in this way. This could probably be documented better - marking as a documentation issue.

[sjakobi]

Oh, I hadn't known about rebuild-ghc-options! I'm not sure whether I agree with the default of false but I think that at least there should be a warning like

Flags changed from [] to ["-O2"], ignoring.
Set rebuild-ghc-options to true to rebuild when ghc-options change.

Maybe rebuild-ghc-options should be configurable on the CLI too?

[mgsloan]

Hmm, yeah, it makes sense to me to explain to the user why --ghc-options changes don't force rebuilds.

I'm not sure whether I agree with the default of false

Me either, but it's even more fiddly to mess with the default

Maybe rebuild-ghc-options should be configurable on the CLI too?

I think --force-dirty does the trick, at least for local packages.

[sjakobi]

I think --force-dirty does the trick, at least for local packages.

It seems that it only executables are recompiled, not the library, nor extra-deps (aeson in this example). extra-deps are locals, right?

~/s/hpack (master) $ stack install
aeson-0.11.0.0: unregistering
...
yaml-0.8.15.3: copy/register
hpack-0.12.0: configure
Configuring hpack-0.12.0...
hpack-0.12.0: build
Preprocessing library hpack-0.12.0...
[ 1 of 10] Compiling Hpack.Haskell    ( src/Hpack/Haskell.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Hpack/Haskell.o )
[ 2 of 10] Compiling Hpack.Render     ( src/Hpack/Render.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Hpack/Render.o )
[ 3 of 10] Compiling Hpack.FormattingHints ( src/Hpack/FormattingHints.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Hpack/FormattingHints.o )
[ 4 of 10] Compiling Hpack.Yaml       ( src/Hpack/Yaml.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Hpack/Yaml.o )
[ 5 of 10] Compiling Hpack.Util       ( src/Hpack/Util.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Hpack/Util.o )
[ 6 of 10] Compiling Hpack.GenericsUtil ( src/Hpack/GenericsUtil.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Hpack/GenericsUtil.o )
[ 7 of 10] Compiling Hpack.Config     ( src/Hpack/Config.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Hpack/Config.o )
[ 8 of 10] Compiling Hpack.Run        ( src/Hpack/Run.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Hpack/Run.o )
[ 9 of 10] Compiling Paths_hpack      ( .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/autogen/Paths_hpack.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Paths_hpack.o )
[10 of 10] Compiling Hpack            ( src/Hpack.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Hpack.o )
In-place registering hpack-0.12.0...
Preprocessing executable 'hpack' for hpack-0.12.0...
[1 of 1] Compiling Main             ( driver/Main.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/hpack/hpack-tmp/Main.o ) [Hpack changed]
Linking .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/hpack/hpack ...
hpack-0.12.0: copy/register
Installing library in
/home/simon/src/hpack/.stack-work/install/x86_64-linux/lts-5.3/7.10.3/lib/x86_64-linux-ghc-7.10.3/hpack-0.12.0-EyFdpy1ilHuKownSRYvByY
Installing executable(s) in
/home/simon/src/hpack/.stack-work/install/x86_64-linux/lts-5.3/7.10.3/bin
Registering hpack-0.12.0...
Completed 29 action(s).
Copying from /home/simon/src/hpack/.stack-work/install/x86_64-linux/lts-5.3/7.10.3/bin/hpack to /home/simon/.local/bin/hpack

Copied executables to /home/simon/.local/bin:
- hpack
~/s/hpack (master) $ stack install --ghc-options -O2 
Copying from /home/simon/src/hpack/.stack-work/install/x86_64-linux/lts-5.3/7.10.3/bin/hpack to /home/simon/.local/bin/hpack

Copied executables to /home/simon/.local/bin:
- hpack
~/s/hpack (master) $ stack install --force-dirty --ghc-options -O2 
hpack-0.12.0: unregistering (--force-dirty specified)
hpack-0.12.0: configure
Configuring hpack-0.12.0...
hpack-0.12.0: build
Preprocessing library hpack-0.12.0...
In-place registering hpack-0.12.0...
Preprocessing executable 'hpack' for hpack-0.12.0...
hpack-0.12.0: copy/register
Installing library in
/home/simon/src/hpack/.stack-work/install/x86_64-linux/lts-5.3/7.10.3/lib/x86_64-linux-ghc-7.10.3/hpack-0.12.0-EyFdpy1ilHuKownSRYvByY
Installing executable(s) in
/home/simon/src/hpack/.stack-work/install/x86_64-linux/lts-5.3/7.10.3/bin
Registering hpack-0.12.0...
Copying from /home/simon/src/hpack/.stack-work/install/x86_64-linux/lts-5.3/7.10.3/bin/hpack to /home/simon/.local/bin/hpack

Copied executables to /home/simon/.local/bin:
- hpack

[mgsloan]

--force-dirty just causes the cabal configure + build to be reinvoked. If Cabal / ghc don't think a rebuild needs to happen, it doesn't happen.

[sjakobi]

--force-dirty just causes the cabal configure + build to be reinvoked. If Cabal / ghc don't think a rebuild needs to happen, it doesn't happen.

Ah, thanks for clearing that up. Adding -fforce-recomp made the library recompile too (not aeson though)!

[sjakobi]

The docs part of this issue was fixed in 9dcfcd9.

Remains the warning.

[jberryman]

I'm not sure whether I agree with the default of false

Me either, but it's even more fiddly to mess with the default

More fiddly how? It might cause more rebuilds?

I don't think this is the right default. I already don't trust my haskell tooling and regularly do a clean or blow away my caches if I'm ever in doubt because I've been burned so many times with this sort of thing.