[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Yacc support vs. Bison support

From: Bruno Haible
Subject: Yacc support vs. Bison support
Date: Sat, 08 Dec 2018 00:48:03 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-138-generic; KDE/5.18.0; x86_64; ; )


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+
      will warn about intended uses of Bison extensions.

  (C) The Automake documentation
      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
presented in

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.


       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' 

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]