在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来照顾构建，并根据需要经常运行测试脚本。