Avoid building the target packages with "stack ghci"

[mgsloan]

In order to make stack ghci reliable / consistent, the cabal_macros.h and Paths_* files need to be generated. Currently, this means that we do a full build of the targets (unless --no-build is passed).

Really all that needs to happen is to run initialBuildSteps before running ghci. Running this function requires LocalBuildInfo, which gets stored in dist/setup-config. Unfortunately, we can't call it directly from stack - it uses Binary / Generic, so we can't rely on it being compatible between cabal versions (and stack may be linked with a different version).

I think a reasonable solution to this is to have a separate program which runs initialBuildSteps on the specified packages. This separate program could either be a script that gets runhaskell-ed, or something that gets build and installed to the snapshot (like the default Setup.hs).

This solution also has relevance to other issues:

• It's also the information necessary to allow Setup.hs to modify the cabal info (see "stack ghci" doesn't honor configured cpp flags #970). Doing this would be more complicated. I think the best way to do this would be to serialize localPkgDescr as a .cabal file (I really hope this is possible). Then, we'd would parse the resulting cabal file, and use that description to generate the arguments passed to ghci.
• This may also allow us to avoid doing full rebuilds for haddock - I noted that in cabal this function is also called by the haddock stuff.

[hesselink]

Another reason this would be very useful (IIUC) is an issue I just ran into. If you have two packages, A and B, and A depends on B, then running ghci A B will now build B. This means that is B has type errors, you won't get a ghci prompt! Often the reason I start ghci is because I'm developing package B, so getting type errors is expected.

Let me know if this is not related, and I'll file a new issue.

[mgsloan]

Hmm, that is surprising. Is this with stack >= 0.1.8? Currently it should carry on running ghci despite build failures.

[hesselink]

That was with stack 0.1.6. I'll try with 0.1.8 and HEAD tomorrow.

[hesselink]

I just tried. 0.1.8 and HEAD give the same result: they build package B, fail, say Warning: build failed, but optimistically launching GHCi anyway (that's new), and then fail with something like <command line>: cannot satisfy -package <some completely different dependency>. I have no idea what's going on, but I don't get a working GHCi...

[hesselink]

Oh, sorry, I just figured out there was another dependency in between. When testing it with the right setup, it works correctly with HEAD and 0.1.8. Disregard my comments, sorry for the noise.

[mgsloan]

No worries! I'm planning to implement #584 soon, btw :D It really does seem to be crucial for having a nice ghci workflow when you have lots of packages.

[hesselink]

Oh that's great news, I'll forward to it!

[mgsloan]

Didn't mean to close this, reopening.