Keith Owens <[EMAIL PROTECTED]>:
> On Wed, 12 Dec 2001 11:29:47 -0500,
> "Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> >Keith Owens <[EMAIL PROTECTED]>:
> >> IMHO the only correct method is to write out only the visible symbols.
> >
> >The current logic looks like this:
> >
> >1. If the symbol has been explicitly set, write it out.
> >2. Otherwise, if the symbol's visibility predicate is all frozen symbols and is n,
> > suppress it.
> >3. Otherwise, if an ancestor symbol is n, suppress it.
> >4. Otherwise write it out.
> >
> >Am I being too complicated here?
>
> Probably. CML1 just does 3+4. 1 propagates symbols that were set at
> some time in the past, they get written out even when set to n.
I can drop test 1. But if I do that, and user sets a symbol he found
via a search command, and that symbol doesn't happen to be normally
visible, and then saves, he's not going to get the result he expects.
I can't drop test 2. This is the test that prevents saving SPARC symbols when
X86 is frozen on. Typically, architecture-dependent choices are not descendents
of the arch symbol, they merely have it in their visibility expressions.
Maybe I ought to just collapse 3 and 4 into "write it out if it's visible".
I'll perform some experiments.
> >> Also I suspect that part of the CML2 problem is inconsistent state
> >> about which symbols are visible or not, caused by the slightly
> >> different constraints of the front ends. If that is the case, the fix
> >> is obvious.
> >
> >The front ends all use the same rulebase, so they're deducing from the
> >same constraints. And they all use the same is_visible() predicate.
>
> So why do different front ends produce different output when fed
> identical input?
I don't know yet. The only opening I can see for producing this kind
of variation is the funky way defaults in choice menus are determined.
Long ago I computed them at rulebase compile time, but this kept
running me into constraint errors. Also, there are issues about the
right thing when the choice menu's compiled default happens to have
its visibility predicate evaluate to n at runtime...
So choice defaults are not actually computed until the time the menu
is first visited by the user. What differs beween front ends is the
timing of first visit. In ttyconfig you don't visit a menu until you
touch one of the symbols inside it. In menuconfig and xconfig you
also visit a menu the first time its parent menu gets thrown on the
display -- because a submenu is only supposed to be visible if it
has visible symbols inside it.
I'm going to have to stare at this code for a while.
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
The right to buy weapons is the right to be free.
-- A.E. Van Vogt, "The Weapon Shops Of Isher", ASF December 1942
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
