[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flex size_t sizes
Re: Flex size_t sizes
Sat, 13 Nov 2021 11:17:34 +0100
> On 12 Nov 2021, at 23:41, Kaz Kylheku <firstname.lastname@example.org> 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
> 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
> 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
> 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
> 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.