设置 %option prefix= 时如何让 automake 识别 flex 生成的非默认文件名答案

【问题标题】：How to get automake to recognize the non-default filename produced by flex when %option prefix= is set设置 %option prefix= 时如何让 automake 识别 flex 生成的非默认文件名
【发布时间】：2020-11-30 19:22:22
【问题描述】：

一般来说，automake 在构建解析器和扫描器时正确调用 flex 和 bison 的能力非常有用。但是，我遇到了一个似乎无法解决的问题。

我有一个 lex 文件 trigraphs.l，它执行 C trigraph 序列的文本替换。最终的可执行文件中将包含多个词法分析器，这将是一个预处理器，为适当的 C 预处理器准备源文件，因此后续的词法分析器将负责连接跨越多个物理行的逻辑行，另一个将剥离输出 cmets 等。根据 C 标准，这些转换应该按照特定的顺序进行，因此为避免出现问题，我使用了三个独立的词法分析器，它们将以正确的顺序运行。

无论如何，为了避免符号名称冲突，我使用 %option prefix="blah"，所以我的三字扫描仪如下：

%option noyywrap
%option prefix="trigraphs_"

%%

"??<"   { printf("{"); }
"??>"   { printf("}"); } 
"??("   { printf("["); } 
"??)"   { printf("]"); } 
"??="   { printf("#"); } 
"??/"   { printf("\\"); } 
"??'"   { printf("^"); } 
"??!"   { printf("|"); }
"??-"   { printf("~"); }
.       { printf("%c", *yytext); }

%%

问题似乎是 automake->ylwrap 期望 flex 的输出具有传统的 lex.yy.c 文件名，以重命名为 trigraphs.c。然而，因为 %option 前缀也改变了输出文件名（到 lex.trigraphs_.c），所以它不会被重命名为 Makefile 所期望的 trigraphs.c。当 Makefile 想要编译 trigraphs.c 并且它不存在时，这会导致明显的编译错误。

我想到的一个解决方案是使用 %option outfile="lex.yy.c" 来回避这个问题。到目前为止它似乎有效；但是，感觉有点“hackish”，所以我想知道是否有更惯用或规范的方式来处理这个问题。在寻找其他人找到的解决方案时，我确实遇到了this question on StackExchange，但它现在已经有 8 年历史了，因此可能在此期间有所发展。

【问题讨论】：

我认为 8 年来没有任何变化。 Automake 和以往一样古怪，虽然 ylwrap 现在真的没有什么用处，但它仍然存在，如果你有多个解析器或词法分析器，它只会妨碍你。至少，这是我的看法。

标签： flex-lexer automake

【解决方案1】：

没有更惯用的方法来处理这个问题，因为 Automake 规则对 flex 一无所知。 Automake 期望使用与 POSIX lex 兼容的项目，并期望任何 lex 实现遵循POSIX convention of producing a lex.yy.c file。

【讨论】：