Yacc support vs. Bison support

[Bruno Haible]

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