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.

[luigy]

Really all that needs to happen is to run initialBuildSteps before running ghci.

True for single package project, but what about multi-package scenario in which a local package could be a dep of another local package? :P
Is there some sane trick for this? I feel like this may be doable by mocking a local package db just for ghci, but seems like just asking for trouble more than anything 😂

1. ...
2. This would have weird behavior in multi-package projects. For example, if you have foo and bar in a project, and bar depends on foo, you can't configure bar until you build foo. I'm not sure how this kind of interface would tie in to that.

Rather, since point 2 hasn't been addressed yet, stack should run build twice for each directly wanted package. Once with BSOnlyDependencies and once more with only-configure to generate LocalBuildInfo. I may have missed a way to achieve this with a single build step?
Then we are ready to run initialBuildInfo like it was mentioned above

I'm not sure if this is territory where the solution for #1265 may have an effect here

[mgsloan]

Is there some sane trick for this? I feel like this may be doable by mocking a local package db just for ghci, but seems like just asking for trouble more than anything 

Oh wow, I hadn't thought about that. Mocking the package might just work, but I'd say it's best to focus on getting it working for a single package. Then, we can do an "only-dependencies" build that includes local packages required by targets.

Once with BSOnlyDependencies and once more with only-configure to generate LocalBuildInfo.

Yes, something like that. I don't think BSOnlyDependencies will work out the box, though. It won't build any of the target packages, but we do want to build target packages if they are dependencies of some other package (as discussed earlier in this comment)

I'm not sure if this is territory where the solution for #1265 may have an effect here

I don't think it'll have much impact on this.

[mgsloan]

This is now implemented!

[ezyang]

@mgsloan Should Cabal library take up this fix?

UPDATE: Actually, we run initialBuildSteps before repl; I misunderstood what this patch does, which is make it possible to call Setup to just do preprocessing

[mgsloan]

@ezyang Shouldn't be necessary. It would be nice to have a way to ask Setup.hs to run intialBuildSteps, but not necessary.