On Mon, 22 Oct 2007, Vegard Nossum wrote: > On 7/23/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: > > > > i'm trying to extend the kconfig structure to add the "maturity" > > level we've been discussing on LKML, and i started with a patch > > suggested by simon arlott which *looked* fine, but this is what i get > > when i run "make config": > > > > $ make config > > HOSTCC scripts/basic/fixdep > > HOSTCC scripts/basic/docproc > > HOSTCC scripts/kconfig/conf.o > > HOSTCC scripts/kconfig/kxgettext.o > > bison -l -b scripts/kconfig/zconf -p zconf scripts/kconfig/zconf.y > > scripts/kconfig/zconf.y: conflicts: 28 shift/reduce > > scripts/kconfig/zconf.y: expected 26 shift/reduce conflicts > > make[1]: *** [scripts/kconfig/zconf.tab.c] Error 1 > > make: *** [config] Error 2 > > $ > > > > now, i can attach the patch but here's a simpler question from > > someone who *isn't* a lex/yacc expert -- what does the above error > > mean? why would there be a mismatch between the number of s/r > > conflicts it expects and the number it finds? > > An s/r conflict means that the grammar is ambiguous. Sometimes these > ambiguities are not a concern (the compiler always picks either > shift or reduce, and sometimes it happens to be the right choice), > so we tell lex/yacc not to warn about them. > > > my first impression (from a position of overwhelming ignorance) > > is that there is, somewhere, a remnant of the official build which > > states that there are 26 s/r conflicts, but the new content > > generates 28. how can i guarantee that i'm doing a fresh build of > > *all* the kconfig stuff? > > Line 41 of scripts/kconfig/zconf.y says: %expect 26 > > So it is likely that your changes introduced two new conflicts. > Instead of simply raising the expected value, the case should be > analyzed to see what the effects are in practice. Probably this is > worthy of a comment in the source file where you explain why the > ambiguity is nothing to worry about. Though it is probably better to > fix the ambiguity. > > > i've set "LKC_GENPARSER := 1" so the build is certainly > > rebuilding the "shipped" stuff, but is there anything else that > > might be the problem? > > > > barring an easy solution, i can submit the patch if someone > > wants to look at it. it seems fairly straightforward, but i'm at > > a loss. thanks. > > > > rday > > Hope this helps.
fair enough, trying to iron out the ambiguities would be nice but, barring that, is it reasonable to assume that (at least in this case), if there are any legitimate ambiguities, they would affect only the new directive being introduced? that is, if the extension to the Kconfig language was to introduce nothing more than the aforementioned "maturity" directive that takes a single argument, is there any way (theoretically) that could screw up the parsing of any other part of the Kconfig structure? (i don't see how but i'm not an expert.) naturally, i'm asking since it would be nice to introduce this feature to allow it to be tested as long as it can't possibly mess up what's already there, and eventually tracking down the ambiguities could wait until later if they truly cause problems. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== - To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
