Re: Flex size_t sizes

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.)