Skip to content
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

SavedConfig Monoid instance: make list fields work like Flags. #2226

Merged
merged 2 commits into from
Nov 17, 2014

Conversation

23Skidoo
Copy link
Member

Fixes #1884. See code comments for more details.

@23Skidoo
Copy link
Member Author

See #2221 for an alternative approach.

@23Skidoo 23Skidoo force-pushed the saved-config-override branch from 5512317 to 7e744fe Compare November 16, 2014 17:05
@23Skidoo
Copy link
Member Author

After a discussion with @dcoutts we decided to merge this for the time being, but migrate to an include/include with filtering mechanism in the future.

23Skidoo added a commit that referenced this pull request Nov 17, 2014
 SavedConfig Monoid instance: make list fields work like Flags.
@23Skidoo 23Skidoo merged commit ae9067d into haskell:master Nov 17, 2014
@23Skidoo 23Skidoo deleted the saved-config-override branch November 17, 2014 21:23
@snoyberg
Copy link
Collaborator

W00t! Do you want me to send PRs for 1.18 and 1.20?

@23Skidoo
Copy link
Member Author

@snoyberg Sure, go ahead. I don't know if @tibbe wants to do another 1.18 release, though.

@snoyberg
Copy link
Collaborator

I would really appreciate if we could. I still recommend 1.18 to most people so as to avoid having two different versions of the Cabal library on their systems. (I still regularly run into error messages about conflicting Cabal library versions if I use parallel builds.)

@23Skidoo
Copy link
Member Author

@snoyberg

(I still regularly run into error messages about conflicting Cabal library versions if I use parallel builds.)

Do we have a ticket for this?

@snoyberg
Copy link
Collaborator

It was issue #1244. I hadn't noticed that the issue had been closed; I'm still able to reproduce it in some cases. It may be that this issue was resolved with cabal-install-1.20; with 1.18 I can reproduce (which seems contrary to what #1244 says):

$ /opt/cabal/1.18/bin/cabal --version
cabal-install version 1.18.0.4
using version 1.18.1.3 of the Cabal library 
$ /opt/cabal/1.20/bin/cabal --version
cabal-install version 1.20.0.3
using version 1.20.0.0 of the Cabal library 
$ /opt/cabal/1.20/bin/cabal install -j
$ /opt/cabal/1.18/bin/cabal build
cabal: You need to re-run the 'configure' command. The version of Cabal being
used has changed (was Cabal-1.20.0.0, now Cabal-1.18.1.3). Additionally the
compiler is different (was ghc-7.8, now ghc-7.4) which is probably the cause
of the problem.

I believe I've also reproduced this when just using a single version of cabal-install, but I was not able to reproduce that right now.

@23Skidoo
Copy link
Member Author

Additionally the compiler is different (was ghc-7.8, now ghc-7.4) which is probably the cause
of the problem.

Hmm, can it be the case that cabal-1.20 and cabal-1.18 are set to use different versions GHC? Then the error is actually correct. We could improve the UX by calling configure automatically in this case; in fact there's already a ticket for this (#2214).

@snoyberg
Copy link
Collaborator

No, they're both using the same version of GHC (ghc-7.8). I believe that error message is simply referring to the version of the compiler which was used to compile cabal-install itself.

@23Skidoo
Copy link
Member Author

I believe that error message is simply referring to the version of the compiler which was used to compile cabal-install itself.

Hmm, yes looks like you're right.

$ /opt/cabal/1.20/bin/cabal install -j
$ /opt/cabal/1.18/bin/cabal build

I thought a bit more about this: it looks like the error is caused by cabal build using the internal setup method, which uses the Cabal version cabal-install was built with. So if you'd stick to just cabal-1.20 or cabal-1.18, you'd be OK.

One approach to making these errors happen less often is to make cabal always use the external/cached setup exe, which would always use the version of Cabal installed on the system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

No way of specifying a remote-repo in a sandbox
2 participants