Solution Guide for Migrating UNIX Build Environments

第 3 章 - 規劃建置遷移

本页内容

簡介與目標
瞭解建置系統遷移
開發解決方案設計
驗證技術
建立功能規格
開發專案計劃
建立專案排程
設定開發和測試環境

簡介與目標

本解決方案指南的其餘部分,會指導您如何將 UNIX 上的 make 建置系統遷移到 Windows 上的 make 建置系統。即使您的解決方案是要在 Windows 上建立新的建置系統,其餘章節中的流程指導和技術資訊仍然適用,不過實作細節將會有所不同。

「規劃」階段的主要目標,是建立解決方案的架構和設計、專案計劃以及專案排程。解決方案設計可以用概念、邏輯系統和實體元件來表達 (也稱為概念性設計、邏輯設計和實體設計)。在這個階段,會將專案的最初願景轉換成如何達成目標的實際計劃。小組成員會利用自身的專業知識,就專案的各個層面建立個別的計劃,涵蓋安全性、預算到部署等各個領域,同時用「專案管理」的角色將所有的個別計畫統整為主要的專案計劃。同樣地,個別排程也會加入成為主要專案排程。

當專案小組同意整個計劃已經清楚地定義,足以繼續進行開發的作業,同時小組、企業贊助者和關鍵參與者也核准主要專案計劃和排程後 (通常是在「階段性目標」會議上),這個階段便告結束。這個階段的正式結束,意味著第二重要的階段性目標「專案計劃已核准」的開始。以下的清單指出達到階段性目標所必須完成的工作:

  • 開發解決方案設計和架構

  • 驗證技術

  • 建立功能規格

  • 開發專案計劃

  • 建立專案排程

  • 建立開發和測試環境

本章所述的技術資訊可以做為您在做決策時,提醒自己必須留意的一些考量。此外還會討論開發和測試環境的需求,並提供驗證將會使用的技術的指導資訊。UMPG 針對專案的這個階段,提供了各項工作和交付成果的詳細說明。

瞭解建置系統遷移

下列步驟提供了建置系統遷移的一般流程概觀,本章其餘部分會詳細討論各項步驟。在執行這些步驟的過程中,您將會決定最適合的 UNIX 可攜性環境。

根據在「構想」階段期間所進行的評估深度,以及所收集的技術需求,您可能已經完成了這些步驟中所述的部分工作。如果您在「構想」階段期間沒有進行深度評估,「規劃」階段會是進行這項工作的好時機。

  1. 清查現有的建置系統

    必須先完全瞭解建置系統的運作方式,並決定成功遷移必要的需求清單,才能開始遷移建置的程序。因此,您需要進行全面檢查建置系統的評估,包括 makefile 和從 makefile 內使用的公用程式。請參閱本章<評估現有的建置系統>一節中所提供的詳細指導。

  2. 建立需求集

    為了將遷移的問題減至最低,您會希望選擇或建立可以盡量與現有系統共用所有重要功能的 Windows 環境。想要比較與對應 Windows 環境與現有系統的功能時,必須要從目前建置系統的評估中,摘錄出建置系統需求的清單。這份需求清單不必是正式文件;它可以全部取自本程序步驟 3c 中所述的範例建構站台。

  3. 選擇適合的 UNIX 可攜性環境

    若要遷移 make 架構的建置流程,必須選擇 Windows 上的 UNIX 可攜性環境。做選擇時,重要的是要比較建置系統需求與可攜性環境的功能。您需要直接測試和使用建置環境,以確保符合所有的需求。選擇適當的環境通常包含下列步驟:

    1. 調查 Windows 上的潛在解決方案

      熟悉適用於 Windows 的所有可能之 UNIX 環境解決方案。在每個系統中試用 shell 指令碼、編譯、編輯文字檔案以及使用 make,判斷它們是否有任何明顯的限制。

    2. 比較建置環境需求與 Windows 解決方案的功能

      決定看起來與現有流程最相容的 Windows 解決方案。請勿太快或太早剔除任何解決方案;它們或許可以解決一些目前還看不出來的重要問題。

    3. 建置範例建構網站

      這個範例站台會模擬您現有的建置流程。建立高層的 shell 指令碼,執行許多與現有的 shell 指令碼相同的作業 (或使用現有的 shell 指令碼)。盡量納入許多現有的作業,讓您可以判定 Windows 解決方案是否能夠處理這些作業。您也會需要建立一些含有代表現有建置流程之建置規則的範例 makefile。使用相同的工具 (編譯器、程式庫封存器及其他公用程式) 來進行所有的測試。這樣的一個站台應該是測試平台。

      這個步驟也能夠確定可以實作替代解決方案的問題範圍。請參閱本指南的第 4 章<遷移建置系統>,熟悉各種 UNIX 至 Windows 的遷移問題,幫助您確定遷移中的潛在問題範圍。

    4. 在 Windows 上安裝各個 UNIX 環境,並分別與原始建置環境進行比較

      您可能會想要在不同的實體系統上安裝各個環境,以避免彼此發生任何潛在的混淆或不相容的互動。請採用範例建構流程,並在每個已安裝的 UNIX 環境中執行。檢查結果並確定問題範圍。

      請注意,某些環境可以提供不同版本的重要公用程式。例如,有些環境會提供它們專用的 make 版本,也會提供常用的 GNU gmake 公用程式。有些環境附有編譯器指令碼,可以設定為使用不同的原始 Windows 編譯器,或支援與先前 UNIX 版本相容的特定命令列選項。

      許多這些 UNIX 環境都宣告本身符合 POSIX 軟體標準,而且很多 UNIX 系統也都做出這樣的宣告。因此,如果建置流程是使用這些軟體標準來建構可攜性,那麼您通常會嘗試使用特殊功能以及非標準的擴充功能。

    5. 挑選最合適的 UNIX 環境

      請選擇在執行建置流程時,問題應該會最少的 UNIX 環境。有時您會發現,一項出色的解決方案有某些行為是與您的需求完全不相容的,或是少了一項不容易取代的功能。這項流程可以讓您更容易做出決定。

  4. 變更實際的建構檔案

    進行必要的變更,嘗試解決已知的問題範圍,然後使用所選擇的 Windows 解決方案來執行您的解決方案。依照這個流程進行可以發現範例建構流程未偵測到的其他問題範圍。繼續執行這個步驟,建置所有的應用程式。

  5. 確保新的 makefile 能夠運作

  6. 將建置系統部署到開發人員的桌面環境

