Odd build failure with new-build #3932
Assignees
Milestone
Comments
|
Well, next time, give us some verbose logs ;) |
|
Fair enough 😳 |
|
Hmmmm.. So this is after I blew away my store. A bit later, fiddling with the dependencies of my project, another build failure: Verbose log: |
|
Here too blowing away the store fixed the problem. |
|
@ezyang fyi, this seems to be related to custom build types |
|
OK, after reading the tea leaves, here's what's going on.
Not sure what kind of fix we can apply. |
|
So what does that mean? Any user with multiple choices for a package in their store will run into this problem unless they put a |
|
The specific situation this problem arises is (1) there is a Custom setup built with Cabal 1.18 or earlier, (2) there are multiple possible solutions for a particular set of constraints in the database, and (3) Setup chooses poorly. We should fix it. I'm just not entirely sure how ;) |
|
Oh, I see. I misunderstood. It's not that my |
|
Yes. But if you put the constraint in your |
|
I see. So perhaps we have to say that new-build requires the Setup.hs to be later than 1.18. |
|
I'd be OK with that? Hopefully we can give a good error message when the Setup script doesn't work. |
Hmm, I thought we already did that? In |
|
Just to remark that I'm running into this fairly regularly. It's not an issue for me personally but I would say that from a PR perspective this definitely needs to be fixed for the next release. |
|
Assuming that our plan is to just require 1.20 or later for new-build, this should be a pretty easy fix assuming we find the right place to put the constraint. |
|
Based on testing, it doesn't look like That's... pretty bogus (I just put a constraint for < 1.18 in p's custom-setup stanza.) |
|
With @ezyang's help, I've done some investigation of this issue today. Here is a rough summary of what we've learned:
The two cases we have identified in (2) are:
Again, the analysis may be a bit off due to difficultly with testing this feature. |
|
OK, we figured out what was going on.
So, one way we could solve this problem is by also modifying custom-setup stanzas when they exist, but we're going to take a different approach: add an extra constraint on Cabal globally to make sure the solver respects it regardless of whether or not there is an explicit setup build info or not. |
|
Fix in #4051 |
ezyang
pushed a commit
that referenced
this issue
Oct 29, 2016
Constrain Cabal >= 1.20 in all new-build install plans. This solves problems where Cabal 1.18 don't have a good enough API to let us handle the new-style store (we need --dependency flags.) In the future we plan to relax this to only Setup.hs dependencies. Fixes issue #3932.
|
And fixed! |
|
@hvr is this in your cabal-install-head package? |
|
With @hvr 's cabal-head 1.25+git20161109.0.d48c1eb-3~16.04, I got this today: Verbose log Blowing away my |
|
Just another data point: another |
|
@edsko I wonder if you could make this failure reproducible by using |
erikd
pushed a commit
to erikd/cabal
that referenced
this issue
Jan 28, 2017
Constrain Cabal >= 1.20 in all new-build install plans. This solves problems where Cabal 1.18 don't have a good enough API to let us handle the new-style store (we need --dependency flags.) In the future we plan to relax this to only Setup.hs dependencies. Fixes issue haskell#3932.
|
Looks like some rough edge of an early version of |
|
Let's close optimistically. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Building https://github.com/well-typed/ghc-events-analyze with ghc 7.8.4:
Blowing away my
~/.cabal/store/7.8.4directory solved the problem. I realize that this bug report doesn't give much to go on... But wanted to report it anyway. Feel free to close as "not enough information" :)The text was updated successfully, but these errors were encountered: