@@ -78,17 +78,21 @@ scopedExtendOpen qpn i gr fdeps fdefs s = extendOpen qpn gs s
78
78
qfdefs = L. map (\ (fn, b) -> Flagged (FN (PI qpn i) fn) b [] [] ) $ M. toList fdefs
79
79
-- Combine new package and flag goals
80
80
gs = L. map (flip OpenGoal gr) (qfdefs ++ qfdeps)
81
- -- IMPORTANT AND SUBTLE: The order of the concatenation above is
82
- -- important. Flags occur potentially multiple times: both via the
83
- -- flag declaration ('qfdefs') and via dependencies ('qfdeps').
84
- -- We want the information from qfdeps if it's present, because that
85
- -- includes dependencies between flags. We use qfdefs mainly so that
86
- -- we are forced to make choices for flags that don't affect
87
- -- dependencies at all.
81
+ -- NOTE:
88
82
--
89
- -- When goals are actually extended in 'extendOpen', later additions
90
- -- override earlier additions, so it's important that the
91
- -- lower-quality templates without dependency information come first.
83
+ -- In the expression @qfdefs ++ qfdeps@ above, flags occur potentially
84
+ -- multiple times, both via the flag declaration and via dependencies.
85
+ -- The order is potentially important, because the occurrences via
86
+ -- dependencies may record flag-dependency information. After a number
87
+ -- of bugs involving computing this information incorrectly, however,
88
+ -- we're currently not using carefully computed inter-flag dependencies
89
+ -- anymore, but instead use 'simplifyVar' when computing conflict sets
90
+ -- to map all flags of one package to a single flag for conflict set
91
+ -- purposes, thereby treating them all as interdependent.
92
+ --
93
+ -- If we ever move to a more clever algorithm again, then the line above
94
+ -- needs to be looked at very carefully, and probably be replaced by
95
+ -- more systematically computed flag dependency information.
92
96
93
97
-- | Datatype that encodes what to build next
94
98
data BuildType =
0 commit comments