圖 3.1 顯示這些步驟的流程圖:

圖 3.1 遷移作業必要核心步驟示意圖
圖 3.1 遷移作業必要核心步驟示意圖

這份流程圖摘要了整個遷移流程中必須完成的重要技術導向工作。您的遷移過程可能會與圖 3.1 中的表示不同,不過此處摘要列出的工作都是遷移流程中以各種形式出現的因素或考量。例如,您的願景/範圍文件可能會指出建置遷移小組無法轉換系統上的一萬個 makefile;不過它們會提供在 Windows 上建置軟體的替代架構 (例如 Visual Studio),以及一組用於轉換 makefile 的原則或公用程式。當一個小組所遷移的建置系統將會供許多不同的應用程式遷移小組使用時,便常常會看到這種方式。

開發解決方案設計

根據現有的 make 系統遷移建置系統的第一項技術活動,就是開發解決方案設計。解決方案設計是由三個部分組成的:

  • 概念性設計,這項設計包括就使用者觀點 (包括使用者設定檔) 而言的建置系統,以及目前與建議的系統使用案例。

  • 邏輯設計,這項設計包括將會執行概念性設計的物件和互動,與特定的硬體或軟體解決方案無關。

  • 實體設計,這項設計包括實作邏輯設計的硬體和軟體解決方案;這個階段的設計也會受到現實情況的限制。

如果這份清單中有些工作看起來很眼熟,也是理所當然的。概念性和邏輯設計是以評估目前的建置系統以及決定要遷移 make 建置系統時,已經完成的工做為基礎。請使用現有建置系統的清查和檢查結果來進行概念性設計。審視目前的使用情況並從該處修改設計,以符合先前定義的高層需求和目標。

概念性設計

概念性設計的目的是要獲知並瞭解適當的商務需求與使用者需求,然後據此建立概念性設計。概念性設計會讓企業贊助者、關鍵參與者和使用者參與,有助於讓需求更完整且更精確。

邏輯設計

邏輯設計也來自目前建置系統的檢查結果。它會試圖跳過這個階段,直接進入實體設計,但是當 Windows 上有必須重新實作的部分時,便應該將現有的建置系統重新評估為邏輯元件。您只能夠從邏輯設計衍生一組建置系統需求。

實體設計

實體設計包含將 make 架構的建置系統遷移至 Windows 的特定硬體和軟體解決方案的選擇。實體設計會包括您現有建置系統的詳細調查結果。不同的軟體解決方案提供不同的功能,這些將會影響實體設計,而且可能會讓您修改邏輯設計。

例如,現有的程式碼基礎可能是由許多檔名只有字母大小寫不同的檔案所組成的。邏輯設計可能只陳述檔案是從這些目錄編譯而來的,但是實體設計就必須解釋字母大小寫的差異。將要如何為這些檔案重新命名?您會選擇解釋字母大小寫差異的系統,還是回到邏輯設計,然後增加一個以某種方式對應檔案名稱的步驟?

現有流程的調查結果可以提供一組技術需求,例如「新系統必須處理符號連結」。調查目標環境可以讓您決定它是否能夠滿足您的技術需求,加上「構想」階段中定義的其他高層需求。

另一個範例是,您實體設計中的 UNIX 可攜性環境可能太過複雜或根本不存在。例如,如果您的 makefile 只會叫用有 Windows 命令列對等用法的公用程式 (copy 等於 cpdel 等於 rm 等),而且不會對檔案系統有任何 UNIX 特定的需求,那麼 make 程式便是您應該要使用的可攜性環境。您只需要移動原始程式檔,找出適當的 make 程式,然後重新寫入 makefile 即可。

另一方面,如果建置流程完全要靠 UNIX 檔案系統語意,就需要更複雜的 UNIX 可攜性環境,例如 Microsoft Services for UNIX 中的 Microsoft® Interix 子系統。

決定實體設計 — 實作已遷移的建置流程的工具組 — 是解決方案設計的重要部分,也是這份文件指南的重要部分。

評估現有的建置系統

事實上,小組有時候會跳過這個步驟。他們只使用稍早「構想」階段的清查結果,然後開始一或多個範例建置系統遷移的作業;他們會在遇到問題時才進行調查。這種方式的流程工作量較少,但是整體的重做 (rework) 工作量往往很大。

這個步驟涵蓋圖 3.1 中四個以「評估」開始的方塊。此時評估的目的是要建立 Windows 目標系統上必須要考慮的功能清單。這些功能必須加入範例系統或概念驗證中,以試驗不同的 Windows 解決方案。

之前在「構想」階段執行的評估中,您只需要粗略的分析,就可以發展出理想的建置流程執行工作、潛在的範圍限制以及顯現可能的問題。在這個階段,您必須要徹底瞭解流程,才能夠對應現有的命令以及可用的 UNIX 可攜性環境命令。所有的工具和流程都必須要經過分析並逐項列出。上述的每一項都必須與每個目標環境的功能進行比較,以決定是否有任何的遷移問題。

請建立表格或工作表,列出對您的流程十分重要的功能。稍後在檢查 Windows 解決方案時,您就能夠判斷 Windows 產品能如何為問題提供解決方案。當您建立範例建置流程或概念驗證時,這份表格便很重要。 關於您所建立的表格比較,第 4 章<遷移建置系統>列出了建置系統中的各種功能,它們會依系統而有所不同。當與您的建置系統需要進行比較時,這些功能可能會顯示出潛在的遷移問題。

