工作环境
巧妇有了米炊
众所周知，Caffe是在Linux下写的，所以长久以来，大家都认为跑Caffe，先装Linux。
niuzhiheng大神发起了caffe-windows项目（解决了一些编译、API相异问题）
以及willyd大神发起的caffe-windows-dependencies项目（整理了依赖库，修正了LMDB在NTFS分区的Bug)
我们现在可以很欢乐地在Windows上研究Caffe源码，以及山寨它了。
编辑器
在Windows下涉及CUDA，Visual Studio必然是首选。如果问原因，这是NVIDIA官方的推荐。
CUDA最初使用的语言，除了二进制机器码，就是类似CPU汇编的，GPU汇编——PTX代码。
后来NVIDIA的工程师写了C接口，编译器称为NVCC。
NVCC相当有趣，它在编译前，需要对CUDA代码以及传统C/C++代码做分离。
这一步给模板(Template)分离式编程带来比较大的麻烦，C/C++编译器和NVCC编译器不共享某些知识，
所以你需要重复某些代码。（幸好我们有宏）
CUDA的地位与DirectX差不多，后者是MS为GPU封装的C++接口。
CUDA、OpenCL、DirectX旗下的Direct Compute并称为GPGPU通用计算的三个小王子。
当然，CUDA属于那种为了夺嫡开挂的小人，目前你看到的CUDA框架，只限于NVIDIA GPU，
因为它在设计的时候，没有从通用GPU出发，直接在自家的硬件物理架构上设计，所以优势很大。
再说Windows，玩过游戏的人都知道，NVIDIA和MS是多年友商了。
玩游戏有句信条：千万不要用Linux。这句话可以从两方面解释：
(I) NVIDIA为Windows全心全意做驱动程序，证据是Linux装显卡驱动曾经
是一个老大难问题，无数人抱怨，“NVIDIA就是MS的奸细”。
(II) 很少有开发者用Linux API写游戏(PC端)
这个现象最近有所改观，基础驱动和CUDA也为部分Linux提供了支持(Ubuntu)。
就连CES2016上，老黄演示无人驾驶系统Drive PX 2 Demo居然也是跑在Linux(Ubuntu)上。
似乎还被人看出来跑的是Caffe(疑似)，但不论则么说，NVIDIA现在是对Linux有所关注了。
为了体现与MS的友谊，CUDA几乎是与Visual Studio捆绑的，前提你得先装VS。
CUDA会把插件和配置直接自动写到VS里去。
配置NVCC和以及传统C/C++编译器相当繁琐，如果你是民间大神，可以尝试Vim或Sublime。
但是，最好不要这么作死，VS其实也不是很难用。
OS及VS
我个人在Windows10 Threshold 1下工作。
VS使用是Metro先锋VS2013，相当老掉牙的版本。（VS 2012及以下的UI相当丑，因为同年8月才出了Windows8）。
VS的默认工作模式是X64 Release。
依赖环境库
你的VS工作环境，决定了你的依赖库是如何使用的。
依赖库有“大三元”的说法：
如图，就是这三个目录，分别存着：动态库、引用头文件，静态库。
(I)先说说静态库，VS的静态库是lib文件，GCC的静态库是a文件。
静态库只能在编译阶段的链接器中使用，这与C/C++的分离式编程有关。
众所周知，C/C++倡导声明定义分离，这大大加快了整体编译速度，以及方便外部调用。
于是编译阶段分为两部门：先进行声明的分析，然后再把定义填充进去。
声明的全部内容通常是提供给外部的，是由零碎的头文件组成，你想用就#include就好了。
定义的内容，会被链接器灌装起来。根据灌装模式的不同，就出现了静态编译和动态编译两类。
根据生成内容的不同，又可以分为可执行文件生成和库生成两类。
利用笛卡尔积，我们大概得到四种模式：
★库生成，静态编译（ h文件+lib文件(VC) 或者h文件+a文件(GCC) )
★库生成，动态编译 (不存在)
★可执行文件生成，静态编译 (exe文件)
★可执行文件生成，动态编译 ( exe文件+dll or bin文件+so文件(Linux) )
其中第二种方式是不存在的。所以针对库生成而言，我们只需要h+lib/a文件即可。
它们应当分别放到include和lib文件夹中。
在VS中配置头文件/静态库很简单，分为两步：
★在工程属性-VC++目录中指定"包含目录"以及”库目录“，分别为h目录以及lib目录
★在工程属性-链接器-输入中，手动添加需要的lib文件
第二步相当重要，如果不做，那么编译是不会错的，但是在链接定义的时候，会找不到lib中的定义：
error LNK2001: 无法解析的外部符号
如果你的lib目录没错，那么试着找一找，是不是没有手动添加lib文件(VS不会自动扫描目录文件并且添加)
(II)再说说动态库，这个方式只有在选择了Release模式编译之后，才会使用。
先说说Debug和Release的区别。
Debug版本一般不用来发布，不仅是因为里面包含了Debug代码，而且没有做编译优化，性能有折扣。
但是有一点好处，就是可以断点、调试，但这非常麻烦。
由于外部依赖库的灌装，你要Debug你的程序，需要提供pdb符号文件，这意味着你得自己把所有依赖库
自己编译一遍，得到pdb文件，否则无法Debug，也就无法断点调试。
因为无法断点，所以Debug只能靠人工推理出断点（推测可能位置，加cout/printf语句测试）
还有一点，就是Debug版本在调试模式中的执行只需要lib文件，如图：
但是，一旦你把Debug版本的exe文件拿到别处，就需要dll文件了，这时候需要动态库。
Release版本则是强制使用动态库，就算是调试模式也无效。
在VS中配置动态库很简单，只要一步
★在工程属性-调试中，指定"环境"的值为：PATH=%PATH%;C:\xxx\bin
确保bin里存在需要的dll文件，否则OS会一致提示你缺少dll文件。
另外，Debug和Release版本需要的lib文件和dll文件均是不同的，不能混用。
一般文件名后补一个"d"，表示这是Debug版本的dll/lib。
教学用·快速依赖环境包
这个包仅教学使用，阉割庞大的Boost，直接无视了OpenCV(这东西其实没多大用)。
对于山寨Caffe，足够了。仅仅30MB，适合傻瓜。
强调，请用于： X64 Release
度娘：http://pan.baidu.com/s/1NeDrS
有问题邮箱@我：neopenx@mail.hfut.edu.cn
2016.2.18 更新lmdb.lib
-修正Win32平台下，set end of file error！的输出信息问题
解决方案是在lmdb源码的mdb.c里把这句printf注释掉。
这是一句毫无意义的输出信息，仅仅在Windows平台下被编译出来，强迫症患者可以选择尝试。