爲了分析一下瀏覽器的內核，很久以前就下了好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的分析報告。從那裏可以得到一些處理流程的信息，我在後續的文章中慢慢分析。