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

[Hans Aberg]

On 12 Dec 2006, at 08:13, Joel E. Denny wrote:

> > 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?

I think so. One would expect to not having to write the #include  
above. Though some may want to override it. Perhaps yet another  
macro, that can be undefined at need!?

The situation I am thinking of, is if one want to change a project  
somebody else has written. Then it is pain having to patch up every  
new version. So this favors 'make'.

> > So perhaps we should go the 'cc' route?
>
> That's what I'm thinking.  Any more discussion?

Do this if you think the precedence rule will cause problems. It is  
possible to change it later. But, otherwise, I think the 'male' rule  
might be useful.

  Hans Aberg