Fix #997 (pass --ghc-options -hpcdir) only on --coverage

[adinapoli]

This patch extends extraBuildOptions in Execute.hs to accept
an extra argument of type BuildOpts, as well as checking if coverage
is enabled. In case it is, -hpcdir is passed as --ghc-option.

This is needed to avoid certain in-memory REPL (like
hint) to choke
on that command line option.

This was the result of a compilation with latest stack:

And this is compiling with my patched stack:

☁  chronos [issue-489] ⚡ /Users/adinapoli/programming/haskell/stack/.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Stack/stack clean
☁  chronos [issue-489] ⚡ /Users/adinapoli/programming/haskell/stack/.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Stack/stack install --flag chronos:development

A couple of things I have noticed (which I think are orthogonal to my patch):

• Every time I tried to compile my project switching stack version (between my binary and the default one) a complete rebuild (with all the deps!) was triggered. Is this by design? Is quite inconvenient with massive stack (no pun intended). At the moment my project has 143 deps, and counting.
• To "toggle" between the behaviour introduced by my patch and the official one I had to do a stack clean. How so?
• Enabling --coverage both on official and my binary, the install step was failing at the final phase with:

Linking .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/chronos-ctl/chronos-ctl ...
chronos-0.15.0.0: install
Installing executable(s) in
/Users/adinapoli/work/chronos/.stack-work/install/x86_64-osx/lts-2.16/7.8.4/bin
/Users/adinapoli/work/chronos/.stack-work/install/x86_64-osx/lts-2.16/7.8.4/hpc/: getDirectoryContents: does not exist (No such file or directory)

Last thing I want is to cause a regression, so does someone have a clue on why is this happening? Can you think of any case this can be introduced by this patch?

Apart from that, should be all good.

[snoyberg]

Every time I tried to compile my project switching stack version (between my binary and the default one) a complete rebuild (with all the deps!) was triggered. Is this by design? Is quite inconvenient with massive stack (no pun intended). At the moment my project has 143 deps, and counting.

If they're local packages, I'm not surprised. We have a change on master for how binary files are saved, so in fact stack master and stack 0.1.4.0 store their metadata in different formats.

To "toggle" between the behaviour introduced by my patch and the official one I had to do a stack clean. How so?

I'm not sure exactly what you mean, but my guess is that stack clean forced a reconfigure. You could also try the new --reconfigure flag.

I'm not sure about that last point, so I'll defer to @mgsloan on it. @mgsloan: this patch is good to go IMO, assuming you don't see any way it's introduced a regression (I don't see any).

[adinapoli]

Thanks for the explanations Michael, and good to hear about --reconfigure. Will wait for the 👍 from the other Michael then!

[mgsloan]

Looks good to me!

I don't think that this will cause any regressions, so merging.

[mgsloan]

I've opened up this issue to track resolving the issue with install #1006 .