为贡献与自定义开发优化的TensorFlow Bazel构建相关技术问询

1. Bazel支持完全可自定义的专属构建目标，和Make的逻辑完全一致 #

Bazel从设计上就具备和Make类似的、细粒度的目标指定能力，甚至依赖追踪精度比Make更高：

• 所有源码文件都会在对应路径下的BUILD文件中绑定具体的构建目标，小到单个单元测试、单个动态链接库，大到完整的pip安装包，都可以独立指定为编译目标，粒度可以精确到单个测试用例级别
• 不需要手动翻找BUILD文件，用内置查询命令就能一秒定位关联你修改文件的所有目标：bazel query 'attr("srcs", ".*你修改的文件相对路径.*", //tensorflow/...)'
• 举个实际场景：如果你修改了C++层的某个算子实现，完全不需要编译整个TF框架，只要指定对应算子的测试目标（比如tensorflow/core/kernels:xxx_op_test）就可以完成编译和逻辑验证，和Make单独编译某个.o文件的体验完全一致

2. TensorFlow的Bazel构建流程本身不会调用GPU资源 #

很多人会把编译流程和运行流程的资源需求搞混，这里明确对应规则：

• 从源码到二进制的全编译、链接环节，所有计算都依赖服务器CPU完成，不会用到GPU的算力
• 如果要在GPU服务器上构建带CUDA支持的TensorFlow版本，只需要在首次运行./configure配置环节，正确填写CUDA、cuDNN的本地安装路径，选择开启GPU构建开关，Bazel就会在最终的链接阶段把CUDA相关的依赖整合到产物中
• 服务器的GPU配置只会影响最终构建出的TF包能不能调用GPU做模型推理/训练，不会影响编译过程的速度。编译阶段你可以通过--jobs参数指定和CPU核数匹配的并行任务数，最大化利用服务器CPU资源缩短编译时长

3. 小幅度修改源码时的最快重编译方案 #

只要避开几个常见误区，小改动的编译耗时可以控制在秒级到分钟级：

• 不要随意删除bazel-*开头的本地缓存目录、不要强制开启无缓存的构建参数。第一次全量构建完成后，Bazel会基于文件内容哈希做精确的增量依赖追踪，只有和你修改的文件存在直接依赖的目标才会被重新编译，没有改动的目标会直接复用缓存产物
• 尽量缩小编译范围，不要一有改动就全量构建pip安装包。比如修改了Python层的接口代码，根本不需要重新编译C层，直接跑对应Python模块的测试即可；修改了C算子逻辑，先编译单算子测试用例做验证，逻辑全部跑通后再做全量的集成包构建
• 小范围逻辑验证阶段，可以临时关闭高等级的编译优化选项，跳过不必要的二进制体积优化、高级指令集支持检查，进一步缩短单轮编译的时长，等验证完成需要出正式构建包的时候再切回优化模式编译
• 如果是在固定的GPU服务器上做开发，可以给Bazel配置固定路径的持久化缓存目录，哪怕后续切换代码分支、调整其他无关文件，只要依赖的输入没有变化，就不会触发重复编译

独立TensorFlow贡献者的常规开发流程 #

所有长期参与TF代码贡献的开发者，都不会用全量重编译的低效方式做开发：

• 所有人都会默认开启Bazel的本地缓存，日常开发只针对修改的模块编译最细分的目标，不会动不动就跑全量构建。比如改了文档格式、Python层的类型注解，基本零编译耗时；改了单个C++算子的逻辑，只需要编译对应算子的测试用例即可
• 很少有开发者会在本地普通PC上做全量编译，一般会把高性能的Linux服务器作为编译节点，本地只负责写代码、做代码评审
• 针对有定制化修改需求的团队，一般不会直接追社区主线的每一次提交，而是维护一个精简的长期分支，把自有定制逻辑和社区代码做解耦，减少频繁同步代码带来的重编译量

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