在 Visual Studio (2005) 下使用 Makefile 代替解决方案/项目文件

Question

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

在 Unix 下，设置一个 makefile 的默认选项被用户设置（或其他配置设置）覆盖是非常容易的。但在 Visual Studio 中做这些类型的事情似乎很困难。

举例来说，我们有一个项目需要针对 3 个不同的平台进行构建。每个平台可能有多种配置（例如调试、发布和其他几种配置）。我对新组建的项目的目标之一是拥有一个可以让所有平台一起构建的解决方案，这使得构建和测试代码更改变得更容易，因为您不必只是为了测试代码而打开 3 个不同的解决方案。但 Visual Studio 将需要 3 *（基本配置数量）配置。IE。PC调试、X360调试、PS3调试等

看起来 makefile 解决方案在这里要好得多。用一些基本的批处理文件或脚本包装起来，可以很容易地将配置扩展保持在最低限度，并且只为我们必须执行的所有不同构建维护一小组文件。

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

谢谢。

（经过编辑后提到这些是 C++ 版本）

Answer 1

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

使用大量自定义构建工具的项目也可以更容易管理，例如，如果您需要编译像素/顶点着色器，或者在没有本机 VS 支持的情况下使用其他语言编写代码。

然而，您仍然需要有各种不同的项目配置，因为您需要区分每个配置的构建工具的调用（例如传递不同的命令行选项来制作）。

我立即想到的缺点是：

• 构建速度较慢：VS 在调用外部工具方面并不是特别快，甚至在首先判断是否需要构建项目方面也不是特别快。
• 尴尬的项目间依赖关系：设置依赖者来构建基础项目是很繁琐的，而确保它们以正确的顺序构建也更繁琐。我在让 SCons 做到这一点方面取得了一些成功，但要做好工作始终是一个挑战。
• 丢失一些有用的 IDE 功能：编辑并继续成为主要角色！

简而言之，您将花费更少的时间来管理项目配置，而花更多的时间来引导 Visual Studio 正常使用它。

Answer 2

Visual Studio 正在构建于 微软构建 配置文件。您可以将 *proj 和 *sln 文件视为 makefile。它们允许您完全自定义构建过程。

Answer 3

虽然这在技术上是可行的，但它在 Visual Studio 中并不是一个非常友好的解决方案。它会一直和你战斗。

我建议你看一下 南安特. 。这是一个非常强大的构建系统，您基本上可以做任何您需要做的事情。

我们的 NAnt 脚本在每次构建时都会执行此操作：

1. 将数据库迁移到最新版本
2. 从数据库生成 C# 实体
3. 编译我们的“主”解决方案中的每个项目
4. 运行所有单元测试
5. 运行所有集成测试

此外，我们的构建服务器利用这一点并添加了一项任务，即生成 Sandcastle 文档。

如果你不喜欢 XML，你也可以看看 耙 （红宝石）， 烘焙/BooBuild系统 （嘘），或者 普萨克 （电源外壳）

Answer 4

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

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

Answer 5

我们的设置与您所描述的类似。我们支持至少 3 个不同的平台，因此我们发现使用 CMake 管理不同的 Visual Studio 解决方案。设置可能有点痛苦，但基本上可以归结为阅读文档和一些教程。您应该能够通过转到项目和解决方案的属性来完成几乎所有您能做的事情。不确定您是否可以在同一个解决方案中同时构建所有三个平台，但您可以使用 巡航控制 照顾您的构建，并根据需要经常运行测试脚本。