为什么80%的码农都做不了架构师？>>> 
大家可能觉得很奇怪，cocos2d-x引擎库的编译不是很简单嘛？不就是下载源码包，解压并打开vs工程，分别对debug跟release两个版本按一下编译就好了吗？对的，编译就这样就完成了。不过，我发现这样编译出来的库好像“移植性”不是很好，不能直接拷贝到另外一台电脑直接使用。于是，我尝试将这个编译好的引擎库变得更加的有“移植性”，并分享这个过程。
（这里的“移植性”之所以用分号，是因为这不是说这个库不能移植到不同平台，而是说不能知道拷贝到其他电脑，然后直接使用。）
-------------------------------------------------------------
首先，说明一下我为什么要干这个引擎库拷贝的事情。是这样的：我本来有个台式机，已经配置好cocos2d-x环境了，然后最近买了手提。于是我想在手提上也装个cocos2d-x环境。然后我想，既然cocos2d-x是一个C++编写的函数库（引擎框架），理论上应该是可以直接拷贝到另外一台电脑使用的。于是我把台式的编译好的cocos2d-x库拷贝到了手提，结果编译一个HelloWorld都要整个cocos2d-x重新编译一次。所以，一台电脑编译，拷贝到另一台电脑使用的想法似乎有问题。
-------------------------------------------------------------
其实，在一台电脑编译，拷贝到另一台电脑使用的想法是没问题的。很多C++的函数库的编译好的版本（binary）不就是这个意思吗？cocos2d-x的之所以出问题，是cocos2d-x本身提供能的工程模板的依赖项的参数设置有一些问题。
我们通过cocos2d-x包中的tools目录下的create_project的python脚本来创建cocos2d-x项目，打开新建的项目，我们发现里面不但有我们想要的那个工程，还有libBox2d， libExtensions等好几个工程，它们对应为我们所要用到的cocos2d-x框架的库。它们跟我们想要的工程放到同一项目，我们的项目依赖于它们。在链接的时候，我们的工程会到它们那里查找想要的库。这样，我们的工程就可以使用这些库了。右击这些库工程，查看属性，点开“Build Events”，它们大部分都有定义“Pre Link Events”的操作。基本都是<if not exist "$(OutDir)" mkdir "$(OutDir)" xcopy /Y /Q "×××××" "$(OutDir)">。这就使得在第一次链接的时候，由于还没有输出的文件夹，所以它会新建输出文件夹并将这几个依赖库的lib跟dll等都复制到项目的输出文件夹中。这样，我们的工程就能够使用这些lib库来链接编译了。
一切看上去都很好的发生着。不过，其实这种在同一个项目中多个工程，并且我们的工程以来其他库工程的做法，正是cocos2d-x编译包不能拷贝到其他电脑直接使用的原因。因为，在我们把整个编译包拷贝到别的地方的时候，那些库工程的路径其实是发生了变化，vs在检测路径变化后，它会认为工程变化了，代码需要重新编译，所以，我们的cocos2d-x源码就要重新编译了。为了解决这种路径变化，库工程重新编译的问题，我们需要做的就是移除以来的库工程，直接指定我们想要用的库的位置就行了。因为我们的库其实早已经编译好了。
我们来看看怎样消除我们项目对库工程的依赖。我们的项目是通过create_project.py脚本来创建的。打开这份代码看一下，（虽然我不会python，但是大概知道它想要干什么。）它的作用就是复制cocos2d-x包下template目录下的其中一种模板（如cpp）到project目录下，并将工程的名字修改为我们想要的名字。所以，理论上我们只要去除template中项目（我修改的也只是cpp模板的）项目对库工程的依赖性，后续创建的项目也就不会以来库工程了。
打开template\multi-platform-cpp\proj.win32下的HelloWorld.sln，右击solution，查看其属性，在configuration properties中，我们看到我们的项目依赖其他几个库项目。关闭属性，在Solution Explorer中，逐一右击我们的库项目，点击remove来将它们移除出工程。这是，我们项目对库项目的以来也自动消失了。但是，我们的项目会因为找不到我们想要的函数库（cocos2d-x库以及box2d库等）而不能编译。所以我们还要为项目指定函数库的位置。假如配置过C++函数库的朋友，可能对接下来的步骤非常熟悉。右击HelloWorld项目，打开属性，点开Linker->input。我们看到已经有了要用的函数库（lib），只是项目不知道这些库放在哪里。再点开VC++ Directories，看Library Directories项，为它添加一个值，为..\..\..\Debug.win32或..\..\..\Release.win32（根据你设置的是Debug还是Release模式下的属性而定）。它使用相对路径，指定我们编译好的cocos2d-x库的所在目录。这样，我们的项目就可以找到相应的lib并编译和链接，并且不会因为cocos2d-x包的位置变化而重新编译库了。但是，我们的工作还没完成。因为在运行的时候，会因为找不到相应的dll而无法运行。配置过C++函数库的朋友可能会想，把cocos2d-x编译出来的dll都放到system32下吧。这是一种方法，但有点违背我刚开始想要的“移植性”。因为拷贝到另外一台电脑，又要重新将dll复制到system32了，并且cocos2d-x库编译出来的dll数量还是比较多的。这里，我使用的方法不知把dll复制到system32，而是在编译的时候，让vs自动把dll复制到我们的项目输出目录。因为dll也不算大（debug跟release版的基本都是10
m左右），并且不用手动配置，且我们不想要cocos2d-x库的时候，整个文件夹删除就可以了，不用污染到system32文件夹。实现方法是在项目的Build Events下的Pre Link Events添加操作脚本<if not exist "$(OutDir)" mkdir "$(OutDir)" xcopy /Y /Q "$(ProjectDir)..\..\..\Debug.win32\*.dll" "$(OutDir)"
>.
至此，我们对模板项目的修改完成。注意，我们是在修改模板，所以不要按下编译键。并且关闭vs后，将模板文件夹下本来没有的一些vs自动生成的文件删除。这样，我们的“可移植”的cocos2d-x库就制作完成了。
-------------------------------------------------------------
虽然，我用“可移植”这个词。但其实还是有很多限制的，例如想要使用编译好的cocos2d-x库的人的电脑要使用跟首次编译cocos2d-x库的人的电脑的vs版本相同，至于操作系统版本似乎也有关联。例如，我在台式机win8 64位上通过vs2012编译并制作的可移植模板，拷贝到我的手提win8 64位上，使用vs2012是可以直接使用cocos2d-x库而不用重新编译的。但我拷贝到一台win7 32位使用vs2010的电脑是是不能使用的。
所以，使用win8 64位vs2012的朋友，有兴趣可以下载下面链接分享的可移植包，看看是否真的能够直接使用：
http://pan.baidu.com/s/1GMe30
为了使压缩包小一点，我把编译好的sample整个给删掉了（我对编写sample的大神表示万分的尊重）。还有也删掉了其他一些除Windows跟android项目的编译好的库。
还有，这个包理论上只要下载后，运行project目录下的new.bat，即可生成工程，然后打开工程即可成功编译。（这里的new.bat实际上还是调用create_project.py的，所以还是要安装python环境的。）
而使用其他配置的windows的朋友，可以尝试下面链接，是修改后的模板工程。
http://pan.baidu.com/s/1CItkV
理论上，只要你编译好cocos2d-x源码包，并将这个模板工程替换源码包的模板。然后你就可以将你编译好的包分享给别人了，其他使用系统配置跟你一样的朋友就不用再编译了。
-------------------------------------------------------------
最后，我说说我对cocos2d-x中模板原来使用工程依赖做法的看法（也只是我的个人看法，我猜猜而已）。这其实不是一个错误或者是一个失误，而是另外一种思路。它为引擎库使用者提供了更大的自由度，并且鼓励我们修改源码。因为，假如我们有什么特别需求，需要修改引擎源码。那么，依赖的库工程会检测到源码被修改了，库便会被重新编译，以达到我们想要的效果。可以说，这其实是一种更高明的做法，一种针对更高要求的框架使用者的处理方法。不过，对于我这种渣渣普通使用者，很多时候我是想要开封后即可使用的编译好的库，无需繁杂的配置跟漫长的编译。所以，我还是希望有人能够做这种预编译好的库，能够让我这种懒人使用者来用的。