google v8 实战 -- 神秘的v8.vcproj
title: google v8 实战 -- 神秘的v8.vcproj
根据前文的说明，大家应该都可以把v8.lib编译出来了。
本文想再说说编译这个环节。因为区区在另外一台同样安装了VS2008和
python2.5的机器上，编译失败，而且败在v8.vcproj中的natives.cc上。打开这
个文件时要小心，连IDE都会警告说“这个文件包含巨长的文本行，可以会很慢”。
google的人很厚道地把natives.cc放在一个叫"generated files"的文件组中，就
说明这个文件其实是给机器读，而不是给人读的啦。
我们都知道，在VC工程中想自定义构建过程可以用Customize Build步骤的，当然
就要好奇看看natives.cc怎么来的。在v8工程设置中没有Customize Build步骤，
那就在js文件组中找吧~十几个.js文件，看了七八个，一个Customize Build都没
看到，怒了，直接用emacs打开v8.vcproj，用isearch才在最后一个v8native.js
中找到：
<File
RelativePath="../../src/v8natives.js"
>
<FileConfiguration
Name="Debug|Win32"
>
<Tool
Name="VCCustomBuildTool"
Description="Processing js files..."
CommandLine="./js2c.cmd ../../src "$(IntDir)/DerivedSources"
"
AdditionalDependencies="../../src/macros.py;../../src/runtime.js;../../src/v8natives.js;../../src/array.js;../../src/string.js;../../src/uri.js;../../src/math.js;../../src/messages.js;../../src/apinatives.js;../../src/debug-delay.js;../../src/mirror-delay.js;../../src/date-delay.js;../../src/regexp-delay.js;../../src/json-delay.js"
Outputs="$(IntDir)/DerivedSources/natives.cc;$(IntDir)/DerivedSources/natives-empty.cc"
/>
</FileConfiguration>
<FileConfiguration
Name="Release|Win32"
>
<Tool
Name="VCCustomBuildTool"
Description="Processing js files..."
CommandLine="./js2c.cmd ../../src "$(IntDir)/DerivedSources"
"
AdditionalDependencies="../../src/macros.py;../../src/runtime.js;../../src/v8natives.js;../../src/array.js;../../src/string.js;../../src/uri.js;../../src/math.js;../../src/messages.js;../../src/apinatives.js;../../src/debug-delay.js;../../src/mirror-delay.js;../../src/date-delay.js;../../src/regexp-delay.js;../../src/json-delay.js"
Outputs="$(IntDir)/DerivedSources/natives.cc;$(IntDir)/DerivedSources/natives-empty.cc"
/>
</FileConfiguration>
</File>
这个要反省一下，虽然一个一个找很慢，但是换用emacs说明区区急了点。
从CommandLine可以看到是js2c.cmd命令生成了natives.cc，在
AdditionalDependencies里面，所有的js文件都被加入，这就是之前找不到其它
Customize Build的原因了。如果细看js2c.cmd，会发现它其实是用js2c.py来完
成任务的。
js2c.py的本质上是个C++数组初始化语句代码生成器，因为py有方便的三引号语
法，用来处理文本模板和简单的宏替换是很方便的。app engine为什么就不做了
sample工程的模板呢，害得区区还得自己写make_app.py~
经js2c.py生成natives.cc的内容大约如下：
//重要注释一堆
#include "v8.h"
#include "natives.h"
namespace v8 {
namespace internal {
static const char runtime[] = { 1...
static const char v8natives[] = {...
static const char array[] = { 10,...
static const char string[] = { 10..
static const char uri[] = { 10, 1..
static const char math[] = { 10, ..
static const char messages[] = { ..
static const char apinatives[] = ..
static const char debug[] = { 99,...
static const char mirror[] = { 82...
static const char date[] = { 10, ...
static const char regexp[] = { 10...
static const char json[] = { 10, ...
....
//后要加一下访问接口
有人问过，说为什么不直接使用win32的自定义资源呢？这没看过最初的v8，只能
说目前而言，v8不光是想跑在win32平台下，所以常量区比较平台无关一些。何况
还可以方便地用py做些中间加工呢。
如果v8.vcproj编译不过，可以用gvim(对于内存不多的机子)/emacs查看一下natives.cc，
然后再根据python版本差异修正一下js2c.py。应该就OK了。。
总的来说...............
这个 文件->数组 的技术没什么。。 不过，还有个耐看些的，就是v8_snapshot，
初略来看，这东西主要是为提升加载速度。就是把前面那个校准库的jit编译结果
序列化，那snapshot版本启动时就不用再重复编译了。有时间区区其想详细写写
这个的~
当然，要说明一个，这个snapshot不是非常新鲜的东西，lisp编译器很早就有了。
以前研究emacs源码时就看到过，只不过GNU的黑客管她叫dump，而不是snapshot而已。