> On 14 Nov 2021, at 01:55, Kaz Kylheku <k...@kylheku.com> wrote: > > 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.
Those installing it may do it different, like compiling the .ll file even thought they should not. GNU 'make distcheck' puts the sources in a read only directory and forces compilation with flex and bison. >> 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. No, it generates it when compiling and add additional ones needed to same directory. So no problems there. > (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.) I thought it would suffice to be compilable with latest Flex, but then it turns out that there are home brew versions out there.
