Re: glr.c: Token definitions

[Joel E. Denny]

On Wed, 21 Sep 2005, Akim Demaille wrote:

> Then indeed --yacc seems the right thing.  But then we have another
> problem: The Autotools currently quite promote using `bison -y' (so
> that the file naming conventions are those of Yacc).  Autoconf and
> Automake should be upgraded to support native Bison in addition of
> stupid yacc names.

If I understand you correctly, removing the #define's in the absence of
`-y' wouldn't cause any compatibility issue with autotools since autotools
promotes the usage of `-y'.  In other words, this change could be made to
bison now with no changes to autotools.

However, you're saying there wouldn't be a way to remove #define's *and*
take advantage of AC_PROG_YACC and automake's lex and yacc compilation
features at the same time.  Right?

If you were to add native bison support to autotools, how would automake
know when you need yacc and when you need bison?  What if you need both?
Should automake recognize a ".bison" suffix as the bison-equivalent of
yacc's ".y"?  When I write a bison spec that isn't yacc-compatible, it's
my habit to use ".bison" anyway... because it just seems more logical.

Moreover, if a user depends on native bison features (such as removal of
#define's), then he shouldn't use AC_PROG_YACC since it might find
something other than bison. Are you planning to add AC_PROG_BISON?

Joel