Re: %name-prefix overrides --name-prefix?

[Joel E. Denny]

On Sat, 9 Dec 2006, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes:
> 
> > Although that logic makes sense to me, Bison doesn't follow it.  Instead, 
> > for example, %name-prefix has precedence over --name-prefix.
> >
> > Which way should Bison behave?

Thanks for everyone's input on this.  Here are my current thoughts.

> In 'make', command-line FOO=bar has precedence over makefile FOO=bar.

The above is what the comments in src/files.c falsely claim as the current 
behavior.  At first, I thought it made sense to do it that way, but now I 
see a problem.  Consider this:

  %defines "parser.h"
  %{ #include "parser.h" %}

and then:

  bison --defines="parser-new.h" parser.y

Given the above precedence rule, this parser won't compile except in the 
unfortunate case that you have a "parser.h" lying around.  Maybe this is 
why the above form of %defines wasn't previously possible?

> In 'cc', command-line -DFOO=bar has equal precendence with source-file
> "#define FOO bar"; that is, if both are specified then they must agree
> or a diagnostic is generated.

I can't think of any problems with this.  It seems clean.

> In 'awk', command-line -v FOO=bar is executed before the
> program (and thus las lower precedence than assignments to
> FOO in the program)

The above is the current behavior.  Consider if you're not a Bison expert 
and you're handed a parser.y that you didn't write.  You would probably 
find it very strange if this:

  bison --defines="parser-new.h" parser.y

generated a header named "parser.h" instead of "parser-new.h".

> So perhaps we should go the 'cc' route?

That's what I'm thinking.  Any more discussion?