On 2021-11-13 13:18, Hans Åberg wrote:
This works as long as nobody tries to compile the .ll file with an incompatible Flex version even in the case the header is shipped.
Your build system has to handle that situation. If the downstream user builds your program in such a way that the .ll file is processed by Flex, rather than using the shipped scanner, then in that situation, that system's FlexLexer.h has to be pulled in or referenced; the build obviously cannot be using the shipped FlexLexer.h, in conjunction with the freshly generated lex.yy.cc. I'd have it so that when the shipped code is being prepared, then the #include <FlexLexer.h> line is replaced by the contents of the header, right there, in place. It then has no references to anything. And so then if a fresh local build is done, then a lex.yy.cc will be generated whose #include <FlexLexer.h> line is left alone and and refers to that system's FlexLexer.h. (The special editing happens only when a certain makefile target is invoked like, say, "make shipped-scanner"). If someone has multiple incompatible copies of Flex, and/or the <FlexLexer.h> header, that is their problem; if that user complains, you can point your finger to your shipped scanner and tell them to just stick to that if they have a problem with Flex. And also that regenerating the scanner is a maintainer activity, and that maintainers must have a development system with all the right tools, reliably installed if they are to build the program entirely from scratch and work on it.
It should have been as in Bison, which always includes the correct header. But Flex isn't developed, so it is what it is.
I'm not aware that Bison-generated parser sources depend on any Bison-specific external headers. (Then again, I wasn't aware that Flex had this problem in the C++ mode, and I don't have experience with every possible mode of using Bison.)
