Re: Flex size_t sizes

[Bug reports for Bison, the GNU parser generator]

> On 12 Nov 2021, at 23:41, Kaz Kylheku <k...@kylheku.com> wrote:
> 
> On 2021-10-14 06:23, Hans Åberg wrote:
>> Hi Akim,
>> Saw you have edited Flex, so I take it up here, even though not
>> strictly a Bison topic:
>> The Apple flex version has been edited to admit size_t sizes, 64-bit
>> on the platform, and perhaps it might be good idea for regular flex,
>> which uses int, only 32-bit there. If using '%option c++' and mixing
>> the versions, then the FlexLexer.h header is incompatible with the C++
>> source code, generating a compile error.
>> On MacOS with MacPorts and Xcode, the files are in
>> /opt/local/include/FlexLexer.h
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/FlexLexer.h
> 
> Consider shipping the output of Flex as part of your project source code,
> so that downstream users do not have to have Flex installed.
> 
> I was not previously aware of this FlexLexer.h (TIL -- "today I learned").

This is when the problems occur, because the system installed FlexLexer.h 
version must agree with the Flex version used.

> This is because I would never think of putting Flex together with C++.

This is specific to the Flex C++ version scanner, which one might use becaue 
one wants to use the C++ streams.

> I see that, for instance on a Ubuntu 18 system here, there is a
> /usr/bin/FlexLexer.h file.
> 
> This is an incredibly, incredibly bad idea.
> 
> Generated parser or scanner code must be 100% self-contained. The 
> Flex-generated
> code cannot be depending on some /usr/include/FlexLexer.h.

It is what it is, and it Flex developed much, so it is better to use something 
else.

> Never mind it being the wrong version; what if it doesn't exist?

Then it won't compile. One can ship it with the sources, and set it so that the 
copiler looks for it, either by patching it, which is what I think Akim did, or 
set an compiler -I option.

> If there must be a FlexLexer.h, the thing to do is to arrange for the build
> process to use a local copy of FlexLexer.h that is in your tree. As part of
> generating the scanner, your Makefile (or whatever) steps should hunt down
> this header file, stick it into your tree, and make the code refer to that
> copy.
> 
> Check that copy into version control, and make sure downstream users have it
> as part of the distribution, and that they can build the scanner without
> having any portion of Flex installed on their system.

So this is a way, but if you do not want to ship it, then it must be present 
elsewhere. And if you ship it, and the the .ll file is compiled with an 
incompatible Flex version, it won't compile.