如何防止引用的包含搜索当前源文件的目录？

Question

gcc 提供了-I- 选项，在-I- 之前的-I 目录中搜索带引号的包含（#include "foo.h"），在-I- 之后的-I 目录中搜索带括号的包含（@ 987654329@)，以及其他引用的包括。

-I- 还有一个非常重要的作用。它会从默认搜索路径中删除#include 所在的源文件目录。通常，带引号的包含总是搜索源文件的目录，并在任何-I 或其他目录之前搜索它。因此，-I- 允许您通过删除默认路径（否则会优先考虑）来准确指定引用包含文件的位置。

所以听起来我回答了我的问题，是吗？不，当我现在使用-I- 时，我得到了这个讨厌的图：

cc1: note: obsolete option -I- used, please use -iquote instead

问题在于-iquote 确实没有从搜索路径中删除当前目录。无论我向-iquote 提供什么，它仍然总是首先搜索。

所以问题是：如何在不使用 -I- 的情况下获得与 -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 更丑更丑），或者提供某种方法从引用的包含搜索路径中删除当前目录？

Answer 1

在树外构建中处理了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 发送（您do)，并将其复制到 Makefile 中的构建树中。

摆脱-I- 的怪异行为是一个很好的举措。在您的搜索路径中有多个以相同名称引用的文件非常令人困惑和难看。如果-I 搜索顺序很重要，那么您的项目或构建中的某些内容设计不正确。我永远不必猜测#include "foo.h" 指的是什么。我绝对不应该处于容易发现自己编辑错误文件的情况。

我对您改进 zlib 构建的工作表示赞赏。 zlib 肯定不是最难构建的包，但也肯定不是最简单的（特别是如果你需要 contrib/minizip 的东西，我总是这样做）。