Xcode: multiple Bison & Flex parsers/scanners

Question

Created Jun ’16

Replies 3

Boosts 0

Views 3.1k

Participants 3

I noticed that some amount of effort has been put into Xcode to support yacc/Bison source files (.y, .ypp, .ymm) and lex/Flex source files (.l, .lpp, .lmm) out of the box conveniently with Xcode projects, that is you just add those source files to your Xcode project and Xcode will automatically generate the respective parser and scanner for you.

However there is one issue I encountered: for a pair of Flex/Bison scanner/parser one usually wants Bison to additionally generate the parser's definitions as separate header file, which would be on the command line either:

bison -d foo.y
mv y.tab.h foo.h

or

bison --defines=foo.h foo.y

That auto generated C/C++ header file (in this case foo.h) would then be included i.e. on scanner side (i.e. to avoid declaring terminal symbols twice on both ends).

Is there a convenient way to handle generation of such parser header files with Xcode as well?

As far as I can see it at the moment (with Xcode 7), when I look at the auto generated output files, Xcode actually calls Bison to let it generate the definition header file and a y.tab.h file is created accordingly, so if you just have exactly 1 Bison parser then you can do a hack and use a

#include "y.tab.h"

statement in your respective source files. But since the auto generated header file will always be named "y.tab.h", what would you do if you got multiple Bison parsers in your project? Shouldn't Xcode automatically do

mv y.tab.h foo.h

for each parser it generates?

Boost

Answer 1

Jeff_Mulligan OP

Jan ’17

bison provide the name-prefix option to handle this. I am currently struggling with the issue that the syntax of the directive was changed in bison 3.0, which I have installed on my systems, but xcode still wants to use the version 2.3 that is part of the command line tools package. bison doesn't have ifdef's or a way to query its own version number in the source code...

0

Answer 2

Crudebyte OP

Oct ’17

The "name-prefix" option of Bison is not related to this issue, it avoids symbol conflicts of the auto generated functions (when having multiple Bison generated compiles) by prefixing all auto generated functions with the given token for the respective generated compiler. And to answer your question on "name-prefix": The correct way to handle this is using the old, deprecated syntax:

%name-prefix="MyPrefix_"

This compiles both with Bison 2 coming with Xcode, as well as with Bison 3. Only drawback: you will get a deprecated warning with the latter, which you cannot disable. But there is no better solution unfortunately since Apple does not have any plans to update Bison shipped with Xcode, and on the other hand you don't really want to tell every of your devs that he must compile Bison 3 on his machine manually just because of this issue.

However as said, the "name-prefix" option does not have any impact on the Bison generated header file name, it will still always write a file named "y.tab.h" for every single Bison generated compiler in your project target, which is obviously a bug in Xcode. I filed a bug report for this (#26995520) but never got a response.

0

Answer 3

Konchog OP

Jul ’21

Still wondering how to get Xcode to use my own flex 2.6.4 / bison 3.7 rather than the built ins, which are out of date.

0