Webkit在Windows上编译时的错误总结

为了分析一下浏览器的内核，很久以前就下了好Webkit的代码，按照它官方网站上的编译步骤在windows上始终没有成功过，无奈之下Google 了一把，貌视大家编译的时候出现的问题都有所不同，找到一篇相对有参考价值的博文（http://www.kpscards.com/blog /?p=26），但我的问题和它也有所区别，最后按照编译错误信息一点点地调整编译环境，最终还是通过了。究其原因，主要还是cygwin的 PATH，VS2005的安装目录，环境变量，XCopy这四方面的问题。

下面按照编译的过程总结一下编译过程中的出现的问题，希望能让和我一样困惑着的朋友有所启发。

首先说明一下我的编译环境：

1。Cygwin安装在F:盘（此Cygwin是从webkit官网下的，也只有这个版本问题最少）

2。VS2005安装在F:/Program Files目录中

3。QuickTime SDK安装在C:/Program Files中

4。主操作系统Win XP安装在C:盘

5。编译用的PC在局域网内部，通过代理服务器访问INTERNET

6。Webkit的源代码放在G:/Webkitsrc中

7。Webkit编译输出目录为G:/Webkitbuild

8。Webkit第三方库代码放在G:/Webkitlib中

9。C:/perl中已经安装了windows版的perl

（注：7，8不能和6为同一目录，否则编译时会出现拷贝失败的错误，原因在我找到的那片博文里有写，下面我假定这个问题已经解决的基础上出现的问题）

为什么要说明我的编译环境呢？因为官网上的编译步骤都是假定要用到的软件都是安装在系统默认安装目录中的（比如C:/Program Files），而我恰恰因为有些软件没有在默认路径中，造成一些莫名其妙的错误，浪费了很多调查时间。

下面把编译过程中遇到的错误和解决方法一一列出来。

问题1。 运行Cygwin，默认Shell为bash，输入ls，dir等命令时说找不到命令

解决方法：我在bash中输入echo $PATH时显示，此PATH正指向了windows系统中的PATH，它不包含Cygwin本身的/bin:/sbin:/usr/bin:/usr /sbin:/usr/local/bin:/usr/local/sbin等存有常用命令程序的目录。所以，我想都没想就用export PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin将Cygwin的目录追加到PATH中。要注意的是这个方法虽然能解决问题1，但是为以后出现的很多奇怪的问题埋下了祸根。后面会再次提到。还有一点要记住，每次编译webkit时都要执行一次。

问题2。运行./update-webkit时，总是不成功。webkit编译用的第三方库总是无法更新。

解决方法：查了很久，最后发现update-webkit脚本用到curl来下载东西，而我的PC在局域网中，且需要设置代理服务器来访问，所以只好手工修改WebKitTools/Scripts/update-webkit-auxiliary-libs文件60行处，给curl加上代理服务器的设置，具体设置的说明可在Cygwin中运行curl --help来查看。

问题3。运行./build-webkit时出现perl脚本运行错误

解决方法：参看（http://www.kpscards.com/blog/?p=26）一文，由于我的PC中C:/perl中已经有了安装，而Cygwin环境中用到的是它自己/bin目录下的perl程序，所以这里我暂且通过[我的电脑]->[属性]->[高级]->[环境变量]将C:/perl从PATH中删除。要注意的是这个方法虽然能解决问题3，但不是最佳的解决办法，后面会再次提到。

问题4。解决了问题3个运行./build-webkit时出现找不到Microsoft Visual Studio 8/Common7/IDE/devenv.com。

解决方法：调查了很久，手工修改G:/Webkitsrc/WebKitTools/Scripts/webkitdirs脚本，在其中放上一些打印语句，发现整套编译脚本都在搜寻 C:/Program Files/Microsoft Visual Studio 8/Common7/IDE/devenv.com。而我的VS2005是装在F:盘的，怪不得找不到，没办法，只好手工修改webkitdirs脚本中的$programFilesPath变量，让其指向F:/Program Files目录。其实有更省事的办法，在Cygwin中输入echo $PROGRAMFILES，它会显示C:/Program Files，这时候输入export PROGRAMFILES=F:/Program Files就行了，但这样有个问题，每次编译webkit的时候都要设置一次$PROGRAMFILES。

