不推荐使用 GCC 标头搜索路径

Question

我发现了一个不寻常的 C makefile 设置，它依赖于似乎没有现代替代品的 GCC 已弃用功能。

此系统需要在包含本地头文件之前对其进行预处理或“烹饪”。 makefiles 会处理这个并将熟版本放在本地'./prepared/' 目录中。头文件使用它们的正常名称如#include "name.h" 正常包含在c 中。系统只需要 './prepared/' 出现在 GCC 头文件搜索路径中的 '.' 之前。

Gcc 曾经提供 -I- 选项来删除默认的 '.'并允许在其之前添加标题搜索路径条目，但不推荐使用此选项。

来自 gcc 文档：

GCC 查找以 #include "file" 开头的请求头 包含当前文件的目录，然后在目录中 由 -iquote 选项指定，然后在相同的地方它会 已寻找带有尖括号的标头。例如， 如果 /usr/include/sys/stat.h 包含#include“types.h”，GCC 看起来 对于 types.h，首先在 /usr/include/sys 中，然后在其通常的搜索路径中。

在 gcc 中没有办法正确控制 C 标头搜索路径了吗？还是有另一种明智的前进方式？我不想使用可能会消失的已弃用功能。现在我很遗憾地过滤 gcc 已弃用的功能警告消息以隐藏它们。构建环境不是我创建的，以打破“烹饪”的方式解决问题会不受欢迎。

Answer 1

据我所知，GCC 没有提供除您所描述的方法之外的其他方法，以避免在编译该文件时将每个源文件的目录放在包含搜索路径中。

最好的解决方案可能是修复头部并构建系统以摆脱头部烹饪。这样的计划很不寻常——几乎其他人都没有。

如果您必须继续依赖标头烹饪，那么您可能应该将原始标头移动到不在包含搜索路径中的目录。例如，在主源目录下创建一个“include”子目录，并将它们放在那里。

编辑添加： 另一种选择是从引用的包含样式切换到尖括号的包含样式，并依靠-I 选项来设置所需的内部包含目录。