Avoid building the target packages with "stack ghci" #1364

Closed
mgsloan opened this Issue Nov 18, 2015 · 11 comments

Projects

None yet

3 participants

@mgsloan
Collaborator
mgsloan commented Nov 18, 2015

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 #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.
@mgsloan mgsloan added this to the P2: Should milestone Nov 18, 2015
@hesselink
Contributor

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
Collaborator
mgsloan commented Nov 23, 2015

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

@hesselink
Contributor

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

@hesselink
Contributor

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
Contributor

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
Collaborator
mgsloan commented Nov 25, 2015

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.

@mgsloan mgsloan closed this Nov 25, 2015
@hesselink
Contributor

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

@mgsloan
Collaborator
mgsloan commented Nov 30, 2015

Didn't mean to close this, reopening.

@mgsloan mgsloan reopened this Nov 30, 2015
@luigy
Contributor
luigy commented Mar 8, 2016

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
Collaborator
mgsloan commented Mar 8, 2016

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 mgsloan self-assigned this Jul 20, 2016
@mgsloan mgsloan closed this Oct 15, 2016
@mgsloan
Collaborator
mgsloan commented Oct 15, 2016

This is now implemented!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment