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

[Adam Novak]

The ifndef include guards are inside the generated header, not around
the include.

The usage of <> predates my work on the project. I think "" would be
more correct, but <> has historically successfully found the header
anyway.

I could try and redo the build system to use the .tab.h filenames.
Right now it drops the .tab as part of some already-existing rewriting
logic, but I could make it clobber the original file or rename the
result back.

On 8/23/20, Kaz Kylheku <kaz@kylheku.com> wrote:
> 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).
>
> By the way, you have some issues in your code. The #include <...>
> notation
> is for including system headers, not your own local headers.
>
> I see that you have
>
>
> %{
>
> /* ... */
>
> #include <turtle_parser.h>
>
> /* ... */
>
> %}
>
> in your grammar file where "turtle_parser.h" is the renamed header that
> is originally "turtle_parser.tab.h".
>
> Is that finding the right header?
>
> Consider using #include "turtle_parser.h" in any case.
>
> I would expect that if you include that header in the %{  ... %}
> section,
> then the generated parser's own #include of the same header should then
> be suppressed with #ifndef, something like:
>
> #ifndef YY_YY_TURTLE_PARSER_TAB_H_INCLUDED
>
> ...
>
> your renamed header should still be putting out the macro.
> Isn't there such an #ifndef in the generated parser around the
> include of the header?
>