GYP是google的一套构建系统，和 cmake 的目的很像。GYP和CMake的主要作用是，从用户编写的一套配置文件，针对不同的工具链生成不同的项目文件（如Makefile/vc projects/xcode projects）。
下面是GYP的配置文件的示例：
{
‘targets’: [
{
‘target_name’: ‘hello’,
‘type’: ‘executable’,
‘sources’: [
‘main.cpp’
]
}
]
}
看上去基本就是一个json。它定义了一个名为hello的target。target的类型是executable，表明它是一个可执行文件。如果要编译库，就换成static_library或者shared_library。sources是一个数组，列出所有的源文件。
然后用
# gyp hello.gyp —depth=. -f make
生成makefile。
然后执行make命令即可。
从设计目标上来说，它和autotools还不大一样。autotools只针对make，且仅限于gnu make。autotools的核心是autoconf，如何利用shell脚本在不同的操作系统环境下生成相应的config.h文件。它利用它强大的检测功能很容易适应不同的Unix/Linux环境。
而GYP和CMake都支持各种主流的构建系统。如make/Visual studio/XCode/Ninja。CMake支持构建系统的种类要更多些，比如eclipse cdt、Sublime Text 2、CodeBlocks、Borland C++等等。而这些非主流的东西GYP压根就不会去碰，不敢碰。
按最理想的情况，我们写一套配置规则，在所有平台上都能执行。此时我们可以不关心操作系统是什么。拿autotools来说，假如你要include某个头文件，那么就在autoconf执行的时候检查下有没有这个头文件，然后在真正使用的时候，利用ifdef/else/endif来条件编译，假如有，我们就用它，没有就砍掉某个功能，或者使用替代实现。由于unix种类甚多，差异甚大，按照这样方式写的程序，即便被扔到一个作者从不知晓的陌生环境里，（也许）也能正常运行。
cmake和autotools都是这样的理想主义者，它们试图把不同的工具链的相同部分抽象出来，用一套统一的配置文件来适应不同的平台。迫不得已的时候你可以写 if(OS==WIN) … else if (OS== Linux) … 。 于是就这样工作了很多年，很好。而GYP觉得我们不该做这样的过分抽象，构建系统自身应该简洁，把适应不同平台的事情交给程序员自己去做。比如，不同的工具链参数不同，gcc编译多线程程序的时候要加-pthread或-pthreads或-lpthread，而vc则要在4种不同的CRT做出选择。那么，你自己去把不同平台的编译参数挨个标明，GYP不管这事。所以，GYP的项目不可能盲目的去支持Sublime Text 2、eclipse cdt这样的小众玩意儿。为了支持它们，condition会急剧膨胀。
GYP是为Chrome项目开发的，Chrome也是GYP的唯一成功案例。就比如前面编译hello world的时候，加上“—depth=. ”，这完全是Chrome的特殊遗留。Chrome是一个有600多万行代码的大型C++项目，它的成功值得借鉴。Chrome在跨平台问题上采用了一个很有趣的事情，把第三方库的源代码copy到现有项目中，并且静态链接进来。相当于，Chrome为它所有用到的第三方库都做了SVN一个分支，在需要的时候与上游同步。然后它为所有的第三方库都生成了一个GYP项目文件，然后在Chrome中引用这些第三方库的项目文件，完成构建。比如，不管你操作系统有没有装libevent版本是多少，我都用我自己带的这个，然后最终链接成一个无比巨大的exe或ELF文件。所以你可以理解，为什么chrome在link的时候会让很多机器挂掉了吧？
我非常赞同Chrome的这种做法。有些第三方库的接口变动非常快，比如glib，单单为了在linux这一种操作系统下适应不同的glib版本，就得在代码中写大量的条件编译宏。查core dump的时候也困难很多，单是找源代码都能找死一批人（别忘了发行版喜欢 编译前打自己的patch）。另一点是，构建系统本身也得以简化，我不需要去把autoconf/automake/cmake/scons等等全装一遍。最可恨的是，autotools自身还有很多版本，而且各不兼容。要把不同版本的autotools全装上，并且用起来互不干扰，也需要很大技巧。
虽然GYP和CMake相比还很不成熟，而且很不独立（它几乎是专为Chrome项目服务），但是Chrome本身其实已经给我们贡献了足够多的代码。虽然GYP不像CMake那样自带了很多Module（丰富的FindXXX），但是我们完全可以去Chrome的项目中把那些GYP文件挖出来。
另外，如果你想复用Chrome的代码，那么就得迁就GYP。比如apache的mod_spdy模块，它的SPDY协议的实现就是从Chrome中直接拿去的。为了引用Chrome的代码，mod_spdy就不得不采用GYP做构建。
原文链接: http://blog.sunchangming.com/post/63087027734
|
