零修改源码迁移makefile项目时，为何Bazel识别不到.bazelrc定义的头文件路径？

核心原因 #

手动执行Bazel输出的gcc命令能编译成功、但Bazel自身构建失败，本质是Bazel沙箱的路径隔离逻辑和手动执行命令的运行环境完全不同：

1. 写在.bazelrc里的-Ia/b/c是相对路径。Bazel编译单个源文件时，沙箱的工作基准目录是沙箱自身的临时输出路径，不是项目WORKSPACE根目录，这个相对路径在沙箱内会被解析成不存在的空目录，自然定位不到头文件。
2. 手动执行gcc时，运行目录是项目WORKSPACE根目录，相对路径a/b/c能正确映射到真实项目路径，所以可以正常完成编译。
3. 就算把-I的路径改成绝对路径也无法解决问题：沙箱默认只会把当前目标srcs、hdrs列表内的文件挂载到沙箱对应可访问路径下，手动指定路径内的文件不会被自动同步进沙箱，编译器根本没有访问权限。

不需要改动现有源码的头文件包含写法，完全依赖Bazel原生机制即可适配，也不需要给每个目标重复写copts：

单目标快速配置 #

修改对应目录下的BUILD文件，给cc_library增加includes属性，直接指定需要映射为头文件搜索路径的目录：

cc_library(
  name = "lib",
  srcs = ["c/1.cpp"],
  hdrs = ["c/1.hpp"],
  includes = ["c"],  # 核心配置
  visibility = ["//visibility:public"]
)

配置生效后的效果：

• Bazel会自动把c目录转换为沙箱内的绝对路径，生成正确的-I参数传递给编译器
• Bazel会自动把该目录下的所有头文件挂载到沙箱的可访问路径下，不会出现文件找不到的问题
• 这个头文件路径配置会自动传递给所有依赖当前库的下游目标，不需要下游重复配置搜索路径。

跨多目录的全局扁平结构适配 #

如果项目里的头文件分散在多个深层目录、都采用单层无路径的include写法，可以在WORKSPACE根目录下创建一个专门的头文件聚合cc_library，把所有需要作为扁平搜索路径的目录列在includes列表里，所有业务目标统一依赖这个聚合库即可：

# 位于WORKSPACE根目录的BUILD文件
cc_library(
    name = "flat_include_roots",
    includes = [
        "a/b/c",
        "d/e/f",
        "src/util",
    ],
    visibility = ["//visibility:public"],
)

后续所有业务目标只需要把//:flat_include_roots加入deps列表，就能自动获得所有头文件搜索路径配置，完全不需要每个目标单独写copts。

之前在.bazelrc里写的build --copt=-Ia/b/c存在两个硬伤：

• 相对路径的解析结果依赖执行bazel命令的当前目录，不同执行场景下路径解析结果不一致，稳定性极差
• 绕开了Bazel的文件依赖追踪机制，对应路径的内容不会被自动同步进沙箱，在隔离构建环境下本质上无法正常工作。

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