[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flex size_t sizes

From: Kaz Kylheku
Subject: Re: Flex size_t sizes
Date: Sat, 13 Nov 2021 16:55:16 -0800
User-agent: Roundcube Webmail/0.9.2

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]