当前位置:  开发笔记 > 编程语言 > 正文

在Visual Studio(2005)下使用Makefile而不是Solution/Project文件

如何解决《在VisualStudio(2005)下使用Makefile而不是Solution/Project文件》经验,为你挑选了1个好方法。

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

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

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

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

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

谢谢.

(编辑后发现这些是C++版本)



1> Nik..:

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

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

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

想到的直接缺点:

构建速度较慢:VS在调用外部工具方面并不是特别快,甚至无法确定是否需要首先构建项目.

尴尬的项目间依赖关系:设置这样做是非常繁琐的,以便依赖项导致基础项目的构建,以及确保它们以正确的顺序构建的繁琐.让SCons做到这一点我取得了一些成功,但要让自己运作良好总是一个挑战.

丢失一些有用的IDE功能:编辑并继续成为主要功能!

简而言之,您将花费更少的时间来管理项目配置,但有更多的时间诱使Visual Studio与其一起正常工作.

推荐阅读
TXCWB_523
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有