CMake、Make及g++编译C++项目时同名头文件的选择规则咨询

首先得明确：你当前项目能编译运行不是偶然生效，但确实依赖于编译器和构建工具的具体实现规则——C标准对#include "..."的查找顺序没有做强制统一的规定，但主流工具（g/Make/CMake）都遵循一套约定俗成的逻辑，下面逐个拆解：

一、g++的核心查找规则 #

作为最终执行编译的工具，g的头文件查找逻辑是底层基础，Make和CMake都是通过给g传递参数来间接控制这个过程的：

对于#include "System-Libraries.hpp"（双引号形式） #

g++会按照以下顺序查找：

• 当前编译的.cpp文件所在的目录：比如你编译src/main.cpp，会先在src/目录下找这个头文件
• 所有通过-I参数指定的目录：按照你传递-I的顺序依次查找（先写的目录优先）
• 系统默认的头文件目录：比如/usr/include这类系统级路径

对于#include <System-Libraries.hpp>（尖括号形式） #

会跳过当前.cpp文件的目录，直接从-I指定的目录开始查找，最后才查系统目录——这也是双引号和尖括号最核心的区别。

二、Make的处理方式 #

Make本身不直接处理头文件查找，它只是负责按照你写的Makefile规则调用g++。所以头文件的选择完全取决于你在Makefile中给编译器设置的CXXFLAGS（C++编译参数）里的-I路径顺序：
比如你的Makefile里写了：

CXXFLAGS += -I./src/core -I./third-party/utils

那么g++会先在./src/core里找System-Libraries.hpp，如果找不到才会去./third-party/utils里找，以此类推。

如果你的Makefile里没有显式指定-I路径，那g++就只会查当前.cpp目录和系统目录——这时候如果两个同名头文件一个在当前目录，一个在系统目录，当前目录的会被优先选中。

三、CMake的处理方式 #

CMake是更上层的构建工具，它会把你的配置转化为对应的g++参数（也就是-I路径），但提供了更清晰的路径管理方式：

1. 推荐方式：target_include_directories
   针对具体的目标（可执行文件、库）设置头文件路径，路径顺序就是查找顺序，比如：

   add_executable(my_project main.cpp)
   target_include_directories(my_project PRIVATE 
       ./src/core 
       ./third-party/utils
   )
   

   这里PRIVATE表示这些路径只作用于my_project这个目标，g++会先查./src/core，再查./third-party/utils。
2. 全局方式：include_directories
   这个命令会把指定路径添加到所有后续目标的搜索路径里，顺序同样是先写的先查，但不推荐使用——因为会污染全局配置，容易引发意外的头文件冲突。
3. 环境变量辅助
   CMake还会读取CMAKE_INCLUDE_PATH环境变量里的路径，把它们加入到搜索序列中，优先级低于你显式指定的路径。

关于“是否符合标准”的补充 #

C标准只规定了：#include "..."的查找方式由编译器实现定义，而#include <...>必须从标准系统头文件目录查找。所以你当前的情况是符合g的实现规则的，但如果换了其他编译器（比如某些小众编译器），可能会有不同的行为——所以这种“依赖顺序的同名头文件”场景还是存在风险的。

建议的优化方案 #

• 尽量避免在不同搜索目录下放同名头文件，从根源解决冲突
• 如果必须保留，要么用相对路径明确指定（比如#include "./core/System-Libraries.hpp"），要么调整CMake/Make里的搜索路径顺序，确保你需要的头文件被优先找到
• 或者给不同的头文件内容加上不同的命名空间，即使头文件名相同，也能避免代码逻辑冲突

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