[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; ; ) |
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
- Yacc support vs. Bison support,
Bruno Haible <=