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

Question

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

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

例如，我们有一个项目需要为 3 个不同的平台构建。每个平台可能有多个配置(例如调试、发布和其他几个)。我在新成立的项目上的目标之一是拥有一个可以让所有平台构建共存的解决方案，这使得构建和测试代码更改更加容易，因为您不必打开 3 个不同的解决方案来测试您的代码。但是 visual studio 将需要 3 * (number of base configurations) 个配置。即 PC 调试、X360 调试、PS3 调试等。

似乎这里的 makefile 解决方案要好得多。用一些基本的批处理文件或脚本包装，很容易将配置爆炸保持在最低限度，并且只为我们必须做的所有不同构建维护一小组文件。

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

谢谢。

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

Answer 1

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

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

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

立即想到的缺点:

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

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