Re: glr.c: Token definitions

[Akim Demaille]

>>> "Joel" == Joel E Denny <address@hidden> writes:

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

Why not, that's an idea.  But you need to help Automake know what the
output language is too.

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

I should have...  I have to write this in my TODO list.