Unix提供了一个程序make，来帮助按照代码之间的时间依赖关系.doc

Unix提供了一個程序──make， 來幫助按照代碼之間的時間依賴關係來進行維護工作，避免每次都更改了所有的檔案，每次都完全重新編譯所有的代碼 使用了make，對大型的應用軟體進行維護就會容易一些。然而不同的系 統有一些與系統相關的定義，這些定義需要在Makefile中依據不同的系統重新設 置，例如X Window的目錄等，這樣要完成可以適合多個不同系統的Makefile檔案 ，仍然具有困難。有一些工具能幫助進行這些系統相關的設置，並生成Makefile 檔案，例如X Window系統使用xmkmf命令和imake模板檔案來產生本地的Makefile 檔案，這樣就能正確偵知本地系統中有關X Window的正確設置，但軟體開發者首 先要完成Imakefile檔案，以使用xmkmf。而GNU的軟體使用autoconf工具，它使用configure命令用來偵測很多系統相關的設置，如編譯器、頭檔案、庫函數等 等，然後使用預設置的Makefile.in模板檔案來產生相應的Makefile。有了這些 工具，進行編譯各種多平台的應用程序都不再是困難的了。 關於跨平台: 在一個系統上開發一套軟體是一回事，而要將此軟體整個移到另外一個不同的平台上編譯、執行又是另一回事。因為不同的平台有不同的特性、不同的開發環境、可能連相同名稱的工具程式的用法也不相同。因此，要將程式跨平台移植不是一件容易的事，甚至連相似程度最高的各 UNIX 系統間也是如此。 然而，人們對於自由軟體總是情有獨鍾，因為它不但可以免費取得，而且還可以自由使用，甚至連原始碼都有，故「跨平台移植」 這個議題在自由軟體世界就顯得格外迫切需要。 但「跨平台移植」不是件簡單的事，因為每個系統都有差異，而這些差異有些是可預期的(或固定的)，有些則不能預期。是否有方法可以達到完全的自動化呢？因此，這邊就有兩種不同的解決方案出現: 1.各平台提供其平台的資訊讓編譯系統參考，如些編譯系統在進行程式編譯時， 可以依程式原始碼中內含的規則做適度的調整，以適應不同的平台。 2.程式原始碼主動出擊，在編譯之前自行偵測此系統平台的組態為何，然後動態調整自己以適應此系統平台，讓編譯工作得以順利進行。 其中 1.方案在許多大型的開發環境中較常見，例如X Window系統或 gtk+ 函式庫等。而 2.方案則是GNU的漂亮傑作。很多時候，我們也可以同時採行這兩個方案，相輔相承。以下，我們就針對Linux舉幾個重要的例子，來看看這些跨平台的解決方案。 ? autoconf autoconf 是最基本的軟體偵測系統平台的工具。此套件收集了大部分的 UNIX 系統 (可能還包括了其他作業系統) 平台的基本特性，經過分析歸納成幾個基本的原則， 然後再根據這些原則來測試系統，並依據測試結果來調整原始碼本身，最後才開始 編譯工作。 通常當我們將程式寫好後，我們可以依據程式的需求來加入 autoconf 的支援。例 如要編譯我們的程式可能需要某些函式庫、可能需要額外的工具程式、可能對編譯 器本身的特性有特別的需求 .... 等等，這些需求都是我們事先可以知道的，但我 們不能確定想拿我們的程式來編譯的系統平台是否能符合這些需求，故我們就將這 些需求寫好，經由 autoconf 程式將它轉換成一個名為 configure 的 shell script, 如此一旦有人要編譯我們的程式時，我們會請他/她先跑一次這個 configure 的 shell script, 它就會根據我們程式的需求去一項項地測試系統，並將測試報告以 各種方式輸出。輸出方式可能包括產生 config.h 的標頭檔，讓我們的原始碼可以 利用，如此我們的原始碼就會知道這個系統有什麼？沒有什麼？而在編譯開始時告 訴編譯器要編譯那幾段的程式碼。或者 configure 也可以根據我們事先準備好的 樣本檔 Makefile.in 來產生可以適應該系統平台的 Makefile, 告訴 make 在編譯 時應該下什麼指令給編譯器？如何安裝編譯好的程式 .... 等等。 也許有人會覺得奇怪，make 程式不都有支援 Makefile 中使用條件判斷式嗎？我們 為什麼不直接將適應各種系統平台的資訊寫入 Makefile 的條件判斷式中，讓它在 編譯時可以直接適應系統平台，而非得用 autoconf 與 configure 不可呢？原因在 於，各家系統平台的 make 程式所能接受的條件判斷式的語法都不同，因此我們很 難寫出一份所有平台都能接受的 Makefile。然而，shell script 的基本語法卻是 可以在各家系統平台 (至少各家 UNIX 平台) 中通行的，而且就算只用到基本語法， 也足以完成所有的系統測試工作，這就是為什麼拌隨程式原始碼而來 config