试图在没学过C#的前提下编译GARbro。

遇到的坑：

1. SchemeBuilder可以直接删掉；

2. 该项目似乎历史久远，项目的sln文件还是VS2013版本建立的，但是NuGet在VS2017版本开始，成为了VS的内部组件之一，对于项目.csproj文件的内容有着不同的要求。以前的版本似乎是要求一定要有.nuget/NuGet.targets文件，但是新版VS不需要也无法产生该文件，这时候可以通过用文本编辑器直接删除配置文件中的相关部分解决可能出现的报错。

   问题根源的代码段：

   <Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />
   <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
     <PropertyGroup>
       <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
     </PropertyGroup>
     <Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
   </Target>

   当然，两者相对位置自由，只要删了这两段就没问题了。

3. 不知为啥我坑爹的VS2019没有自带nuget.org的在线源= = 弄了老半天说找不到包，结果一看只有一个100多M的离线本地源。。添加方式见：https://docs.microsoft.com/en-us/azure/devops/artifacts/nuget/upstream-sources?view=azure-devops

   这里只留一个关键信息，防止官方文档翻车-> https://api.nuget.org/v3/index.json

前情提要

这回在tf官方repo发现有人问了类似的问题，给出的建议是按照推荐的编译环境操作一遍。然后因为C盘红了，就装了一个2017的build tools（微软官方提供的，不带IDE的编译器）。

这回好了很多，一口气跑到了1w+的target，越过了之前不到800必红的诅咒（ERROR）。

结果给我来一句

ImportError: Could not find 'cudart64_.dll'.

然后又红了？？？

然后找到一个别人发的issue：https://github.com/tensorflow/tensorflow/issues/29831。

发现设置环境变量没有用。照样报错。后来有人在下面建议用bazel自带的环境变量定义方式来传递：

build --action_env TF_CUDA_VERSION="10.1"
build --action_env TF_CUDNN_VERSION="7"

把两个--action_env和参数一起传进去之后，编译居然重新开始了= =
估计是之前参数压根就没传进去吧。。等编完看结果了（我不想再写第四篇了555）

====================================
第二天更新

编译成功了！Ура!!

然后可能遇到的问题是，cmd下的unzip命令好像有点问题，解压会漏文件，到MSYS2下去执行最后的build_pip_package.sh即可避免问题。

终于不坑了！系列完结！（真就编译器版本的问题呗）

====================================
2020/4/17

今天编译东西的时候顺便看了一下，似乎是可以不用装VS2017的，实际上在本次与之前编译的区别在于使用的编译器版本不同，VS2019默认的编译工具集是v142，而VS2017是v141。但是实际上是可以在VS2019的安装器中找到v141编译器工具集的选项的。因此推测，直接在VS2019中安装v141版本的工具集，然后在编译的时候指定编译器版本，也是能够正常编译的。有待测试。

问题出在CMake上。作者在写CMake脚本时使用了perl，这个工具在Linux发行版一般会自带（太常用了），但是Windows就没有。粗略看了一下，做了的工作至少包括了调用objcopy，这也恰好是出现LNK2017的原因，明明读取到了openblas.obj但是找不到符号。

解决方案一目了然，给Windows平台上安装perl环境即可。个人解决方案是直接借用了texlive里的tlperl包，可以成功完成任务。

翻车历史见这里

我胡汉三又回来了！！

编译的版本是Tensorflow 1.14。

为什么不用2？因为据说API大改，一堆坑。
像我这种改别人代码跑跑的肯定用不得

这次遇到的问题：

1. 需要按照要求装MSYS，并且要使用MSYS2环境而不是MinGW环境（Github for Windows提供了MinGW，但是没有pacman）；
2. 记得适当修改bazel的缓存位置（真香），每次运行命令时使用选项--output_user_root，避免把缓存写在叠瓦技术(SMR)的机械硬盘上，那速度慢得爽的飞起；
3. LLVM更新速度过快，而且现在已经更改项目名为llvm-project（之前是llvm），尽量使用和tensorflow发布时间相近的LLVM快照（时间过久会失效，但这不像Github的风格啊= =），在${PROJECT_ROOT}/tensorflow/workspace.bzl中可以找到并修改引用的LLVM版本；
4. 截至Tensorflow 1.14和本文撰写时（2020/2/8），XLA和nccl是不支持Windows平台或者支持的不是很好的（不折腾的话，几乎无法编译成功），不建议启用这两个特性；
5. （某些特殊版本）需要修改${PROJECT_ROOT}/.bazelrc中，把build:cuda中--define=using_cuda_nvcc=true注释掉，因为在Windows平台上不能使用--config=nonccl选项取消使用nccl，会报错；
6. 有时候会遇到error C2993: 'Derived': 非类型模板参数 '__formal' 的不合法类型。在pytorch的issues里找到了类似的问题，说是由于依赖关系和多线程编译竞争带来的问题，设置为单线程编译--jobs 1可以解决问题（未测试）：https://github.com/pytorch/pytorch/issues/25393；

=============================================================

20200216补充

算了，放弃了，一直说是Eigen有问题，好像是关于GPU设备代码上找不到std::conj定义一类的问题。这几天网上冲浪的时候发现风评CUDA nvcc对于STL的支持很差，可能与这个有关。但是有dalao硬是编译出来了，就很不服气。在个人笔记本上编译特别浪费时间，1-2h起步，而且从来没成功过= =。等这波病情过去，借到好点的CPU资源再说吧。

没看文档，看别人写的时候有点懵，顺便记录一下。

add_library(<name> SHARED ${<LIBNAME>_SRC})

比如说项目顶级目录为/project，按照CMake的文件夹结构，下面应该有一个src子目录存放所有的源码，则用add_library命令调用的方法是add_library(project SHARED ${project_SRC})。

其中project_SRC代指的就是/project/src这个目录，变量名不用预先定义。

又是一个自由的，变量名有特殊含义的编程语言= =