若要決定將建置流程遷移至 Windows 的最好方法,必須分析並徹底瞭解您現有的流程。評估時要考量的四大要素,依重要性可以約略排名為編譯器和連結器、make 和 makefile、shell 指令碼以及其他使用的公用程式。以下四節將分別就這些要素進行討論。

評估編譯器和連結器

根據所建置的應用程式的類型、複雜度和特性,實際編譯和連結公用程式的功能和使用可能會是獨特而又複雜的。一般來說,編譯器可以處理大部分的編譯選項,包括直接將功能要求傳送給連結器,讓建置流程不需要直接呼叫連結器。但是在某些情況下,例如建構共用程式庫,就必須直接呼叫連結器。

在 UNIX 上,C 編譯器最常用的名稱是 cc,而 C++ 編譯器的常用名稱為 CC。許多 UNIX 系統廠商會提供自己的特定編譯器版本,這些版本可能會有不同的名稱,例如 IBM 的 AIX xlcxlC 編譯器以及 GNU gcc 編譯器。在許多情況中,ccCC 等名稱是廠商的特定編譯器位置的連結。請注意,兩個名稱之間的字母大小寫的差異在 Windows 上可能會造成問題。

每家廠商的編譯器都不同。不只是 UNIX 廠商之間會有差別,UNIX 和 Windows 廠商之間也有差別。雖然它們都傾向支援常用的選項集,但是在支援不同的命令列選項時,以及在針對不同的 ANSI/ISO C 和 C++ 標準提供不同等級的相容性時,還是會產生差異。從 UNIX 移至 Windows 時,差異會變得更明顯。

Windows 上有數種 UNIX 環境會透過特殊命令叫用原始的 Windows 編譯器,例如 ccwcc。這些是可設定的包裝函式指令碼,用於模擬熟悉的 UNIX 編譯器命令和編譯器行為。由於它們是可設定的指令碼,因此很容易修改以配合不同的 Windows 工具,並且建立您自己的個人化增強功能。大部分常用的 UNIX 命令列選項都是由這些包裝函式指令碼支援的。

如果您的建置系統也會叫用 ld 指令,就需要決定 Windows 上的 UNIX 環境是否也支援這個命令,如果不支援,則要決定編譯器是否可以用來取代 ld ,或是您需要直接呼叫原始的 Windows 連結器,例如 link.exe

在您使用編譯器、連結器或同時使用這兩者來建置應用程式之後,可能會需要使用偵錯工具來調查應用程式在遷移之後為什麼無法如預期般運作。不論選擇何種編譯器,請確定您有對應的偵錯工具。若是 gcc,則為 gdb;若是 Interix (wcc) 和 MKS (cc),則為 Windows 偵錯工具,例如 windbgcdb。雖然偵錯工具在應用程式遷移中是很基本的,但是如果它們建立自己的工具來協助建置,在建置流程中也可能會很重要。

評估 make 和 makefile

makefile 的評估應該要決定建置系統中 make 使用的所有功能,以及雖然不是 make 特有的、但是可在 makefile 中擷取的功能。下列問題的回答將有助於在規劃新的建置系統時建立功能:

  • makefile 中還提供哪些其他的目標?它們允許不同的版本、清除舊有物件檔案、列印文件或去除符號資訊的執行檔嗎?

  • makefile 中使用何種功能?包括尾碼規則、模式比對、特殊巨集指派作業、條件式和虛擬目標嗎?

  • 會使用特有的配方嗎?

  • 會使用何種編譯時間巨集來控制版本建置?

  • 會使用何種編譯器選項?

  • 建置系統會視區分大小寫的檔案名稱而定嗎?特別是,建置系統會視下面兩個檔案名稱之間的大小寫區分而定嗎:makefile 和 Makefile?

請確定對現有的 makefile 評估包含下列資訊:

  • 建立執行檔的隱含規則

  • 其他 makefile 的加入

  • 特別目標

  • 建立目錄階層時的遞迴

  • 如 MAKEFLAGS 和 SHELL 等變數

  • 使用 VPATH 巨集

  • 先決條件中的動態巨集

  • 模式比對規則

  • makefile 名稱中大小寫特定性的使用 - 如果名為 Makefile 和 makefile 的兩個檔案必須使用不同的方式處理,這種大小寫的差異在 Windows 上就會是個問題

評估 Shell 指令碼

大部分的 UNIX 建置系統都會廣泛使用 shell 指令碼來驅動軟體建構流程。這些指令碼位於他們自己的檔案中,或是可以做為 makefile 中的配方。

在許多情況中,都可以在 Windows 上選擇對等的 shell,因為 kshshbashcsh 的版本可以在本文件所討論的部分或所有 UNIX 可攜性環境中使用。因此,您很少需要根據 shell 指令碼需求來決定 UNIX 可攜性環境。

在評估 shell 指令碼時,請確定您的評估包含下列考量:

  • 用於執行指令碼的 shell

  • shell 的選擇不一致 (例如,或許有少數的指令碼實際上是 csh 指令碼,而不是 Bourne shell 指令碼)

  • shell 是否與 POSIX 相符?

  • 所使用的 POSIX 的擴充功能,例如共同處理

  • 指令碼用於何處?也就是說,指令碼的用途為何?

  • 分別使用何種命令列選項?

  • 所叫用的任何特殊指令碼或應用程式的目的為何?

  • 是否使用符號連結 (意即,指令 ln –s 是否用於任何指令碼中)?

  • 在指令碼的絕對路徑名稱中,是否使用任何的路徑名稱?

  • 有任何的檔案或路徑名稱含有 Windows 不支援的字元或是 Windows 保留的檔案名稱嗎?

  • 區分大小寫的檔案和目錄名稱是否重要?

評估公用程式的使用

此時評估公用程式的目的,是要針對在建置流程中所叫用的公用程式,產生一份完整的清單。您可能已經從「構想」階段中所完成的檢查得到這份清單。取得這份清單時,您會需要個別評估每項公用程式,決定該公用程式是否可以在 Windows 上使用,以及其命令列選項是否相同。基本上,您要嘗試找出在遷移至 Windows 期間需要修改或取代的公用程式。

