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.


This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
kbuild-devel mailing list

Reply via email to