代码之家 › 专栏 › 技术社区 › Mark

在Visual Studio下使用Makefile而不是解决方案/项目文件(2005)

makefile visual-studio c++

Mark · 技术社区 · 18 年前

是否有人使用VisualStudioC++生成的MaxFrm(VS 2005),而不是使用项目/解决方案设置。对于我们来说,项目/解决方案的工作方式并不直观,当您试图使用特定的编译时标志调整构建时,会导致配置爆炸。

在Unix下,设置默认选项被用户设置(或其他配置设置)覆盖的makefile非常容易。但是在VisualStudio中做这些事情似乎很困难。

举例来说,我们有一个项目需要为3个不同的平台进行构建。每个平台可能有几个配置(例如调试、发布和其他几个)。我在一个新成立的项目上的目标之一是,有一个解决方案,可以让所有平台构建一起进行,这使得构建和测试代码更改变得更容易,因为您不必打开3个不同的解决方案来测试您的代码。但是VisualStudio需要3*(基本配置数)配置。i、 e.PC调试、X360调试、PS3调试等。

似乎makefile解决方案在这里更好。用一些基本的批处理文件或脚本包装,可以很容易地将配置分解保持在最低限度,并且只为我们必须执行的所有不同构建维护一小部分文件。

但是,我没有在VisualStudio下使用makefiles的经验,我想知道其他人是否有可以分享的经验或问题。

谢谢

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

5 回复 | 直到 12 年前

Nik 18 年前

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

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

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

脑海中浮现的直接负面影响:

较慢的构建:VS在调用外部工具方面,甚至在确定是否需要首先构建项目方面都不是特别快。
失去一些有用的IDE功能:编辑&继续成为主要的一个!

aku 18 年前

VisualStudio正在 MSBuild

Ben Scheirman 18 年前

NAnt . 这是一个非常健壮的构建系统,基本上你可以做任何你需要做的事情。

我们的NAnt脚本在每个构建中都执行此操作:

从数据库生成C#实体
运行所有单元测试
运行所有集成测试

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

Rake (红宝石), Bake/BooBuildSystem (嘘),或者 Psake (PowerShell)

DevelopingChris 18 年前

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

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

axs6791 18 年前

我们的设置与您描述的类似。我们至少支持3种不同的平台,因此我们发现 CMake 不确定是否可以将所有三个平台构建放在同一个解决方案中,但可以使用 CruiseControl