這份所有公用程式清單的取得來源包括 shell 指令碼、makefile 中的配方以及您自訂的建置流程公用程式 (例如從資料庫中擷取版本識別碼的工具) 等。許多公用程式都將會有 Windows 對等用法,例如,移動和複製檔案的指令在功能中大部分都會重疊,但有些則無。

請確定沒有 Windows 對等用法的命令的目的。這些指令將必須自行處理,而不是對應到可攜性環境中的對等用法。沒有對等用法的命令往往是處理檔案系統功能的命令。例如,命令 ln –s 代表符號連結。由於 UNIX 和 Windows 檔案系統之間的差異,因此在大部分的情況中必須自行處理符號連結的使用。

選擇 UNIX 可攜性環境

這個步驟是由圖 3.1 中所示之「規劃」階段的下半部組成的。現在請使用在您評估期間產生的功能清單,來選擇適當的 UNIX 可攜性環境。

為了讓遷移有效率,您會希望選擇最適合建構工具需求的環境。由於 Windows 原本就與 UNIX 不同,因此必須找出適用於 Windows 的 UNIX 環境解決方案。幸好,有許多 UNIX 環境系統都可供 Windows 使用,包括 MKS Toolkit 的開發人員版本、Microsoft Services for UNIX 中的 Interix 環境系統以及 Cygwin 環境和工具組。這些系統都嘗試提供最多的 UNIX 類型功能,讓從 UNIX 進行遷移的工作更加輕鬆。

您對於一種可攜性環境的選擇,可能是根據一項重要的公用程式或功能只能在該環境使用而決定。可能是編譯器的選擇決定您對於可攜性環境的選擇,或是可攜性環境的特定功能決定您對於公用程式的選擇。

事實上,在「開發」階段早期之前,您可能都不想選擇特定的可攜性環境。如果評估的結果是沒有結論 (通常都是如此),或者如果不同版本之間的取捨不清楚,就應該要根據您的需求,安排各環境中可用功能的優先順序,以便幫助您釐清取捨。如需更多資訊,請參閱本章的<驗證技術>一節。

比較 UNIX 可攜性環境

如果您瞭解各種 UNIX 環境系統的限制,建置系統遷移將會更加順利,因為它與您目前的建置流程的需求和依存性有關。您希望系統所提供的工具大都具有和您在 UNIX 中所使用的相同的功能,並且最適合您的業務目標。

本文件中討論到三種這類的產品:MKS Toolkit for Developers、Interix 環境 (Microsoft Services for UNIX 的一部分) 和 Cygwin 環境。這些產品都各有自己的特性,這些特性可能會、也可能不會讓產品適合您的遷移。如果沒有一項產品可以提供您需要的所有功能,您就必須選擇最適合的一種,然後改變您的建置系統來配合它。例如,如果需要在多種平台上共用建置流程,就必須找出可以讓建構檔案變更最少的 Windows 解決方案。

您應該自行調查 Windows 產品,補充有關上述這三種主要產品的資訊。雖然許多遷移專案中都使用這些產品,不過您可能會發現本指南中沒有提到的某種系統更符合您的需要。

您可能也會發現,不同的產品符合您不同部分的需求,因此您可能會想要混合搭配各項產品中的不同元件。這種方法通常並不可行,也不建議您使用,因為會有一些潛在的困難:不是成本的問題 (各項產品的授權成本可能都很高),就是技術的問題 (一項產品的技術與其他產品的技術不相容)。混合搭配不是不可能 - 例如,gmake 就適用於所有的這些環境 - 但是多種產品很少可以成功用於一項解決方案中。表 3.1 摘錄了一些可用於各項產品中的功能。

表 3.1 高層功能比較矩陣

功能

MKS Toolkit

Interix

Cygwin

make 公用程式

MKS make

gmake (在光碟中)

BSD make

gmake (可以從 www.interopsystems.com 取得)

GNU make

(gmake)

Win32 的編譯器

cc, cxx

(Windows 編譯器的介面,可以使用 CCG 環境變數來設定)

wcc

(Windows 編譯器的介面。 可以從 www.interopsystems.com 取得)

gcc, g++

連結器

ld

(Windows 連結器的介面,可設定的)

使用 wcc

或 Windows 連結器 (link.exe)

ld

已安裝的 Shell

MKS ksh,

csh (tcsh),

bash

ksh (pdksh 5.2.13)

