如何防止引用的include搜索当前源文件的目录?
gcc提供-I-
选项,在-I-
之前的-I
目录中搜索引用的包含( #include "foo.h"
),并在-I-
之后的-I
目录中搜索括号内的包含( #include
),以及其他引用后的内容。
-I-
有另一个非常重要的影响。 它从默认搜索路径中删除#include
所在的源文件的目录。 通常,带引号的include总是搜索源文件的目录,并在任何-I
或其他目录之前搜索它。 -I-
因此允许您按照所需顺序指定引用包含文件的确切位置,方法是删除原则上优先使用的默认路径。
所以听起来我回答了我的问题,是吗? 不。当我使用-I-
,我得到了这个讨厌的图:
cc1: note: obsolete option -I- used, please use -iquote instead
问题是-iquote
不会从搜索路径中删除当前目录。 无论我向-iquote
提供什么,它仍然总是先搜索。
所以问题是:如何在不使用-I-
情况下获得与-I-
相同的效果,这已被弃用并最终消失?
阐述:
假设文件的布局如下:
srcdir/ configure file1.c file2.c config.h builddir/ Makefile file1.o file2.o config.h libpudding.a
由于各种原因,我们无法从srcdir
删除config.h
(它将影响其他平台上的构建过程)。 但是,我们希望将zconf.h
中的config.h
优先zconf.h
在srcdir
的zconf.h
中。
这可以通过GCC的-I-
标志来完成,但似乎不可能。
更新的问题:
好吧,似乎GNU CC开发人员弃用了-I-
,但没有提供实现其function的替代方法。 所以我更新的问题是:什么是引起开发人员注意的最有效的方法,以便很有可能-I-
是不完美的(我觉得最优选,因为它是一种非常优雅的方式处理指定搜索,更加如此,并且比-iquotexxx更难看,或者提供某种方式从引用的包含搜索路径中删除当前目录?
在一个树外构建中使用zconf.h
烦恼,我肯定会回到你的观点,当一个问题非常棘手时,它通常是错误的问题。 你是绝对正确的。 正确的问题是为什么zconf.h
存在于srcdir
中,当它应该从zconf.h.in
生成时。 对于给定的一组配置设置,应始终生成或永远不生成文件。 它永远不应该在同一个构建中提供和生成。
这里最好的解决方案是从源代码树中删除zconf.h
,并始终从zconf.h.in
生成它,就像在CMake构建中一样。 我从来都不清楚为什么它为CMake做了一个方法而为Make做了另一个方法。 如果关键是你没有autoconf,那么你将使用预先构建的zconf.h
进行make,而是使用CMake为CMake生成的,然后将其作为zconf.h.in
(你做了什么),并将其复制到Makefile中的构建树中。
摆脱-I-
的离奇行为是一个很好的举动。 在您的搜索路径中使用相同名称引用的多个文件非常混乱和丑陋。 如果-I
搜索顺序很重要,那么在项目或构建中没有正确设计某些内容。 我永远不应该猜到#include "foo.h"
指的是什么。 我绝对不会遇到很容易发现自己编辑错误文件的情况。
我鼓励你改进zlib构建的工作。 zlib肯定不是最难构建的软件包,但它肯定不是最简单的(特别是如果你需要contrib / minizip的东西,我总是这样做)。