[Top][All Lists]

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

api.header.include and backward-compatible .y files

From: Adam Novak
Subject: api.header.include and backward-compatible .y files
Date: Fri, 21 Aug 2020 17:33:37 -0700


I'm maintaining a .y file at
https://github.com/vgteam/raptor/blob/master/src/turtle_parser.y that
needs to be backward-compatible with the Bison available in Ubuntu
18.04 (3.0.4), but also work on the latest Bison that our project's
Mac users get supplied from Homebrew (3.7.1).

The recent change that made api.header.include actually work seems to
make that difficult:

2020-06-09  Akim Demaille  <akim.demaille@gmail.com>

        api.header.include: document it, and fix its default value
        While defining api.header.include worked as expected, its default
        value was incorrectly defined.  As a result, by default, the generated
        parsers still duplicated the content of the generated header instead
        of including it.

The build system I am working with generates .tab.c and .tab.h files,
and then moves them around so they become plain .c and .h files.
Previously, between a hardcoded #include for the right file that the
.y injects into the .tab.cc and Bison's copy-pasting the header,
things would work and the header contents would be available to the C
code. But now, Bison insists on introducing an #include line for a
file which does not exist by the time the code is compiled, and I
can't use `%define api.header.include {<the_right_name.h>}` to fix it,
because the older Bison versions I need to support will reject the
unknown setting.

What's the right way to write a .y file that's compatible back to
3.0.4 when the header file is not going to stay as whatever.tab.h? Is
there no way to do it and I just need to add a bunch of sed to my


3.0.4 doesn't have an `api.header.include`

reply via email to

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