2013-05-02 147 views
8

我的印象是,這個問題被問了100次,但從未完全回答。處理C++依賴關係(跨平臺)

我正在開發一個小型項目,在某些時候應該針對三大PC平臺(Windows,Mac & GNU/Linux)發佈,因此儘早將技術鎖定在技術上是一個壞主意。幸運的是,不幸的是,現在,在早期的開發過程中,我們只針對32位Windows。

在代碼級別上,如果您選擇正確的庫,跨平臺開發相對容易。同時在多個平臺上構建軟件相對比較簡單,我正在研究使用GYP還是CMake。

問題是依賴關係。要構建您需要的項目:SDL,SDL_image,SDL_ttf,iconv,libxml2,libxmlmm,sigC++,wxWidgets,glew,bullet,openALsoft以及稍後可能會添加的更多內容。

到目前爲止,我已經發現了三個選項:在源

  1. 檢查,並建立他們作爲該項目的一部分
  2. 檢查二進制文件
  3. 管理源代碼樹的外部依賴性

第一個看起來像是矯枉過正,因爲你需要基本上保持你的庫和你的自定義構建系統的叉子。

當您的目標只有一個或兩個平臺時,第二個選項聽起來像是要做的事情。但是如果你計算所有不同的目標,包括32/64位變體,這也開始膨脹成幾乎不可管理的東西。

第三個選項取決於環境。如果你讓你的開發人員手動處理依賴關係,你將永遠不會睡在附近。只是獲得構建並準備使用的每個依賴關係幾乎是不可能的。更不用說,你不能確保每個開發人員使用正確的版本。

如果您看其他語言,他們會以不同的方式解決問題。使用像npm,marvin或phing這樣的系統,您只需在項目中維護一些配置文件,然後工具就可以獲取所需的任何依賴關係。

我正在考慮集中構建依賴關係,將它們打包到zip/deb/rpm /無論什麼軟件包中,並將它們放入存儲庫。然後,每個開發人員都會在構建之前將其平臺的依賴關係複製到存儲庫(但不檢查它們)。這將優選地自動作爲預構建步驟來完成。

我特別不想要一個額外的構建系統。我環顧四周,唯一遠程做我想要的東西可能是常春藤。但是,我要麼錯過了一些東西,要麼常春藤完全在設計這個問題。有一些簡單的東西可以解決這個問題嗎?

我是建立自己的英寸。

+0

列表中的第三種方式是有多少個較小/獨立的企業和開源人員。首先是有多少大企業。這完全取決於你有什麼資源。 – 2013-05-02 12:38:45

+1

如果你的目標是N個不同的平臺,你將不得不在不同的平臺上重複測試*,因此*重複(最好至少每天一次),對吧?這意味着您將需要在構建文件中正確配置*和*每個平臺的依賴關係,因此您無法「自然」獲取它們。通過一些linux的包裝系統。所以爲了做到這一點,您需要經常將這些依賴關係部署到您的構建環境中,這意味着您將需要自動執行它。根據平臺的不同,最好用選項2或3完成。我沒有得到選項2的「氣球」。 – 2013-05-02 13:11:29

+0

我的意思是膨脹失控,就是越多的項目你有更多的努力。 (目標x項目)雖然你完全知道**什麼進入了構建,它似乎有點過度給我。在我的「第一」工作中(這是我自己的工作),他們將一切二進制文件放入一箇中央源代碼庫(一個明確的VOB文件),但是由於他們將每個版本並行化,這只是一個榮耀的FTP。我可以爲每個依賴使用git-submodules,雖然... – rioki 2013-05-02 13:23:39

回答

3

我會建議不要建立自己的。

我們使用ant/ivy/Hudson來自動化我們的跨平臺(Windows和Linux)構建。我們還使用Nexus(Maven)作爲我們的工件存儲庫,其中包含我們的第三方庫以及我們自己的應用程序的平臺特定版本。 Hudson與Perforce(我們的軟件存儲庫)整合在一起。

我們也正在創建一切的單獨的32位和64位工件,而ant/ivy會使這個工作變得更容易。

它對我們來說非常好。