本文的起因是：我近来渐渐多的收到了一些同学来信，让我帮忙看看编译log，然后帮忙查查错。其实这个事本身没有什么大不了，能帮的我也随手帮了，但是由于这方面的请求逐渐增多，我也意识到这里面存在的问题：
1. 大多数同学脸皮比较薄，所以都是直接给我发信寻求帮助而不是在论坛留言，这样的话，往往同样的问题我回答了多次，于我而言则是多做了许多重复的工作；
2. 有些同学发信给我，而我做出解答后，偶尔会陆续来信继续寻求帮助，对我形成了一种依赖。然而缺少独立和深入的思考，在技艺上如何能取得进步呢？于人而言，我的有限帮助反可能对其发展造成了一定的负面影响；
3. 有些具有代表性的问题，如果可以总结成文并敞开来让人搜索，而不是私下发信，是能够帮助到更多的人的；
4. 有些同学，恐怕是初学者，在连makefile等基本知识都不太明白的情况下，就直接上手这么大一个项目，力有未逮，需要一个台阶帮忙他们获取相关的知识和技巧。
因此，我决定在这里写下这篇文章。文章标题限定了Mac OS系统和MobileVLC项目，只是因为我不想让讨论的范围过大以致脱离掌控，而其实本文通用于绝大多数系统和软件项目。只要能学着举一反三就好。
文章的脉络就假定为如下场景：一个学了几年编程的菜鸟，懂编程语言但是没有做过项目，可以在terminal下敲命令但是能熟练运用的命令不多，但是却要求做一个基于MobileVLC的二次开发小项目。有点两眼一抹黑的情况下，应该如何着手呢？且跟我来：
(图片来自网络)
1. 上手
这里本应从面对新的操作系统和开发环境来讲起，但是想想又作罢，毕竟是一个太大的题目了，如果有机会以后续写。当然，续写的几率不大。这里假设我们的主人公经过艰苦卓绝的训练，已经在新的操作系统中配置好了编译环境，然后可以打开terminal在里面敲命令了。
有了系统和开发环境，下面就是MobileVLC这个项目了。初接手一个项目，项目主页的描述，下载包中的README和INSTALL等文件，都是需要仔细阅读的。现在开源项目这么丰富，任何时候我们都不是一个人在战斗，即使像chromium和android这样的高端产品，其中也聚合了很多开源资源。由此可见，阅读开发文档和编译已有项目，已经算是一个很重要的技能了。
回到MobileVLC，经过一番搜索，主人公找到了源文件所在位置：http://www.videolan.org/vlc/download-ios.html以及开发指南：http://wiki.videolan.org/MobileVLC。有了源代码，耐心读了编译步骤，主人公大概了解了源代码的大概功能划分以及编译顺序。接下来，就可以动手了。
Tip1.1：注意开发环境的统一，曾有在windows下写脚本，然后在mac下运行，却因为本文格式的问题不认的情况；
Tip1.2：避免文件夹的名称中含有空格。不管有空格有没有坏处，没空格至少没有坏处不是？
Tip1.3：仔细读README和INSTALL文档
2. 编译工具
大多数的开源项目都使用了GNU开发编译工具。（早期xcode也是，不过4.x以来，已经渐渐放弃了GNU。不过这对编译的影响较小。）对于Unix项目开发比较陌生的同学，可以看看这里了解autotools是如何配置开发环境和编译选项的：http://en.wikipedia.org/wiki/Autotools（注：篇幅不长）
很多小项目的编译都是两步曲：configure和make，前者配置当前开发环境，后者实际编译。
不少同学曾纠结于Makefile，大概源于学编程语言时的练习作业，有时得自己写makefile。不过其实现在的大小项目，Makefile都是自动生成的。Makefile所设定的开发环境，是configure生成的；而Makefile所设定的编译依赖，是automake自动生成的，所以一般来说Makefile出问题的几率不是很大。大多数的错误，还是来源于操作系统平台和编译环境的细小差异上（一如我关于MobileVLC编译的几篇文章中所列举的原因）
Tip2.1：修改了某个文件，但是不确定是否编译了。方法是删掉源文件所对应的目标文件.o，以及其上各生成文件，然后编译
3. 脚本
稍微大一点的项目，也许最终文件的构成就会比较复杂了，需要编译若干lib，然后最终绑到一起打包成最终文件。这时候少不了用脚本，比如MobileVLC的编译终究会用到2个脚本。
脚本的好处且略，脚本的坏处也有一点点：对于刚接手项目的人而言，脚本往往隐藏了过多的细节，需要再抽丝剥茧的还原出原作者的意图。
Tip3.1：如果脚本执行出错，可以尝试将脚本中的命令一条一条按顺序敲在terminal中执行，以定位问题；
Tip3.2：脚本执行后的log，可以很大程度上帮忙查错。而且现在的工具都太强劲了，存log往往只需要“保存”之即可。老黄历的各种通道啥的，大多时候可以休息了；
Tip3.3：分析脚本log中的错误，往往并不是从最后开始。因为一旦脚本前期出错，那么后面一大票的命令可能会接着出错，产生出毫无价值的大量log（当然，不同水平的人写出来的脚本是完全不同的）
Tip3.4：搜索关键字虽然很重要，但是最终的杀手锏依然是静心下来一行一行的读
Tip3.5：找到出错信息后，google（注意：是google，最好https）之。keep in mind，你永远不是一个人在战斗。另：stackoverflow是现阶段的神站
Tip3.5-1：google的小技巧：最开始，你可以把整行出错信息敲进去搜，如果碰巧你找到同样问题的答案，就赚了；如果找不到，逐步删除出错信息中的一些比较特例的单词（比如文件名行号啥的），直到能在google中找到类似的错误问题；
Tip3.5-2：这里有一些google搜索技巧：最值得一看的几条简单的谷歌 Google 搜索技巧，瞬间提升你的网络搜索能力！(http://www.iplaysoft.com/get-more-out-of-google.html)
Tip3.6：因为下载的项目其实都是别人能成功搞定过的，所以其实遇到的大部分问题都是：目录错了、参数有问题、文件找不到、版本不对劲等等，绝大多数情况下用不到修改代码。因此，对项目不了解有什么关系呢，编译就是去了解的开始。
有需要以后再更新