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

[Kaz Kylheku]

On 2020-08-21 17:33, Adam Novak wrote:
> Hello,
>
> 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.

There are just two wrongs here: you and Bison. I'm leaning toward
less you and more Bison.

The "-b" option of Yacc is specified by POSIX. The .tab.c and .tab.h
convention is hard-coded. POSIX doesn't explicitly state that you can
just rename the files yourself and they still work. So you are skirting
trouble by doing that.

That said, Bison did a bad thing here. You see, POSIX requires y.tab.c 
to
duplicate y.tab.h. That's why the skeleton was doing it.

Here is the wording from POSIX about y.tab.c:

   "It also shall contain a copy of the #define statements in
   the header file."

Now if that is the case, there is no reason for y.tab.c to include
y.tab.h, which has the interpretation that you can rename it to whatever
you want!

Bison's change to reference the header file via #include is actually
a nonconformance which breaks programs that rename the header.

I see this in a 3.0.4 generated file:

  /* In a future release of Bison, this section will be replaced
     by #include "y.tab.h".  */
  #ifndef YY_YY_Y_TAB_H_INCLUDED

I.e. "a future release of Bison will raise a middle finger to
IEEE 1003.1 which requires the following section ...".

Your parser is obviously using so many extensions that we might
be tempted to say that POSIX is irrelevant; yet it's obviously
relevant because you would still have this issue with the header
file even if you were using Bison as nothing more than a yacc
implementation.

Anyway, though, try just not renaming the files and living
with the .tab. infix. It's a nice convention. When any "Yacc
person" sees those files, they know what they are.

The way Bison is maintained, it is such a moving target, that
the the best thing to do may be to insist on a particular version of
Bison for building your program. And since downstream distros that
pick up your project, as well as regular users, will certainly not
have that version of Bison, what you have to do is include the
generated Bison code in your project, checked into your Git repo,
and redistributed along with your source.

This way only someone who wants to be a contributor
(specifically, a contributor who wants to modify your .y files)
has to then get that required version of Bison to rebuild the
parsers.