New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
4 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.
@hesselink

This comment has been minimized.

Contributor

hesselink commented Nov 23, 2015

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

hesselink commented Nov 23, 2015

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

@hesselink

This comment has been minimized.

Contributor

hesselink commented Nov 24, 2015

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

This comment has been minimized.

Contributor

hesselink commented Nov 24, 2015

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

hesselink commented Nov 25, 2015

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

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Nov 30, 2015

Didn't mean to close this, reopening.

@luigy

This comment has been minimized.

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

This comment has been minimized.

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 added a commit that referenced this issue Oct 10, 2016

mgsloan added a commit that referenced this issue Oct 12, 2016

Merge pull request #2697 from commercialhaskell/1364-setup-shim-for-ghci
Use a shim to invoke initialBuildSteps for ghci #1364

@mgsloan mgsloan closed this Oct 15, 2016

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Oct 15, 2016

This is now implemented!

@ezyang

This comment has been minimized.

ezyang commented Jan 27, 2017

@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

This comment has been minimized.

Collaborator

mgsloan commented Jan 31, 2017

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

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