-
Notifications
You must be signed in to change notification settings - Fork 701
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
Improve algorithm for choosing flags with './Setup configure' #3082
Conversation
Cabal previously tried all flag combinations, which was very slow. The new algorithm assigns one flag at a time, and backtracks when a flag introduces a dependency that is unavailable. The new algorithm handles the Buildable field by adding an extra conditional at the top level of each component that represents the condition for which the component is buildable. Since all dependencies go under the "then" branch, they are only required when a flag choice makes the component buildable. The buildable logic is taken from the cabal-install dependency solver. This commit also changes the error message that is shown when dependencies are missing. Previously, Cabal printed the shortest list of missing dependencies from a single flag assignment. Now it takes the union of all dependencies that caused it to backtrack when trying different combinations of flags, which requires less searching.
Just checked that the |
@23Skidoo What is different in the containers test suite? |
The |
LGTM. |
Improve algorithm for choosing flags with './Setup configure'
Merged, thanks! |
@23Skidoo Thanks. I just realized that if I export |
Refactor #3082 to reduce code duplication and improve Haddock comment.
Cabal previously tried all flag combinations, which was very slow. The new
algorithm assigns one flag at a time, and backtracks when a flag introduces a
dependency that is unavailable.
The new algorithm handles the Buildable field by adding an extra conditional at
the top level of each component that represents the condition for which the
component is buildable. Since all dependencies go under the "then" branch, they
are only required when a flag choice makes the component buildable. The buildable
logic is taken from the cabal-install dependency solver.
This commit also changes the error message that is shown when dependencies are
missing. Previously, Cabal printed the shortest list of missing dependencies
from a single flag assignment. Now it takes the union of all dependencies that
caused it to backtrack when trying different combinations of flags, which
requires less searching.
I updated #2925 to allow backtracking to work with the Buildable field. I moved the
extractCondition
function (added in #2731) from the modular solver toDistribution.PackageDescription.Configuration
so that it can be used by Cabal and cabal-install. SinceextractCondition
is not a very general utility function, I was wondering if there is a better place to put it.