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

["Eric S. Raymond" <esr@thyrsus.com>]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> If you get a conflict, turn the second feature in config file order off/on
> as appropriate then tell the user you did it.  Then continue to verify.

> Actually I think the problem is different. You are trying to solve a 
> mathematical graph theory problem elegantly. Make oldconfig solves a real
> world problem by a mixture of brutality and heuristics. 

You want brutality and heuristics?  I'll give you brutality and heuristics...

I could just treat a config as a sequence of assignments, as though
the user had typed them in sequence, rejecting any later ones that
throw constraint violations.  That way we can avoid ever accepting or
having to deal with an invalid configuration.  The invariant that every
symbol assignment either augments a valid configuration or is rejected
would be conserved.

This isn't "recovery", it's more like high-handedly throwing away
assignments that don't happen to fit stuff bound earlier in the tree
traverse that defines symbol print order.  And it's going to give odd,
"brutal" results in some cases because guard symbols are ordered
before their dependents.

But if all you want is brutality and heuristics, it might do.


I guess you didn't know that I trained as a mathematical logician.  On the
one hand, that predisposes me to try to find "elegant" solutions where 
you might regard brutality and heuristics as more appropriate.

On the other hand, without that kind of background you don't get
people building constraint-satisfaction systems to give you
provably-correct results, either.  So perhaps, on the whole,
mine is a more positive predisposition than not ;-).
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Men trained in arms from their infancy, and animated by the love of liberty,
will afford neither a cheap or easy conquest.
        -- From the Declaration of the Continental Congress, July 1775.