|
關於 VC 編譯的猜想與試驗 |
|
作者: JIURL |
|
日期: 2003-5-4 |
|
|
| 今天在看從一個從Console程序中導出的makefile文件時，產生了一些想法。爲了驗證這些想法，於是做了些試驗。我的環境是 Win2K ,VC6。
首先簡單介紹一下程序是如何編譯鏈接的。程序寫好之後，我們進行編譯和鏈接來產生可執行程序。這時候，編譯器爲了完成編譯和鏈接，需要知道很多信息。比如要編譯的文件是哪一個，使用哪些編譯選項進行編譯，編譯好之後輸出到哪裏，輸出文件叫什麼名字等等。makefile 就是被vc使用保存這些信息的方法之一，編譯時程序nmake根據makefile中的信息，在用相應選項執行編譯，用相應執行鏈接，最後生成可執行文件。vc的編譯程序是CL.EXE,鏈接程序是LINK.EXE。關於本文所提到的vc編譯鏈接用的程序都在 目錄 .../Microsoft Visual Studio/VC98/Bin/ 下。 整個過程如下。 在我看這個console程序的makefile的時候，突然懷疑vc6中，console,sdk,mfc等的編譯也是通過執行外部的nmake.exe來完成的。如果真是我猜的這樣的話，如果我在vc的集成環境中選擇rebuild all 進行編譯鏈接的話，vc就會執行nmake.exe文件，那麼nmake.exe這個文件必須存在，否則的話編譯就會失敗。於是，我將 nmake.exe 這個文件改了個名字。來測試，vc6的console,sdk,mfc程序是否是調用nmake來完成編譯的。 結果很失望，沒有了nmake.exe，這個console程序一樣可以編譯。這說明了，vc6並不是通過執行nmake來進行編譯的。可能是調用內部的某些函數，來處理各種編譯的參數和路徑，再分別調用編譯程序和鏈接程序來完成編譯。不過再想想也是，連makefile文件都沒有。不會是通過nmake來指導編譯的。 那麼使用makefile的程序（叫project更準確）的情況又如何呢？於是我又找了一個使用makefile的程序來試，我找的是msdn附帶例子中的ping，這個是使用makefile的。這一次，如果沒有nmake.exe，就無法進行編譯。會報如下錯誤 'NMAKE' 不是內部或外部命令，也不是可運行的程序 由此可見，使用makefile的程序，確實是通過nmake.exe分析makefile中的內容，來指導編譯的。 總結一下，用VC new->project 中的 Win32 Console Application （console), Win32 Application (sdk), MFC AppWizard (mfc) ，這樣建的程序，編譯不通過nmake。而使用 Makefile 的編譯會通過 nmake 處理相應的makefile文件，來進行編譯。順便說一句，沒有makefile的工程，他們的編譯信息，編譯選項放在了哪裏呢？這個是我本身就知道的，他們放在工程目錄下的dsp文件中，用編輯器，比如記事本，打開dsp文件就可以看到。也可以打開dsw文件看看。 最後我又做了這樣兩個試驗， 將CL.EXE改名。結果編譯出錯。錯誤如下。 Compiling... 一定程度可以說明了，編譯程序是CL.EXE，VC集成環境下的編譯，也是用一定的編譯選項調用CL.EXE來完成的。 將LINK.EXE改名。結果鏈接出錯。錯誤如下。 Linking... 一定程度可以說明了，鏈接程序是LINK.EXE，VC集成環境下的鏈接，也是用一定的鏈接選項調用LINK.EXE來完成的。 完 |
