gcc 提供了-I-选项，-I-前面的-I目录将搜索带引号的包含 (#include "foo.h" (，-I-后面的-I目录将搜索括号内的包含 (#include <foo.h> (，并在其他目录之后搜索带引号的包含。
-I-还有另一个非常重要的影响。 它会从默认搜索路径中删除#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(这将影响其他平台上的构建过程(。 但是，我们希望包含来自builddir的config.h，而不是srcdir中的zconf.h。
这可以通过GCC的-I-标志来实现，但似乎是不可能的。
更新的问题：
好吧，似乎GNU CC开发人员弃用了-I-，但没有提供实现其功能的替代方法。 所以我更新的问题是：引起开发人员注意的最有效方法是什么，以便很有可能-I-未弃用(我觉得这是最可取的，因为它是一种非常优雅的方式来处理指定搜索，比 -iquotexxx 更是如此，更丑陋(， 或者提供了某种方法从带引号的包含搜索路径中删除当前目录？
外构建中处理了zconf.h的烦恼之后，我肯定会回到你的观点，当一个问题非常棘手时，它通常是错误的问题。你是绝对正确的。正确的问题是为什么zconf.h存在于srcdir中，而它应该从zconf.h.in生成。应始终为一组给定的配置设置生成文件，或者从不生成文件。它永远不应该在同一版本中同时提供和生成。
这里最好的解决方案是从源代码树中删除zconf.h，并始终从zconf.h.in生成它，就像在 CMake 构建中所做的那样。我一直不清楚为什么它以一种方式为 CMake 做，而另一种方式为 Make。如果关键是你没有 autoconf，所以你将使用一个预构建的 zconf.h for make，而一个 CMake 生成的 CMake 的，那么只需将其作为zconf.h.in发布(你这样做(，并将其复制到 Makefile 中的构建树中。
摆脱-I-的怪异行为是一个很好的举措。在您的搜索路径中有多个文件以相同的名称引用是非常令人困惑和丑陋的。如果-I搜索顺序很重要，则表示您的项目或构建中没有正确设计某些内容。我永远不必猜测#include "foo.h"指的是什么。我绝对不应该处于很容易发现自己编辑错误文件的情况。
zlib 当然不是最难构建的软件包，但它肯定也不是最容易构建的(特别是如果你需要 contrib/minizip 的东西，我总是这样做(。