What's going on with clang's include priorities?

问题

My command:

/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 has:

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

Output:

  /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 \

However, there exists: /usr/local/include/opencv2/core/core.hpp, and /usr/local/include/opencv2/ml/ml.hpp.

Using the -v flag, clang tells me:

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)

Why is clang including from /opt/local/include instead of /usr/local/include, despite /usr/local/include coming first in the list of -I directories in the command? Why is /usr/local/include pushed down the priority list.

回答1:

You can check the default search path for #include by:

gcc -Wp,-v -E -

(give the -v flag to the preprocessor).

Your directories (given with -I) are searched before the standard list, in the order you give them.

You give /usr/local/include explicitly, and gcc disregards your instruction because it will be added (as a system directory) later on anyway; thus the directories are searched in the wrong order. If you really want to control the directories searched yourself, use -nostdinc and give them all. That is extremely fragile.

To have two sets of header files with the same names is a very bad idea (as you found out). No way to clean up that mess?

来源：https://stackoverflow.com/questions/22178946/whats-going-on-with-clangs-include-priorities

标签

clang

include-path