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

[Joel E. Denny]

On Tue, 12 Dec 2006, Hans Aberg wrote:

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

Yes, that's true in many cases, so my example wasn't very good.  However, 
for people still using prologues (those ugly %{...%} things), I believe 
one common way to put extra code in their header is to wrap it in another 
header, #include the wrapper in parser.y, and depend on cpp guards to 
prevent multiple occurrences of the same definitions.

Then again, it occurs to me now that anyone who writes:

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

is surely aware that some file somewhere very likely depends on the 
original header name.  A possible problem is someone who doesn't realize 
that a header was previously being generated at all, but I guess we have 
to assume the user knows something about what's going on.  If we go this 
way, there should probably be a short note about this issue in the 
--defines and %defines documentation.

> Though
> some may want to override it. Perhaps yet another macro, that can be undefined
> at need!?

I hope that's not necessary.

> 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'.

Yes, I was thinking of that too.

I'm now leaning towards make's approach.  I have some patches to review 
and some other work, so I'll sit on this a little longer in case others 
have input.