有没有人有使用Visual Studio C ++生成的makefile(在VS 2005下)的经验，而不是使用项目/解决方案设置的经验。对于我们来说，项目/解决方案的工作方式不直观，当我们尝试使用特定的编译时标记来调整构建时，会导致配置爆炸。

在Unix下，很容易设置一个makefile，该文件的默认选项被用户设置(或者其他配置设置)覆盖。但是在Visual Studio中执行这些类型的操作似乎很困难。

举例来说，我们有一个项目，需要针对3个不同的平台进行构建。每个平台可能有几种配置(例如，调试，发行和其他几种)。我在一个新成立的项目中的目标之一是拥有一个可以使所有平台构建在一起的解决方案，这使构建和测试代码更改更加容易，因为我们不必打开3个不同的解决方案来测试代码。但是Visual Studio将需要3 *(基本配置数量)配置。即PC调试，X360调试，PS3调试等。

看起来，makefile解决方案在这里要好得多。包裹一些基本的批处理文件或者脚本，可以很容易地将配置展开次数降至最低，并且只为我们要做的所有不同构建维护一小组文件。

但是，我没有在Visual Studio下使用makefile的经验，并且想知道其他人是否有可以共享的经验或者问题。

谢谢。

(编辑后提到这些是C ++构建)

解决方案

回答

Visual Studio是基于MSBuild配置文件构建的。我们可以将* proj和* sln文件视为makefile。它们使我们可以完全自定义构建过程。

回答

我们可以使用nant单独构建项目，从而替换解决方案，并且只有1个编码解决方案，而没有构建解决方案。

要记住的一件事是vs 2005及更高版本的解决方案和csproj文件是msbuild脚本。因此，如果我们熟悉msbuild，则可以使用现有文件，使vs变得更容易，并使部署更容易。

回答

尽管从技术上讲是可行的，但在Visual Studio中这并不是一个非常友好的解决方案。它将一直困扰着我们。

我建议我们看一下NAnt。这是一个非常强大的构建系统，我们可以在其中进行所需的任何操作。

我们的NAnt脚本会在每个版本上执行此操作：

• 将数据库迁移到最新版本
• 从数据库生成C＃实体
• 编译我们"主"解决方案中的每个项目
• 运行所有单元测试
• 运行所有集成测试

此外，我们的构建服务器利用了这一点，并增加了1个任务，该任务正在生成Sandcastle文档。

如果我们不喜欢XML，也可以看看Rake(ruby)，Bake / BooBuildSystem(Boo)或者Psake(PowerShell)

回答

我发现大型项目的makefile有一些好处，主要与统一项目设置的位置有关。如果它们都在makefile或者其他构建配置文件中，则管理源文件列表，包括路径，预处理器定义等会稍微容易一些。对于多种配置，添加包含路径意味着我们需要确保通过Visual Studio的灵活项目属性手动更新每个配置，随着项目规模的增加，这可能会变得非常乏味。

使用大量自定义构建工具的项目也可以更轻松地进行管理，例如，如果我们需要编译像素/顶点着色器，或者使用不具有本机VS支持的其他语言编写的代码。

但是，我们仍然需要具有各种不同的项目配置，因为我们需要区分每个配置对构建工具的调用(例如，传递要进行的不同命令行选项)。

马上想到的直接缺点是：

• 较慢的构建：VS在调用外部工具方面并不是特别快，甚至还没有弄清它是否首先需要构建项目。
• 尴尬的项目间依赖关系：进行设置很麻烦，以使受抚养人可以使基础项目得以构建，并且要灵活地确保以正确的顺序进行构建。让SCons做到这一点我已经取得了一些成功，但是要一直努力工作始终是一个挑战。
• 失去了一些有用的IDE功能：编辑和继续是主要功能！

简而言之，我们将花费更少的时间来管理项目配置，而花更多的时间哄骗Visual Studio使其正常工作。

回答

我们有与我们描述的类似的设置。我们至少支持3个不同的平台，因此我们发现使用CMake可以管理不同的Visual Studio解决方案。设置可能会有些痛苦，但是它几乎可以归结为阅读文档和一些教程。通过转到项目和解决方案的属性，我们应该几乎可以执行所有操作。
不确定是否可以在同一解决方案中同时使用这三个平台构建，但是可以使用CruiseControl进行构建，并根据需要频繁运行测试脚本。