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

[Akim Demaille]

Hi Adam,

> Le 22 août 2020 à 02:33, Adam Novak <anovak@soe.ucsc.edu> a écrit :
> 
> 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).

Back in the days, people were *shipping* the generated files.  That
was awesome, since then maintainers are free from such constraints:
they use whatever version of their favorite generator is, and are
free from requiring anything from the user; users don't even need
to have the generator (Bison in the present case).

It's a pity today we lost this wisdom.

> 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.

So you lie to your tool.  Why don't you *tell it* what you need
instead of playing tricks afterwards?  Just use -o/%output and
quit sedding.

> 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,

That doesn't make sense.  Why would the header not exist?  You should
fix your build procedure to make it available.  If you are sedding
something about the generated parser, do the same with the generated
header *at the same time*.

> 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
> build?

If that's possible for you, you may also decide in your build
procedure to pass '-Dapi.header.include={foo.h}' to bison if
it supports it.

Cheers!