3 ms·

Flex / Bison are manageable if you spend a bit of extra time reading the manual. I admit that there are often better options out there these days, I'm just sayi

Flex / Bison are manageable if you spend a bit of extra time reading the manual. I admit that there are often better options out there these days, I'm just saying that some of these complaints about Flex / Bison may be a bit outdated. Multiple grammars are fine, you just instruct Flex and Bison to use static or add prefixes. No worries about ODR or LTO. If your build system can't handle generated code, that's an indictment of your build system. I know that's a bit harsh, but there are plenty of build systems which can handle generated code and cross-compile just fine. Flex and Bison work fine on Windows.

jcelerier 5y ago
It's good that prefixes are now possible, but it's still something additional to know (I have never seen them in the wild and I've seen a lot of yacc in various projects), while most C++ programmers don't have to search inside some manual to know that two parsers must not have the same name : while with yacc / bison, you generally only discover it when it crashes at run-time. Also http://gnuwin32.sourceforge.net/packages/bison.htm http://gnuwin32.sourceforge.net/packages/bison.htm is not what "work fine on Windows" mean (hell, it does not even have the prefix thing you mentioned in the other comment). If there's anything ressembling a ./configure / some step that requires bash in its build pipeline then it's a complete no-go and given the GNU history of bison I doubt it'd use CMake. Though even if all of this was solved, it'd still not be as convenient as Spirit.
- klodolph 5y ago
  When I integrate third-party dependencies I often port the build system to the build system I'm using. For projects made with autotools, that means ignoring the configure script, hand-writing a "correct" version of config.h.in, and reading Makefile.am. I'm sure this practice would offend some people. In my experience, this practice is quite common in industry. I've done this enough times that using Bison on Windows was no problem at all. In my case, I wasn't really interested in Bison itself, but I was using a different third-party dependency which itself depended on Bison.

jcelerier 5y ago

It's good that prefixes are now possible, but it's still something additional to know (I have never seen them in the wild and I've seen a lot of yacc in various projects), while most C++ programmers don't have to search inside some manual to know that two parsers must not have the same name : while with yacc / bison, you generally only discover it when it crashes at run-time. Also http://gnuwin32.sourceforge.net/packages/bison.htm http://gnuwin32.sourceforge.net/packages/bison.htm is not what "work fine on Windows" mean (hell, it does not even have the prefix thing you mentioned in the other comment). If there's anything ressembling a ./configure / some step that requires bash in its build pipeline then it's a complete no-go and given the GNU history of bison I doubt it'd use CMake. Though even if all of this was solved, it'd still not be as convenient as Spirit.

klodolph 5y ago
When I integrate third-party dependencies I often port the build system to the build system I'm using. For projects made with autotools, that means ignoring the configure script, hand-writing a "correct" version of config.h.in, and reading Makefile.am. I'm sure this practice would offend some people. In my experience, this practice is quite common in industry. I've done this enough times that using Bison on Windows was no problem at all. In my case, I wasn't really interested in Bison itself, but I was using a different third-party dependency which itself depended on Bison.