[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %name-prefix overrides --name-prefix?
From: |
Joel E. Denny |
Subject: |
Re: %name-prefix overrides --name-prefix? |
Date: |
Tue, 12 Dec 2006 16:37:51 -0500 (EST) |
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.
- %name-prefix overrides --name-prefix?, Joel E. Denny, 2006/12/09
- Re: %name-prefix overrides --name-prefix?, Paul Eggert, 2006/12/10
- Re: %name-prefix overrides --name-prefix?, Hans Aberg, 2006/12/10
- Re: %name-prefix overrides --name-prefix?, Paolo Bonzini, 2006/12/11
- Re: %name-prefix overrides --name-prefix?, Joel E. Denny, 2006/12/12
- Re: %name-prefix overrides --name-prefix?, Hans Aberg, 2006/12/12
- Re: %name-prefix overrides --name-prefix?,
Joel E. Denny <=
- Re: %name-prefix overrides --name-prefix?, Hans Aberg, 2006/12/12
- Re: %name-prefix overrides --name-prefix?, Joel E. Denny, 2006/12/14
- Re: %name-prefix overrides --name-prefix?, Hans Aberg, 2006/12/14
- Re: %name-prefix overrides --name-prefix?, Joel E. Denny, 2006/12/14
- Re: %name-prefix overrides --name-prefix?, Hans Aberg, 2006/12/14