Tensorflow的编译工程化做得不好，主要表现以下几个方面
- 工程的依赖库默认从远程下载，而对于网络条件不好或中国地区用户，无法获得远程的依赖；且在repo.bzl中固化了mirror.tensorflow.org字样的代码，导致无法替换有效的镜像地址；
- 工程编译速度非常慢（64Core大于10分钟），由于所有依赖都采用源代码进行编译，虽然编译工具bazel有缓存，但是仍然非常之慢；整个源代码编译在一个库里，好处是对于不同的操作系统，尤其是分布式集群，分发看似方便一些，不需要依赖安装，但同时带来了隐患，依赖缺乏有效管理，导致底层的依赖有问题，需要升级，是很难覆盖，且不知道tensorflow依赖它；
- 工程依赖可视化管理比较差，上述已经提到，由于bazel的基因它只是一个编译工具，但它又想把依赖这件事情做好，具备很好的灵活性，有点像node和go库，但对于C/C++工程来说，每个库是远远比node和go库重一些，且很多是多层多次依赖，一般由操作系统来进行包的依赖管理，但bazel想自己做成一个王国，就有点勉强了。
回到tensorflow上来说，很现实的问题，系统的protobuf库使用的是高版本，而tensorflow 1.15.5版本内置的protobuf源码版本很低，如果tensorflow版本默认编译，低版本的protobuf符号会连接到tensorflow的库中，当我们应用需要protobuf高版本以及tensorflow库时，该应用的编译和连接没有问题，但运行时，会出现protobuf符号连接版本问题，那么这个时候需要解决版本冲突问题，当然问题不仅仅只有protobuf库，其他的库也是一样；故需要去指定系统环境的依赖库达到目的，由于bazel只有基本语法规范，但重要的还是tensorflow本身自己的编译工程需要去解决。
前面提到了tensorflow工程上的一些问题，对于系统提供的库，我们需要额外的cc_library和new_local_repository来代替new_http_archive，幸运的是，tensorflow考虑到了本地系统的依赖库，其配置在third_party/systemlibs中，syslibs_configure.bzl文件中有详细的依赖说明，故根据源文件查到环境变量TF_SYSTEM_LIBS来控制那些第三方依赖使用系统的库，故编译选项如下：
bazel build --action_env TF_SYSTEM_LIBS='boringssl,com_google_protobuf,grpc,zlib_archive,pcre,jsoncpp_git,curl,com_googlesource_code_re2,snappy,hwloc,lmdb,org_sqlite' --copt=-mavx2 --copt=-mfma --copt=-mavx512f //tensorflow/tools/lib_package:libtensorflow
即解决依赖库用系统已经编译好的库的问题
