clang 的包含优先级是怎么回事？答案

【问题标题】：What's going on with clang's include priorities?clang 的包含优先级是怎么回事？
【发布时间】：2014-04-06 09:37:12
【问题描述】：

我的命令：

/usr/bin/c++ -fPIC -I/Users/me/project/include -I/usr/local/include/opencv \
-I/usr/local/include -I/opt/local/include -std=c++11 -O3 -M -c \
/Users/me/project/src/program.cpp | grep opencv

program.cpp 有：

#include "opencv2/core/core.hpp"
#include "opencv2/ml/ml.hpp"

输出：

  /opt/local/include/opencv2/core/core.hpp \
  /opt/local/include/opencv2/core/types_c.h /usr/include/assert.h \
  /usr/include/math.h /opt/local/include/opencv2/core/version.hpp \
  /opt/local/include/opencv2/core/operations.hpp \
  /opt/local/include/opencv2/core/mat.hpp \
  /opt/local/include/opencv2/objdetect/objdetect.hpp \
  /opt/local/include/opencv2/ml/ml.hpp \

但是，存在：/usr/local/include/opencv2/core/core.hpp 和 /usr/local/include/opencv2/ml/ml.hpp。

使用-v 标志，clang 告诉我：

ignoring duplicate directory "/usr/local/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 /Users/me/project/include
 /usr/local/include/opencv
 /opt/local/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1
 /usr/local/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)

尽管/usr/local/include 在命令的-I 目录列表中排在第一位，为什么clang 包含来自/opt/local/include 而不是/usr/local/include？为什么/usr/local/include会被优先级列表下推。

【问题讨论】：

尝试颠倒收录顺序，你会得到答案
@user2485710 你的意思是把-I/opt/local/include -I/usr/local/include/opencv -I/usr/local/include？这并不能解决问题。 /usr/local/include 仍会在-v 生成的包含路径列表中列出 /opt/local/include。
它们不包含相同的标题，您是否使用简约的源代码尝试过这种方式？ stackoverflow.com/a/6685693/2485710
搜索目录的内容不应该影响-v产生的搜索顺序。（而且，它们确实包含相同的标题，尽管这并不重要。）我认为你不理解我的问题。
那个测试只是冗长的编译，忘记你对文件的看法，只需将源代码提供给`gcc'，看看真正使用了哪些文件。

标签： clang include-path

【解决方案1】：

您可以通过以下方式查看#include 的默认搜索路径：

gcc -Wp,-v -E -

（将-v 标志提供给预处理器）。

您的目录（以-I 给出）在标准列表之前搜索，按照您给它们的顺序。

您明确给出/usr/local/include，而gcc 无视您的指令，因为它稍后会被添加（作为系统目录）；因此以错误的顺序搜索目录。如果您真的想控制自己搜索的目录，请使用-nostdinc 并全部提供。那是极其脆弱的。

拥有两组具有相同名称的头文件是一个非常糟糕的主意（正如您所发现的那样）。没有办法清理那个乱七八糟的东西？

【讨论】：

那么，我不应该在 /opt/local/lib 中安装 opencv 2.4.8，而在 /usr/local/lib 中安装开发分支？我认为通过在命令行中指定包含目录和库目录的顺序，可以很容易地在这些之间进行选择。似乎这只是一个非常糟糕的主意因为 gcc 和clang 的这种行为。
“拥有两组同名的头文件是一个非常糟糕的主意......” - 嗯？这是更新过时库的标准方法。操作系统在/usr/{include|lib} 中拥有<favorite lib> 的旧副本，而您将<favorite lib> 的更新副本放在/usr/local/{include|lib} 中。某些库需要它，例如 OpenSSL。 Apple 仍然发布 EOL/Abandoned OpenSSL 0.9.8。