csh (tcsh 6.08.03

bash

其他可用的 Shell

 

bash

(可以從 www.interopsystems.com 取得)

 

指令碼工具

Perl 5.6.0,

MKS awk

gawk (在光碟中)

Perl 5.6.1

AT&T awk

gawk

Perl 5.8.0,

gawk

常用的公用程式

POSIX.2

POSIX.2

POSIX.2

單一根目錄的檔案系統

區分大小寫的檔案名稱

Windows 檔案名稱語法

與 Win32 相容的 Unix 可攜性程式庫

下列各節詳細說明了可以在 Windows 上使用的三種常用的 UNIX 環境產品。

MKS Toolkit

MKS Inc. 提供了一組在 Windows 上常用的 UNIX 工具和程式設計環境,稱為 MKS Toolkit 產品系列。有數種版本的 MKS Toolkit 可以讓您保留 UNIX 的投資,並且輕鬆快速地將指令碼、來源程式碼、建置環境和工作環境從 UNIX 遷移至 Windows。MKS Toolkit for Developers 產品可以解決將 UNIX 建置環境遷移至 Windows 的問題。

MKS Toolkit for Developers 提供了在 POSIX.2 中定義的整套工具,包括 Korn、C 和 bash shell;findgrepawkperl 以及另外 400 種工具和公用程式。在開發方面,包括如 makeldcc 指令碼等公用程式,可以設定為支援適用於 Windows 的各種 C 和 C++ 編譯器 (例如 Microsoft Visual Studio)。

MKS Toolkit for Enterprise Developers 是 MKS Toolkit for Developers 的超集合,用於企業 UNIX 應用程式至 Windows 的遷移。除了 Developer 產品的所有功能,MKS Toolkit for Enterprise Developers 還包括以用於遷移 UNIX 應用程式的 Win32 子系統為基礎的一組完整的 UNIX 應用程式介面 (API) 程式庫。Enterprise Developers 產品也包括 X11、OpenGL、Motif、C、C++、Fortran、curses 和 shell 指令碼應用程式的支援。

MKS Toolkit 技術為 UNIX 和 Windows 應用程式提供了可在 Windows 平台上共存及完整互動的架構。遷移流程幾乎不需要修改 UNIX 來源程式碼,並可讓您維護在 UNIX 和 Windows 上建置和部署應用程式的單一來源程式碼基準。此外,您可以使用 MKS Toolkit 在繼承應用程式中引入及整合 Windows 特定的程式碼和功能,讓它們得以利用 Windows 功能,例如 .NET 和 COM。

本文件是以 MKS Toolkit for Developers 產品為主;Enterprise Developers 產品比較廣泛,可以選擇用於將建置環境和應用程式本身遷移至 Windows 環境。

如需有關 MKS Toolkit 產品的更多資訊,請參閱 http://www.mkssoftware.com/products/tk/

Microsoft Services for UNIX 和 Interix

Interix 3.5 版是附在 Microsoft Services for UNIX (SFU) 產品中的。Interix 是完整的 UNIX 環境,包括 Interix 子系統、Korn 和 C shell、超過 350 種 UNIX 公用程式以及一套完整的軟體開發套件 (SDK)。這些公用程式都是 UNIX 電腦上的標準,並提供熟悉的環境,讓開發人員、使用者和系統管理員可以輕鬆地從 UNIX 轉換為 Windows。SDK 支援超過 1900 種 UNIX API 及遷移工具,例如 makercsyacclexnmstrip

SDK 也附有編譯工具,例如允許重新編譯 UNIX 來源程式碼的 ccc89gccg++ldg77。它們會產生一個在 Windows 平台上執行的二進位值,但是這個二進位值與 Win32 子系統無關也不相容。這個二進位值只會在 Interix 環境子系統中的 Windows 上執行。可惜的是在本指南中,這代表這些編譯工具都不適合,因為本指南假定您的目標是要建置 Win32 二進位應用程式。幸好,Interix 用許多其他的方法來支援與 Windows 的交互操作性,包括直接叫用 Windows 公用程式的功能。有一種可以編寫指令碼的公用程式稱為 wcc,看起來像是傳統的 UNIX C/C++ 編譯器,雖然是在 Interix 環境中運作,但是會叫用 Microsoft C/C++ 編譯器以產生 Win32 執行檔。由於它是可編寫指令碼的,因此也可以修改 wcc 來叫用 Windows 版本的其他常用編譯器,例如 Windows 版本的 gcc

另一項 Interix SDK 工具是 ld 公用程式,是 gcc/g++ 系列工具的一部分。它也不能用於建立 Win32 二進位值。因此,如果您的建置系統需要使用連結器,就必須使用 wcc (使用適當的連結器命令列選項) 或 Windows 連結器公用程式 (例如 Windows link.exe) 來取代。

有關 Interix 和 Services for UNIX 的其他資訊,請參閱 http://www.microsoft.com/windows/sfu/http://www.microsoft.com/windows/sfu/productinfo/overview/default.asp

Cygwin

Cygwin 適用於 Windows 的 Linux 類型環境, 它由兩個部分組成:

  • A DLL (cygwin1.dll) 做為 Linux 模擬層,並提供豐富的 Linux API 功能。

  • 提供 Linux 的外觀和感覺的工具組合。

Cygwin 工具是已為 Microsoft Windows 移植的常用 GNU 開發工具的接口。它們使用 Cygwin 程式庫來執行,該程式庫提供了這些程式所預期的 UNIX 系統呼叫和環境。

安裝了這些工具之後,便可以編寫利用標準 Microsoft Win32 API 和 Cygwin API 的 Win32 主控台或 GUI 應用程式。因此,您不需要大幅更改來源程式碼,便可以輕鬆地移植許多 UNIX 程式。其中包括設定和建置大部分可用的 GNU 軟體,包括 Cygwin 開發工具本身所附的套件。

Cygwin 系統可以從 http://www.cygwin.com/ 取得。

選擇 make 的版本

UNIX 可攜性環境的選擇通常會影響 make 的決定,反之亦然:您在 MKS 環境中通常會使用 MKS make,在 Cygwin 環境中會使用 gmake,而在 Interix 環境中則會使用 Interix make

然而,由於 gmake 實作是開放原始碼,因此這個版本很容易可以針對任何 UNIX 環境進行重新編譯,包括 Interix 和 MKS 可攜性環境。MKS 版本可在光碟中取得,Interix 版本可從 http://www.interopsystems.com 網站取得。

如果您正考慮同時在 UNIX 和 Windows 上維護建置流程,您可能會想要考慮在建置流程中使用 gmake

選擇 Windows 編譯器

有各種不同的 Window 編譯器可供使用,包括 Microsoft Visual Studio® .NET 和 Windows 版本的 gcc。在選擇時,要視您的 UNIX 應用程式所需要的功能而定,或許還要考慮到您目前使用的是何種 UNIX 編譯器。例如,如果您在 UNIX 上是使用 gcc,可能會想要使用 Windows gcc 編譯器。這項選擇可以讓您的應用程式遷移問題降至最少。

gcc 編譯器在 UNIX 上十分常用,因為它幾乎在每種 UNIX 平台上都是免費的,具有合理的效能,並且隨時符合最新的 ANSI/ISO 編譯器標準。它提供了多種平台上的一致性,簡化了可攜性。然而,在 Windows 上,此編譯器有數種不同的版本和組態可以使用。Cygwin 所附的 gcc 編譯器是設定為使用 Cygwin UNIX 可攜性程式庫,並且取決於 Cygwin 執行階段 DLL。 另外還有 MinGW (Minimalist GNU for Windows) 套件所附的 gcc 編譯器,含有一組 Windows 標頭檔和匯入程式庫,可以讓您建置不需要 Cygwin 執行階段 DLL 的 Win32 應用程式。

在 Interix 環境中直接使用任何的 Windows 編譯器都會造成問題,因為 Interix 和 Windows 之間的檔案名稱語法不相容。如果您想要使用 Interix 環境,應該使用 wcc 包裝函式指令碼,它的目的是要叫用之前安裝的 Microsoft C/C++ 編譯器,例如 Visual Studio .NET,並建立 Win32 二進位值。您可以將此指令碼修改為叫用其他的 Windows 編譯器,例如 gcc,但是您必須進行適當的修改。

MKS Toolkit 環境提供了可編寫指令碼的 cc 公用程式,它是使用 Microsoft Visual C® 編譯器,可以設定為建置嚴格的 Win32 應用程式,或是建置需要 MKS Toolkit for Enterprise Developers UNIX 可攜性程式庫支援的 UNIX 應用程式。前者位於 $ROOTDIR/etc/compiler.ccg,後者則位於 $ROOTDIR/etc/nutccg/cc.ccg。

比較 make 環境中常用的機制

表 3.2 摘錄了 UNIX 上一些常用的功能,以及這些功能在 Windows 上不同的 UNIX 環境產品內的可用性。由於 make 公用程式十分重要,因此本表特別指出許多 Sun Microsystems Solaris 版的 make 所提供的功能,這些功能在建置流程遷移期間可能會有問題。第 4 章<遷移建置系統>中會詳細解釋這些功能比較的詳盡資料。目前請先看看這些功能中,有哪些是您的建置系統所使用的,以及有哪些 Windows 實作方式支援它們。

表 3.2 make 環境中常用機制的支援

常用機制

Cygwin

Interix

MKS Toolkit

產品在安裝期間提供 gmake

 

 

gmake 可供使用

make 支援多行註解

 

makefile 可以包含其他的 makefile

make 將命令列巨集定義儲存在 MAKEFLAGS 中

 

make 支援變數值的立即評估 (:=)

make 指派 shell 命令結果給巨集 (VAR:sh = sh_cmd_line)

 

 

make 有條件地定義巨集 (:=)[Sun Solaris 功能]

 

 

 

make 使用 VPATH 巨集

 

 

make 提供巨集 COMPILE.c、LINK.c

 

 

make 提供將 .c 檔案轉換為執行檔的隱含規則

make 提供先決條件中的動態巨集

 

make 提供模式比對規則

 

make 提供 .INIT 和 .DONE 特別目標的對等用法

 

 

產品提供 Windows gcc

 

 

Windows gcc 可以從產品環境來叫用

適用於 Windows 應用程式的 C 編譯器公用程式

gcc

wcc

cc

適用於 Windows 應用程式的 C++ 編譯器公用程式

g++

wcc

cxx

產品提供單一根目錄檔案系統的外觀

 

ln -s 建立檔案的 symlink*

 

ln -s 建立目錄的 symlink*

產品提供檔案系統大小寫區分*

 

 

產品支援 Windows 路徑名稱語法

 

注意 表格中標有星號 (*) 的項目,是只能用於對應之 UNIX 環境所建置的公用程式和應用程式的機制。這些機制通常無法和 Windows 應用程式或其他 UNIX 可攜性環境的應用程式一起使用。

使用本表來確定遷移會產生的問題時,並不只是統計勾選記號、選擇得分最高的產品這麼單純。您必須依據使用的頻率和解決的困難度,為每一項功能指定優先順序或權數。例如,缺少將 .c 檔案轉換為執行檔的隱含規則雖然很不方便,但是修正起來也相當容易;而對於符號連結的依賴,要想找出變通的解決方案大概就不是那麼簡單。另一方面,您的建置系統可能只會使用一次符號連結,但卻常常要使用隱含規則。

在建置系統遷移方面,您可能會需要移植構成該建置系統的個別元件。移植元件可能會需要建立或移植指令碼,以便在 Windows 環境中執行特定的功能。雖然大部分的指令碼都可以遷移 (若是有適當的 UNIX 可攜性環境),但您還是應該要檢查兩個主要的不相容性的來源:

  • 檔案和路徑規格

  • 權限和安全性

在《UNIX 應用程式遷移指南》和第 4 章<遷移建置系統>中說明了這些遷移的細節。

建置流程常常會使用許多不同類型的應用程式:sedawk 和 shell 的指令碼;標準 UNIX 公用程式,如 makecpldrm;以及針對您的組織特別設計、以 C 或 C++ 編寫的應用程式。 這些應用程式和控制的 makefile 都構成了建置流程的解決方案元件。在「規劃」階段期間,您的調查工作應該要能找出任何需要修改或取代的元件。

驗證技術

您應該要執行概念的驗證,來驗證您的實體設計。如果您尚未決定要使用的 UNIX 可攜性環境,透過概念驗證便會很快得知符合您需求的 UNIX 可攜性環境為何。這項驗證的機制是測試建置,如本章<瞭解建置系統遷移>一節中的步驟 3c、3d 和 3e 所述。

測試建置是一個簡單的應用程式,它使用建置系統中最重要的功能。這個測試應用程式可能是特別針對遷移的測試方面所編寫的簡單應用程式,但通常是遷移專案本身的子集 (如果建置系統包括自訂的公用程式,那麼使用遷移的建置系統進行建置,會是一個有趣的 bootstrap 問題,同時也會是有用的測試)。

如果您有足夠的資源,應該要在電腦中裝妥各種可能的 Windows 環境。這種平行測試必須與開發同步;與逐一嘗試不同的環境比較之下,平行測試可以大幅節省時間。

請注意,概念驗證與試用 (pilot) 不同。試用專案會測試整個系統;這種驗證測試並不會涵蓋整個系統,甚至並不穩定。然而,它可以做為日後的試用或測試套件的基準。

建立功能規格

建置系統通常不會取得詳細的功能規格。在遷移 make 建置系統時,很容易就陷入「它會和 UNIX 版本類似」的想法,然後就不管功能規格了。開始時用到的遷移問題表是可能要考慮的細節的清單,但並不算是功能規格。在小型專案中,這樣就足夠了。

不過,根據已經完成的評估,您必須釐清能讓新系統完全相同、以及無法達成的領域究竟為何。功能規格的作用是合約以及未來測試機制的指南,應該要能提供這些資訊。規格應該要能讓一般使用者或測試者判斷系統是否能運作,或是判斷發生失敗的情形,以及成功或失敗的比例如何。

在某些公司中,makefile 的初始轉換是建置遷移小組的工作。而在其他公司中,建置遷移小組會處理建置系統的公用程式和結構,但不會動到實際的 makefile;而是提供架構 (工具集) 和一組指示或轉換公用程式,讓應用程式開發人員依轉換的需要來套用。

不論您的建置遷移小組提供的是何種方式,功能規格都是要完成之交付成果的重要說明。功能規格是建置遷移小組和應用程式遷移小組之間的合約,是記錄此資訊的最佳位置。不過,它也可以在其他地方定義,只要有定義就好。

開發專案計劃

專案計劃說明了每日進行遷移的方法。它們會分配資源,並設定含有階段性目標的排程。UMPG 含有您可能需要為軟體遷移專案開發的計劃的清單。您所建立的可能專案計劃 (安全性、通訊、預算、開發、測試、採購和設備、部署、試用、訓練和工作量) 有哪些,與您要遷移的應用程式有極大的關聯。建置遷移至少必須要有開發和部署計劃;如果不將建置遷移視為單獨的專案,則應用程式遷移的開發、測試和部署計劃就必須將建置遷移納入考量。

當定義應用程式遷移的開發、測試、部署、試用和訓練計劃時,必須考慮建置系統遷移。這些計劃中,有一些 (例如應用程式試用計劃) 需要先完成建置系統,才能夠繼續進行應用程式遷移。所以,排程是相當重要的一點。

如果您讓一個群組為其他群組遷移建置系統,以便用於他們的應用程式遷移中,您應該先開發這個建置遷移計劃。建置系統遷移需要為許多客戶提供單獨的一項產品,建置遷移小組需要考慮的是客戶的期限。如果開發人員同時在進行建置系統遷移以及應用程式遷移,這些要點必須要涵蓋於應用程式遷移的專案計劃中。

以下的專案計劃說明可以在您決定建置遷移專案需要何種專案計劃時,協助提供指引。此處所述的個別計劃可以累加成主要的專案計劃,應該用來做為「規劃」階段期間的基準。

開發計劃

開發計劃可以使用應用程式遷移開發計劃中所定義的許多相同的原則。例如,當開發建置系統時,每個人都應該要使用原始檔控制;應該要審查指令碼和 makefile,就像其他程式碼一樣。應該要開發遷移的工具。建置系統中任何編譯的公用程式都應該要定期重新組建。

開發計劃必須細分為不同的建置系統元件,並指出將要遷移和將要取代的元件。這種從整體到細節的分析方式,可以防止發生浪廢人力的遷移作業。

建置系統的各種指令碼、應用程式和公用程式在遷移至 Windows 之後,必須進行整合。它們必須彼此搭配運作,並且與應用程式一起使用。這種開發必須在應用程式遷移之前完成,而且一定要先保持穩定才能進行應用程式遷移。請經常組建並整合建置系統的元件。

預算計劃

預算計劃會確定遷移所需要的軟硬體主要費用。預算應該要涵蓋下列事項:

  • 僅使用一次的各種 UNIX 環境,以供規劃期間使用。

  • 符合一般開發人員的工作環境的開發硬體,以及在評估流程期間所選擇的 UNIX 開發環境。

  • 測試時需要的軟體 (如果用到的話)

  • 選定的 UNIX 部署環境的規劃成本。

很明顯地,最後一個項目是一個估計值,假設在「規劃」階段所做的初步選擇在整個「遷移」和「測試」階段都是可行的。應該要預留誤差的空間;或許應該使用「規劃」階段期間確定為可接受的最昂貴解決替代方案的成本做為預算。

測試計劃

測試計劃說明了您要如何進行測試,換言之,它會說明將進行何種測試、由誰進行、在何處進行以及使用何種工具進行。它不必說明實際的測試個案或要使用的測試套件。測試計劃應說明概念驗證的設定,以便用於做為測試系統的基準。

有許多的功能測試可以在建置系統上執行:

  • 它會實際產生要求的目標嗎?(這是基本的煙霧測試 (smoke test))

  • 模組是否包含應該包含的部分?

  • 目標是否位在正確的位置?

  • 所有的選項和功能是否如預期般運作?

  • 是否正確發現過時的模組或目標?

  • 可以進行累加建置嗎?

另外也有非功能性的測試:

  • 完整的建置要花多久的時間?

  • 在建置期間,編譯了多少不必要的模組?

應該定義並包含衡量準則。

這些測試有部分會與應用程式遷移小組所進行的測試重疊,以確保其工作的正確性。「測試角色」也應該規劃要由誰負責進行哪些測試。測試計劃也應該確保設定管理機制能正常運作。如果建置系統插入版本號碼或模組識別碼,請確定它們已確實插入並且是正確的。

效能和負載測試比較少成為建置系統的問題,不過如果您的系統是個例外,還是值得考慮。有一些加速建置的技巧可以傳授給開發人員。例如,使用 makefile include 指示詞來代替 make 的遞迴呼叫常常可以加速建置,方法是建立更完整的依存性圖表;不必要的編譯就不需要進行。

規劃和設計自動化的測試工作,甚至向下延伸到建置系統輸出的檢查。在稍後的穩定階段中,將會經常執行測試,而且應該盡量在沒有人為介入的情況下執行。

部署計劃

在「規劃」階段期間,往往會忽略了為建置系統的部署建立計劃。建置系統的部署工作,必須比對應的應用程式遷移更為簡單。建置系統的部署包含兩個部分,它們常常會安裝在不同的位置:已遷移的 makefile 一般是安裝在來源樹狀目錄中;新的建置系統和環境則是安裝在各開發人員的電腦上。下面的清單將詳述這兩個選項:

  • makefile 的部署十分簡單,只要將修訂新增到來源樹狀目錄中,然後更新開發人員的來源作業版本,通知他們「部署」即可。

  • 建置系統和環境的部署將包含在各開發人員的電腦上安裝新的環境。

您的部署計劃的細節,視您的建置遷移案例而定。在「虛擬小組」案例中,部署可以是快速及非正式的,因為小組在遷移期間已經轉換了所有的 makefile。在這種情況中的部署會自動發生;應用程式遷移小組會使用新的工具和解決方案做為他們日常工作的一部分。部署計劃涵蓋了記錄建置系統,包括將如何為新進人員安置於專案中。在「明確實體」案例中,部署則較為正式且緩慢。在部署之前,必須先準備好記錄文件,而且必須向接收建置系統的開發人員取得某種形式的簽收或接受。

在這兩種情況中,都必須記錄說明:

  • 解決方案會以何種形式散發到不同小組的開發人員手中,以及他們會如何安裝解決方案。

  • 如何正確地使用解決方案。

  • 使用新環境時各小組可能會遭遇的問題,以及這些問題的解決方案。

請注意,這項資訊在虛擬小組案例中是必要的,但是屬於較不正式的記錄。

在兩種案例中,解決方案可能是以 UNIX 環境產品為基礎。您必須為這項產品的散發和安裝訂出適當且清楚的指示,並解釋這項流程和之前的 UNIX 系統上所使用的流程之間的差異。這些指示應盡量自動化並加以記錄。在實際執行環境中使用這些工具的人,應該很容易安裝及使用此解決方案。

請為應用程式開發人員規劃更簡易的安裝和升級途徑。此外,在建置系統的穩定期間,必須要為開發人員提供建置系統的更新。當建立部署計劃時,請考慮下列問題:

  • 建置系統如何提供開發人員使用?

  • 如果您需要商用的 UNIX 可攜性環境,是否暗示需要進行工具的採購?

  • 初始安裝將會如何進行?如果開發人員必須先安裝 Services for UNIX (Interix) 之類的產品,該如何提供使用?

  • 您的組織是否允許開發人員自行安裝這種類型的軟體?

  • 將會進行何種類型的更新,以及如何散發?

  • 將如何通知開發人員?

  • 如果開發人員變更建置系統,這些變更會如何回饋給建置遷移小組?

有些組織只需要建立單一網路目錄,讓開發人員可以視需要從中取得最新的穩定建置。其他公司則是組建安裝程式套件或壓製光碟。部署機制的選擇,將視您組織的需要而定。大型的組織可能會認為取得 UNIX 可攜性環境的 OEM 授權,並製作可供開發人員使用的安裝程式比較實用。

請記住,部署的工作不會因為發行遷移的應用程式而告中止;還是會有需要安裝建置系統的新進開發人員。

試用

挑選一項應用程式遷移做為試用專案。雖然其他群組一定會同時試用建置系統,但是試用專案會負責確保建置系統能夠在實際執行環境中運作。指定一項應用程式遷移做為試用專案後,代表的是專案小組必須在排程中預留時間,以便進行建置系統的最後測試。

教育訓練

遷移 make 建置系統的原因之一,是要將教育訓練減至最少,不過「使用者經驗角色」需要記錄建置系統的參數、相關的參數,以及系統中所允許的自訂和未來開發的種類。開發人員可以做什麼改變來影響他們的建置?他們要如何將這些資訊傳達給實際執行的建置人員?

建立專案排程

雖然 UMPG 具有排程所需要的大部分資訊,不過請記得 make 特有的下列考量:

  • 專案排程必須與較大型的應用程式專案排程整合。

  • 在設定專案排程時,最好在初期建立階段性目標,以建立概念驗證 (如果正在實際執行的話)。比起因為嘗試建立穩定的建置系統而延遲所有其他的遷移作業,早點取得對開發人員進行應用程式遷移有用的資訊會比較理想。

  • 如果您將建置遷移視為單獨的專案,請從如 UMPG 中定義的主要階段性目標開始。例如,建置系統將會在某個時點對開發人員發行 (UMPG 中的「發佈就緒認可」階段性目標)。如果您將建置遷移視為較大型的應用程式遷移專案的一部分,就必須建立只適用於建置系統的同等階段性目標。

  • 如果您不確定需要使用哪一種 UNIX 可攜性環境,請在排程中預留空間,以便重新進行元件的遷移。

  • 如果您的部署計劃需要建立安裝程式以及適用於建置系統的複雜套件,請記得將那段時間納入考量。通常建立安裝程式所需要的時間很容易被低估;這些時間會經由連續的發行週期而不斷累積。

設定開發和測試環境

您將會需要開發和測試這兩項環境,即使它們的硬體特性不同,但是初始設定可能是完全相同的。測試套件的安裝將會改變測試環境,以符合您的測試規格。開發環境可能會與實際執行環境類似,但也可能不同。

建置系統的開發和測試環境通常是應用程式開發人員的系統複本。實際執行環境可能會有很大的不同。例如,如果您產生內嵌式系統,實際執行環境便無法用於開發。如果實際執行環境和開發環境有很大的差異,則必須確認您是否需要一組測試,以查看建置系統的成果。換言之,如果您正在為內嵌式系統進行開發,就必須在建置之後再檢查內嵌式系統中的應用程式的測試環境嗎?如果需要這麼做,那麼通常是群組要進行建置系統遷移,以便在早期使用針對應用程式遷移群組設計的測試環境。如果不可能如此,建置系統遷移便應該使用和應用程式遷移「測試角色」所使用的相同規格和設備。

在漫長的遷移專案中,可能會修訂所包含的協力廠商軟體元件:在專案期間,可能會有新版本的 UNIX 可攜性軟體。因此,應該留意該軟體製造商的發行週期。請記住,您可能會需要使用修訂後的軟體來執行第二輪測試,以確保建置系統是否仍然穩定。

顯示: