parsing - 如何用多个文件编译yacc/Bison ？

Question

我想调整kconfig-libs(/<path-to-kconfig>/libs/parser)的yacc分析器。但是我在解决各种符号，变量，函数，标记等时遇到问题。我想问题是，对于编译而言，并非包括kconfig-parser的所有文件。这是我的工作:

lex lconf.l
bison -d -y ./yconf.y 
gcc -o yconf y.tab.c

我收到如下错误消息:

./yconf.y 499:44: Error: >>ROOTMENU<< not declared (first use in this function)
rootmenu.prompt = menu_add_prompt(P_MENU, ROOTMENU, NULL);
                                          ^

./yconf.y:576:2: Error: »zconfnerrs« not declared (first use in this function)
zconfnerrs++;
^

./yconf.y:546:3: Error: »zconfnerrs« not declared (first use in this function)
zconfnerrs++;
^

解析器目录中还有更多文件(.c和.h)，(我想)需要包含在编译过程中: hconf.c, lconf.c util.c symbol.c menu.c expr.c confdata.c, lkc.h lkc_proto.h(但是在源代码中已经有特定的 #include命令)

我直接使用此代码。当我在该目录中使用makefile时，它可以毫无问题地进行编译，但是像上面显示的那样手动执行似乎不起作用。不幸的是，由于我不是makefile-pro，makefile对我来说似乎很隐秘-因此查找它们的工作并不容易。

感谢您的建议，关于在哪里“传递”这些文件，以便可以正确完成编译。

亲切的问候

[ 编辑:]
kconfiglib的源代码可以在 http://ymorin.is-a-geek.org/projects/kconfig-frontends中找到。解析器的来源位于: /<path-to-kconfig>/libs/parser

Answer 1

这些构建问题确实与野牛或flex无关。每当您尝试构建复杂的软件项目而不使用项目的构建系统时，都会发生类似的问题。

因此，简单的答案是kconfig-frontends项目是使用自动工具构建的，这意味着您应该执行

./configure [options]

在顶层目录中，以创建构建项目所需的 Makefile。

像往常一样，git存储库实际上并不包含 configure脚本。而是必须使用自动工具创建该脚本(和其他必要的配置文件)。

如果您使用的是发行版tarball，则无需弄清楚如何生成configure脚本，因为它已包含在tarball中。因此，您的构建问题可能会更少。

顺便说一句，源代码管理不是一个简单的问题，关于如何执行它有许多不同的意见。问题之一是，在构建过程中注入(inject)对源文件的修改是很常见的，例如为了配置特定于平台的默认设置。例如，采用以下行:

rootmenu.prompt = menu_add_prompt(P_MENU, ROOTMENU, NULL);

在 conf_parse函数底部找到 yconf.y。在这里， ROOTMENU应该是一个字符串，其中包含根菜单的文件路径；该文件路径将是特定于安装的，因此未在源代码中的任何位置定义。而是将其注入(inject) Makefile，它将包含类似以下内容的行:

CPPFLAGS = -DROOTMENU="\"$(root_menu)\"" -DCONFIG_=\"$(config_prefix)\" ...

(这比这还复杂；我正在大大简化该过程。但是 libs/parser/Makefile.am中有些类似的行，在顶层运行 libs/parser/Makefile后，您会在 ./configure中找到相关的内容。)
make在需要构建目标文件时将 CPPFLAGS(即C PreProcessor标志)传递给C编译器。 (有许多这样的预定义变量；您可以在 make的文档中找到列表。) gcc(和大多数其他C编译器)将 -DMACRO=value解释为“在预处理这些源文件之前将 MACRO预先定义为 value”。

结果是，除非您认为 automake的输入文件是源文件的一部分，否则您的宏在源文件的任何位置都不可见。除非您了解这些宏，否则不使用 bundle 的构建系统就无法编译文件。

上面是C/C++源代码分发的标准问题。您遇到的另一个问题很容易避免(我认为)，但也很普遍。
flex和 bison都带有将生成的代码中的 yy前缀更改为其他选项的选项。如果您的项目中有多个解析器或扫描器，则需要执行此操作。否则，全局符号会发生冲突，例如 yylex或(在这种情况下) yynerrs。 kconfig项目使用前缀 zconf，因此符号 zconfnerrs是全局变量，解析器在每次报告语法错误时都会对其进行递增。但是要使其正常工作，在使用 bison生成解析器和使用 flex生成扫描器时，需要设置前缀。

前缀可以在命令行选项中设置，也可以在 bison和 flex源文件中设置。与上述魔术宏一样，使用命令行选项会使设置不那么可见。此外，如果未将前缀设置为预期值，则生成的代码可能不会编译，并且肯定不会链接。因此，我更喜欢在源文件中设置前缀，但并非所有人都认同这种观点，包括您试图构建的软件包的作者。

我在顶层 configure文件中找到了设置:

AM_LFLAGS="-L -P zconf"
AM_YFLAGS="-t -l -p zconf"

这些设置用于为Makefile创建 LFLAGS( flex 标记)和 YFLAGS(野牛“yacc”标记)变量。 (如果您知道要查找的内容，很容易找到它们，但这不是借口。)

对于它的值(value)，我会将此设置放入源文件中:

  /* Flex (.l) file: */
%option prefix="zconf"

  /* Bison (.y) file: */
%define api.prefix "zconf"

其他命令行选项不太重要，尽管如果需要，也可以在源文件中设置它们。

我不知道为什么要使用 -l/-L标志:它们使bison/flex省略了 #line指令，该指令将生成的文件链接到 .y/.l文件中的源行号；没有这些指令，调试会更加痛苦。 bison -t标志使bison包含用于“跟踪”解析的代码，尽管您仍然必须将全局变量 yydebug(在这种情况下为 zconfdebug)设置为非零值，以便实际生成跟踪。强烈建议使用 -t，因为它成本低廉并且简化了调试，但是没有它，项目应该可以正常构建。