任意C项目的预处理[关闭]答案

【问题标题】：Preprocessing of arbitrary C Projects [closed]任意C项目的预处理[关闭]
【发布时间】：2016-11-19 15:42:01
【问题描述】：

我想用 python 编写一个好的调用图程序，因此我使用 pycparser。 Pycparser 需要预处理 c 文件才能正确创建抽象语法树。我的第一种方法是在文件上仅使用 gcc 的 -E 选项，然后将其传递给 pycparser。但是对于不同的项目，我会收到“No such file or directory”错误，因为 gcc 找不到特定的标头。如果我尝试使用 gcc -E `find | grep "\.c"\` 预处理 linux 内核，它会丢失一些头文件，例如带有 Linux/ 前缀的头文件，因为没有这样的文件夹。在我看来，我需要一些额外的标志来让 gcc 传递头文件的位置并正确地进行预处理。是否有预处理任意 C 项目的通用方法？

此外，我猜如果我让它正确预处理，那么不同文件中有相同函数的多个副本。有没有办法确定函数的原始文件？

【问题讨论】：

没有一种正确的方法可以找到所有源代码的标头。不同的程序需要通过预处理器命令行上的-I /path/to/headers 选项指定不同的目录集。

标签： python c gcc c-preprocessor pycparser

【解决方案1】：

您需要了解 GCC 如何查找头文件，至少包括编译器命令行开关和搜索路径的环境变量。

我怀疑各种项目集配置变量的构建脚本会影响 GCC 如何为任何特定编译找到头文件。许多这样的脚本甚至在命令行上进行宏替换，这意味着你必须知道脚本在做什么。

如果您将 C 源文件与设置其构建上下文的 make 脚本隔离开来，GCC 将找不到正确的头文件。这就是你的问题。

您可能需要运行构建脚本，并拦截对 GCC 的调用以捕获必要的上下文。

【讨论】：

谢谢。听起来很复杂。也许我尝试只为 linux 内核编写这个程序。有人可以帮助我使用 gcc 命令对其进行预处理。 gcc -E -nostdinc -I ./include -I ./arch/x86/include/ find | grep "\.c" 似乎不起作用:(
@Mr.Moon 是什么让您认为 Linux 内核在解决这个问题时要容易得多？
我写这个调用图程序的意图是Linux内核。我只想让它通用，以便其他人可以将它用于其他 c 程序。如果我可以预处理内核并编写这个程序只用于内核，那对我来说就足够了。
@Mr Moon：你没有回答我问的问题。内核是很多编译单元。为什么你认为这些比其他 C 程序更容易（预）处理？
我不认为预处理比其他 C 程序更容易，但我认为它比一般预处理任意 C 程序更容易。