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的东西，我总是这样做）。
需要了解更多c/c++开发分享如何防止引用的include搜索当前源文件的目录？，也可以关注C/ C++技术分享栏目—计算机技术网(www.ctvol.com)!
以上就是c/c++开发分享如何防止引用的include搜索当前源文件的目录？相关内容,想了解更多C/C++开发(异常处理)及C/C++游戏开发关注计算机技术网(www.ctvol.com)!)。
本文来自网络收集，不代表计算机技术网立场，如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址：https://www.ctvol.com/c-cdevelopment/979795.html