问题5。好不容易build-webkit能够跑起来了，可没过多久，大概是在编译Webkitgenerated的时候发现找不到HtmlNames.h等一系列XXXXNames.h的文件，Google了一把，很多人碰到这样的问题，但是没有明确的答案，有的人说是Cygwin中缺少gpref程序。但我的环境中明显是有的。后来一点点地分析，大致定为在DerivedSources.make执行make_names.pl脚本的时候，出错了，但是什么错呢。这个问题困扰了我很久，后来发现DerivedSources.make用到了sort，uniq，echo等程序，我搜了一下C:/WINDOWS/system32和/bin目录发现两个目录中都有sort程序，这下问题搞清楚了，我在问题1种设置PATH的时候把Windows下的路径设在/bin等目录的前面了，Cygwin在调用sort命令时优先调用C:/WINDOWS/system32目录中的sort。由于Windows和Linux下，sort程序的输出在格式方面肯定是有所差别的，造成DerivedSources.make在解析sort等程序的输出时出错，本来该自动生成得XXXXXNames.h文件没有被生成出来。这只能怪自己经验不足。这个问题的解决很简单，直接执行export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:$PATH，对照问题1，我们将/bin等目录放在Win XP的PATH前面。

问题6。解决了问题5，build- webkit又跑了好一会儿，但最终又停了下来，这一次提示，某些源代码含有Unicode字符，编译器将警告当错误处理了。这个问题在（http://www.kpscards.com/blog/?p=26）一文中有提到，用VS2005打开G:/Webkitsrc/WebKit/win/WebKit.vcproj/WebKit.sln文件，将各个工程属性中C++设置项中的将警告视作错误的选项值改为否（这句话是大概的意思，我是在日文版的VS2005中编译的，中文是否作此说法有待确认）。这样改过之后能解决一部分问题，但还是有几个顽固的源代码显示还有Unicode字符。这时候直接上Editplus，打开文件另存为的时候选择UTF-8编码，再编译的话问题没有了。

问题7。问题6解决之后不久，又出来个找不到WebKitSystemInterface/WebKitSystemInterface.h错误。真是烦啊。这时候不管了，直接在G:/Webkitsrc/WebKitLibraries/win/include目录下，把WebKitSystemInterface目录连同目录里面的文件统统考到G:/Webkitlib/include目录下来，问题解决了。

问题8。其实就是问题7，只怪我一时心急，只考了个include/WebKitSystemInterface目录，链接的时候说找不到 WebKitSystemInterface.lib库（注：编译Debug版本时是 WebKitSystemInterface_debug.lib）。不管三七二十一直接把G:/Webkitsrc/WebKitLibraries /win/lib/WebKitSystemInterface.lib下的东西统统拷到G:/Webkitlib/lib下，继续编译。其实问题7和8 说明整套编译脚本在编译开始前拷贝G:/Webkitsrc/WebKitLibraries中的文件到G:/Webkitlib/l时，有一些文件漏拷贝了，什么原因我没有调查，至少少个文件或者库这样的错误还是很明显很容易解决的。

通过这8关之后，漫长的链接过程，Webkit.dll终于编译好了。看了一下G:/Webkitbuild的大小差不多有2.5G左右。很大的工程。Webkit.dll的Debug版也将近30M，装上Apple的Safari浏览器，运行debug-safari终于可以调适Webkit了，但是在哪里设断点，跟踪那些变量又是个头大的问题，Google了一把，找到一个Houjong的人写的Webkit的分析报告。从那里可以得到一些处理流程的信息，我在后续的文章中慢慢分析。