Re: [kbuild-devel] Why recovering from broken configs is too hard

[Keith Owens <kaos@ocs.com.au>]

On Thu, 3 May 2001 12:59:21 -0400, 
"Eric S. Raymond" <esr@thyrsus.com> wrote:
>Keith Owens <kaos@ocs.com.au>:
>>         (3) For failing constraints, freeze the guard variables, change
>>             the dependent variable to satisfy the constraint then
>>             freeze it.
>
>There's the problem.  You don't know which variable(s) are dependent.
>That's not a well-defined notion here.  Consider the case that stimulated
>this whole argument:
>
>	(X86 and SMP) implies RTC!=n
>
>You think you know that RTC is 'dependent', but this is an illusion created
>by the presence of the asymmetrical `implies'.  Go look at the hierarchy.
>You'll see what I mean.

On the contrary, I know what the hierarchy says and I also know that
that implies is normally bidirectional.  In the case of batch mode,
where you cannot ask the user to solve the violation, I suggest that
CML2 treat implies as unidirectional, but only for this case.

IOW, the order of the constraints (not the hierarchy) and the ordering
of the guard and dependent variables in each constraint are hints by
the rules writer to CML2 about which variables are more important.
Earlier constraints are more important than later ones.  Guard
variables are more important that dependent variables.

So when CML2 reaches the end of a batch config run and has a violation
on 'require X86 and SMP implies RTC!=n', X86 and SMP will not be
considered for changing, RTC will be.  Using hints from the order of
the constraints reduces the solution space from 3^1957 to 2.