我发现了一个不寻常的 C 联编文件设置，它依赖于 GCC 的一个已弃用的功能，该功能似乎没有现代替代品。
该系统需要在包含本地头文件之前对其进行预处理或“ cooking ”。 makefile 会处理这个并将熟化的版本放在本地“./prepared/”目录中。头文件使用它们的正常名称(例如 #include "name.h")正常包含在 c 中。系统只需要在 GCC 头文件搜索路径中出现在“.”之前的“./prepared/”即可。
Gcc 曾经提供 -I- 选项来删除默认的 '.'并允许在它之前添加 header 搜索路径条目，但不推荐使用此选项。
来自 gcc 文档:
GCC looks for headers requested with #include "file" first in the directory containing the current file, then in the directories as specified by -iquote options, then in the same places it would have looked for a header requested with angle brackets. For example, if /usr/include/sys/stat.h contains #include "types.h", GCC looks for types.h first in /usr/include/sys, then in its usual search path.
在gcc中是不是再也无法正确控制C头文件的搜索路径了？或者还有其他明智的前进方式吗？我不想使用可能会消失的已弃用功能。现在我很遗憾地过滤了 gcc 弃用的功能警告消息以隐藏它们。我没有创建构建环境，以破坏“ cooking ”的方式解决问题是不受欢迎的。
最佳答案
据我所知，除了您所描述的方法之外，GCC 没有提供其他方法来避免在编译该文件时使用的包含搜索路径中首先出现每个源文件的目录。
最好的解决方案可能是修复 header 并构建系统以摆脱 header cooking 。这样的计划非常不寻常——几乎其他人都没有。
如果您必须继续依赖 header cooking ，那么您可能应该将原始 header 移动到不在包含搜索路径中的目录中。例如，在主源目录下创建一个“include”子目录，并将它们放在那里。
编辑添加:
另一种选择是从引用的包含样式切换到尖括号的包含样式，并依靠 -I 选项来设置所需的内部包含目录。
关于c - GCC header 搜索路径已弃用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29832390/