On 12 Dec 2006, at 22:37, Joel E. Denny wrote:
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.
It is probably not difficult to that later, would somebody be in dire
need of it. :-)
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 have done such patching of Hugs, porting to Mac OS 9, over a number
of years, so I have some idea of it. It is fine for some time, but
after awhile, it is a chore.
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.
Though I do not have any direct need for in the case of Bison. So it
is not a big hurry to me. :-)
But it is good to set a development rule.
Hans Aberg
