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 <k...@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? >
