Bad install plan selected for keter with GHC 7.8.2 #1877
Assignees
Labels
Comments
kosmikus
added a commit
to kosmikus/cabal
that referenced
this issue
May 19, 2014
This adds a mechanism in the modular solver to store whether a flag is "strong" or "weak". A weak flag is deferred during solving, a strong flag is not. By default, flags are now weak unless they're manual. This is a change in behaviour, but I think it's probably the better default, because many automatic flags are used to figure out what's on the system rather than to impose hard constraints. There's a new flag --strong-flags that restores the old behaviour. I do not think such a global flag is particularly useful, but it may be of interest to compare build plans between the new and old behaviour. With these preparations, it's easy to make the distinction between strong and weak flags more sophisticated. We can either add more heuristics as to when flags should be treated as strong or weak, or we can add syntax to .cabal files that allows package authors to specify explicitly how they intend a flag to behave. This is related to various cabal-install issues, e.g. haskell#1831, haskell#1864, and haskell#1877.
|
As far as I can test, this one is (will be) fixed by #1879. |
kosmikus
added a commit
that referenced
this issue
May 23, 2014
This adds a mechanism in the modular solver to store whether a flag is "strong" or "weak". A weak flag is deferred during solving, a strong flag is not. By default, flags are now weak unless they're manual. This is a change in behaviour, but I think it's probably the better default, because many automatic flags are used to figure out what's on the system rather than to impose hard constraints. There's a new flag --strong-flags that restores the old behaviour. I do not think such a global flag is particularly useful, but it may be of interest to compare build plans between the new and old behaviour. With these preparations, it's easy to make the distinction between strong and weak flags more sophisticated. We can either add more heuristics as to when flags should be treated as strong or weak, or we can add syntax to .cabal files that allows package authors to specify explicitly how they intend a flag to behave. This is related to various cabal-install issues, e.g. #1831, #1864, and #1877. (cherry picked from commit 3dcddea) Conflicts: cabal-install/Distribution/Client/Dependency.hs
kosmikus
added a commit
that referenced
this issue
May 23, 2014
This adds a mechanism in the modular solver to store whether a flag is "strong" or "weak". A weak flag is deferred during solving, a strong flag is not. By default, flags are now weak unless they're manual. This is a change in behaviour, but I think it's probably the better default, because many automatic flags are used to figure out what's on the system rather than to impose hard constraints. There's a new flag --strong-flags that restores the old behaviour. I do not think such a global flag is particularly useful, but it may be of interest to compare build plans between the new and old behaviour. With these preparations, it's easy to make the distinction between strong and weak flags more sophisticated. We can either add more heuristics as to when flags should be treated as strong or weak, or we can add syntax to .cabal files that allows package authors to specify explicitly how they intend a flag to behave. This is related to various cabal-install issues, e.g. #1831, #1864, and #1877. (cherry picked from commit 3dcddea) Conflicts: cabal-install/Distribution/Client/Dependency.hs cabal-install/Distribution/Client/Freeze.hs cabal-install/Distribution/Client/Setup.hs
Closing then. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With a clean package database, I just ran
cabal install keter --dry-runusing ghc-7.8.2 and cabal-install-1.20.0.1. The full output is available at:https://gist.github.com/snoyberg/d1b9d1d4e3feae8daad9
The important bits:
Instead running with
--reorder-goalsgenerates a more sensible build plan: https://gist.github.com/snoyberg/1a8362ee40aa5b91675b.This is likely related to #1855.
The text was updated successfully, but these errors were encountered: