17

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

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

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

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

由于各种原因，我们无法从中删除config.h（srcdir它会影响其他平台上的构建过程）。但是，我们希望将config.hfrombuilddir优先于zconf.hin srcdir。

这可以通过 GCC 的-I-标志来完成，但在其他方面似乎是不可能的。

更新的问题：

好吧，似乎 GNU CC 开发人员已弃用-I-，但没有提供实现其功能的替代方法。所以我更新的问题是：让开发人员注意这一点的最有效方法是什么，以便很有可能不-I-被弃用（我认为这是最可取的，因为它是处理指定的一种非常优雅的方式搜索，比 -iquotexxx 更丑更丑），或者提供了某种方法来从引用的包含搜索路径中删除当前目录？

4

1 回答 1

4

在处理了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 的东西，我总是这样做）。

于 2012-07-24T03:58:45.890 回答