Re: Flex size_t sizes

[Hans Åberg]

> On 14 Nov 2021, at 01:55, Kaz Kylheku <kaz@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.