Hi, Up to version 2.69, Autoconf has - good support for Yacc-syntax sources, - mediocre support for Bison-syntax sources.
Let me distinguish - Yacc programs, that follow the POSIX specification http://pubs.opengroup.org/onlinepubs/9699919799/utilities/yacc.html , - Bison programs, that use one or more of the many (useful) Bison extensions. What are the problems with the Yacc support? None I know of. What are the problems with the Bison support? (A) When configure runs on a machine that has a BSD yacc installed, but no bison installed, the variable YACC gets set to 'yacc', and 'make' fails because 'yacc' of course does not support the Bison extensions. (B) The newly introduced warnings in Bison 3.3+ https://git.savannah.gnu.org/gitweb/?p=bison.git;a=commitdiff;h=d92ed9d9f72bfe98dfee5d13800aef95b87c82c6 will warn about intended uses of Bison extensions. (C) The Automake documentation https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html advertises Yacc support, but no Bison support. Problem (A) has been widely recognized; it is the reason for the separate macros bison.m4 and INTLBISON in intl.m4 (both in gnulib). Now comes the patch from 2013-03-19 https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=42761668c0300afa7f8bf5ba736458a818cd5d15 presented in https://lists.gnu.org/archive/html/autoconf-patches/2013-03/msg00000.html What it does is to remove (B) from the list of problems in the Bison support and add it to the problems of Yacc support. Namely: Now the problems of Yacc support are: (B') The newly introduced warnings in Bison 3.3+ - which would be useful for this case - cannot be activated. (The advice given in autoconf/NEWS, "Add -Wyacc to your YFLAGS to enable them." cannot be followed because the BSD yacc does not understand the -Wyacc option.) Now the problems of Bison support are: (A) as above (C) as above This is not a good situation, IMO. I would suggest to come to good support for Bison sources, while at the same time not regress on the support for Yacc sources, as follows: 1) Revert the patch from 2013-03-19. 2) Introduce a macro AC_PROG_BISON (or AC_PROG_YACC_BISON if you prefer) that sets the YACC variable, with the following differences: - It takes an optional version argument that specifies the minimum Bison version needed. - If a non-Bison yacc or a Bison version smaller than that version is found, it sets the YACC variable to ':'. Rationale: dnl bison is only needed for the maintainer (who touches the *.y dnl sources). But in order to avoid separate Makefiles or dnl --enable-maintainer-mode, we put the rule in general Makefile. dnl Now, some people carelessly touch the files or have a broken dnl "make" program, hence the generated .y -> .c rule will sometimes dnl fire. To avoid an error, defines YACC to ":" if it is not dnl present or too old. - If a Bison in the expected version range is found, set YACC to 'bison -o y.tab.c'. 3) In Automake, mention the Bison support in the documentation. And change the error message Makefile.am: error: Yacc source seen but 'YACC' is undefined Makefile.am: The usual way to define 'YACC' is to add 'AC_PROG_YACC' Makefile.am: to 'configure.ac' and run 'autoconf' again. to Makefile.am: error: Yacc or Bison source seen but 'YACC' is undefined Makefile.am: The usual way to define 'YACC' is to add 'AC_PROG_YACC' or Makefile.am: 'AC_PROG_BISON' to 'configure.ac' and run 'autoconf' again. How does that sound? As far as I can see, this would solve the problems (A), (B), (C) in the Bison support, while at the same time not regressing behind 2.69 regarding the Yacc support. Bruno