不同编译器头文件搜索路径差异：如何调整CL与GCC的包含规则？

你碰到的这个问题，核心是MSVC（CL编译器）和GCC对#include "xxx.h"的搜索逻辑不一样：MSVC会额外把当前编译的源文件所在目录加入搜索路径，而GCC完全遵循C++标准，只先搜头文件自己的所在目录，再搜系统路径。这就是为什么folder/header2.h里引用header1.h在CL下能成功，GCC里却报错的原因。

一、让CL/Visual Studio禁用这个非标准行为 #

要让MSVC老老实实按标准来，有两种靠谱的方法：

1. 用编译器选项/X #

/X会直接禁用所有默认的包含路径，只认你用/I显式指定的目录。不过这么做需要手动加系统头文件的路径，有点麻烦，但胜在严格符合标准。
举个编译命令的例子：

cl /X /I. main.cpp

这里/I.是把项目根目录加入搜索路径，保证header1.h能被找到，同时MSVC不会再偷偷把编译源文件的目录加进去。

2. 在Visual Studio里设置头文件属性（适合IDE用户） #

如果你用VS开发，可以给特定头文件设置「外部头文件」属性，强制编译器用标准逻辑处理它：
右键点击folder/header2.h → 「属性」→ 「C/C++」→ 「常规」→ 「外部头文件」→ 改成「是」
这样编译器处理这个头文件时，就不会再用MSVC的非标准搜索规则了。

另外提一句，你用Clang编译时看到的-Wmicrosoft-include警告，就是专门针对这种非标准行为的，CL里开/W4级别的警告也会提示类似问题。

二、让GCC模拟MSVC的搜索行为 #

GCC默认不支持MSVC的这个扩展，但我们可以手动模拟：

直接用-I指定编译源文件的目录 #

最简单的办法就是编译时把项目根目录（也就是main.cpp所在的目录）加入包含路径：

gcc -I. main.cpp

这样GCC处理folder/header2.h里的#include "header1.h"时，就会去项目根目录找，效果和MSVC完全一样。

进阶：用宏实现动态路径（适合复杂项目） #

如果项目结构复杂，不想每次手动写-I路径，可以搞个小技巧：
先写个msvc_compat.h文件：

// 提取当前编译文件的所在目录
#define __FILE_DIR__ __FILE__
#define __FIND_SLASH__ strrchr(__FILE_DIR__, '/') ? strrchr(__FILE_DIR__, '/') : strrchr(__FILE_DIR__, '\\')
#define __CUR_DIR__ (__FIND_SLASH__ ? (__FIND_SLASH__ + 1) : __FILE_DIR__)
#pragma GCC system_header

然后编译时用：

gcc -imacros msvc_compat.h -I. main.cpp

不过这种方式有点绕，一般项目直接用-I指定路径就够了。

最后补个知识点 #

C++标准里明确规定，#include "filename"的搜索顺序是：先在当前头文件所在的目录找，找不到再去系统包含路径搜。MSVC的那个额外搜索编译源文件目录的操作，属于它自己加的非标准扩展，虽然方便但会影响代码的可移植性——这也是为什么Clang会专门给个警告提醒你的原因。

内容的提问来源于stack exchange，提问作者Teivaz