在Visual Studio下使用Makefile代替解決方案/項目文件（2005）

Question

有沒有人有使用Visual Studio C++構建的makefile（在VS 2005下）而不是使用項目/解決方案設置的經驗。對於我們來說，項目/解決方案的工作方式並不直觀，並且在您嘗試使用特定的編譯時間標誌調整構建時會導致配置的爆炸式增長。

在Unix下，設置一個默認選項被用戶設置（或其他配置設置）覆蓋的makefile是非常容易的。但在Visual Studio中做這些事情似乎很困難。

舉例來說，我們有一個需要爲3個不同平臺構建的項目。每個平臺可能有多種配置（例如調試，發佈和其他幾種）。我在新成立的項目中的一個目標是建立一個解決方案，讓所有平臺可以共同生活，這使得構建和測試代碼更改變得更加容易，因爲您不必爲了測試代碼而打開3種不同的解決方案。但視覺工作室將需要3 *（基本配置的數量）配置。即PC調試，X360調試，PS3調試等。

這似乎是一個makefile解決方案在這裏好得多。用一些基本的批處理文件或腳本包裝起來，可以很容易地將配置文件展開到最低限度，並且只需要爲我們必須完成的所有不同的構建維護一小組文件。

但是，我沒有使用visual studio下的makefile的經驗，並想知道其他人是否有經驗或可以共享的問題。

謝謝。

（編輯後提的是，這些都是C++編譯）

Answer 1

我發現有大項目的makefile一些好處，主要涉及統一項目設置的位置。管理源文件列表，包括路徑，預處理器定義等等，如果它們都在makefile或其他構建配置文件中，則會更容易一些。通過多種配置，添加包含路徑意味着您需要確保通過Visual Studio的易用項目屬性手動更新每個配置，隨着項目規模的增大，這些屬性會變得非常繁瑣。它使用了很多定製的

項目構建工具可以更容易地管理過，例如，如果你需要編譯像素/頂點着色引擎，或代碼在其他語言中沒有原生支持VS。

您仍然需要然而，具有各種不同的項目配置，因爲你需要區分每個配置構建工具的調用（例如，通過在不同的命令行選項來生產）。

映入腦海立即缺點：

• 較慢構建：VS是不是在調用外部工具，甚至工作了，是否需要建設擺在首位的一個項目特別快。
• 尷尬的項目間的依賴關係：這是繁瑣的設置，使得dependee導致基地項目建設，並fiddlier以確保他們得到建在正確的順序。我已經取得了一些成功，讓SCons能夠做到這一點，但要做好工作始終是一項挑戰。
• 損失一些有用的IDE功能：編輯&繼續是主要的一個！

簡而言之，您將花更少的時間來管理項目配置，但是有更多的時間讓Visual Studio正確地使用它。

Answer 2

Visual Studio是正在興建的MSBuild配置文件的頂部。您可以將* proj和* sln文件視爲makefile。它們允許您完全自定義構建過程。

Answer 3

您可以使用nant來單獨構建項目，從而替換解決方案，並擁有1個編碼解決方案並且不需要構建解決方案。

需要記住的一件事情是，vs 2005及以上的解決方案和csproj文件是msbuild腳本。所以，如果你熟悉msbuild，你可能會運用現有的文件，使vs更容易，並使你的部署更容易。

Answer 4

雖然它在技術上是可行的，但在Visual Studio中它不是一個非常友好的解決方案。它會一直與你戰鬥。

我建議你看看NAnt。這是一個非常強大的構建系統，你可以基本上做你需要的任何事情。

我們的楠腳本做到這一點對每次構建：

1. 遷移數據庫到最新版本
2. 生成C＃實體關閉數據庫
3. 編譯在我們的「主人」的解決方案每個項目
4. 運行所有單元測試
5. 運行所有集成測試

另外，我們的構建服務器利用它並增加了另外1個任務，即生成Sandcastle文檔。

如果你不喜歡XML，你也可以看看Rake（紅寶石），Bake/BooBuildSystem（BOO），或Psake（PowerShell中）

Answer 5

我們有一個類似的設置，如你所描述的一個。我們至少支持3種不同的平臺，因此我們發現使用CMake來管理不同的Visual Studio解決方案。設置可能會有點痛苦，但它可以歸結爲閱讀文檔和一些教程。您應該能夠通過參與項目的屬性和解決方案來做幾乎所有可以做的事情。 不知道您是否可以將所有三個平臺搭建在同一解決方案中，但您可以使用CruiseControl來照顧構建，並根據需要經常運行測試腳本。