在Visual Studio（2005）下使用Makefile而不是Solution / Project文件 [英] Using Makefile instead of Solution/Project files under Visual Studio (2005)

问题描述

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

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

例如，我们有一个项目需要为3个不同的平台构建。每个平台可能具有多个配置（例如调试，发布和其他几个配置）。我的一个新项目的目标之一是有一个解决方案，所有的平台构建生活在一起，这使得构建和测试代码更改更容易，因为你不必打开3种不同的解决方案，只是为了测试你的代码。但是visual studio将需要3 *（基本配置数量）配置。即PC Debug，X360 Debug，PS3 Debug等。

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

但是，我没有在visual studio下makefiles的经验，想知道其他人是否有经验或问题，他们可以共享。

谢谢。 / p>

（后编辑，提及这些是C ++版本）

解决方案

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

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

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

立即感觉到下列阴影：

• 放慢建立：VS不是特别快在调用外部工具时，或者甚至确定是否需要首先构建一个项目。


• 尴尬的项目间依赖关系：很容易设置，使得被依赖者导致基础项目建设，和fiddlier，以确保他们建立在正确的顺序。我已经取得了一些成功让SCons这样做，但它总是一个挑战，以获得良好的工作。


• 失去一些有用的IDE功能：编辑&

简而言之，您将花费更少的时间管理项目配置，工作正常。

Does anyone have experience using makefiles for Visual Studio C++ builds (under VS 2005) as opposed to using the project/solution setup. For us, the way that the project/solutions work is not intuitive and leads to configuruation explosion when you are trying to tweak builds with specific compile time flags.

Under Unix, it's pretty easy to set up a makefile that has its default options overridden by user settings (or other configuration setting). But doing these types of things seems difficult in Visual Studio.

By way of example, we have a project that needs to get build for 3 different platforms. Each platform might have several configurations (for example debug, release, and several others). One of my goals on a newly formed project is to have a solution that can have all platform build living together, which makes building and testing code changes easier since you aren't having to open 3 different solutions just to test your code. But visual studio will require 3 * (number of base configurations) configurations. i.e. PC Debug, X360 Debug, PS3 Debug, etc.

It seems like a makefile solution is much better here. Wrapped with some basic batchfiles or scripts, it would be easy to keep the configuration explotion to a minimum and only maintain a small set of files for all of the different builds that we have to do.

However, I have no experience with makefiles under visual studio and would like to know if others have experiences or issues that they can share.

Thanks.

(post edited to mention that these are C++ builds)

解决方案

I've found some benefits to makefiles with large projects, mainly related to unifying the location of the project settings. It's somewhat easier to manage the list of source files, include paths, preprocessor defines and so on, if they're all in a makefile or other build config file. With multiple configurations, adding an include path means you need to make sure you update every config manually through Visual Studio's fiddly project properties, which can get pretty tedious as a project grows in size.

Projects which use a lot of custom build tools can be easier to manage too, such as if you need to compile pixel / vertex shaders, or code in other languages without native VS support.

You'll still need to have various different project configurations however, since you'll need to differentiate the invocation of the build tool for each config (e.g. passing in different command line options to make).

Immediate downsides that spring to mind:

• Slower builds: VS isn't particularly quick at invoking external tools, or even working out whether it needs to build a project in the first place.
• Awkward inter-project dependencies: It's fiddly to set up so that a dependee causes the base project to build, and fiddlier to make sure that they get built in the right order. I've had some success getting SCons to do this, but it's always a challenge to get working well.
• Loss of some useful IDE features: Edit & Continue being the main one!

In short, you'll spend less time managing your project configurations, but more time coaxing Visual Studio to work properly with it.

这篇关于在Visual Studio（2005）下使用Makefile而不是Solution / Project文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！