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

Using Makefile instead of Solution/Project files under Visual Studio (2005)

提问by Mark

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.

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

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.

在 Unix 下，设置一个 makefile 非常容易，它的默认选项被用户设置（或其他配置设置）覆盖。但是在 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.

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

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.

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

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.

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

Thanks.

谢谢。

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

（编辑后提到这些是 C++ 构建）

采纳答案by Nik

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.

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

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.

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

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!

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

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

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

回答by aku

Visual studio is being built on top of the MSBuildconfigurations files. You can consider *proj and *sln files as makefiles. They allow you to fully customize build process.

Visual Studio 是在MSBuild配置文件之上构建的。您可以将 *proj 和 *sln 文件视为 makefile。它们允许您完全自定义构建过程。

回答by Ben Scheirman

While it's technically possible, it's not a very friendly solution within Visual Studio. It will be fighting you the entire time.

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

I recommend you take a look at NAnt. It's a very robust build system where you can do basically anything you need to.

我建议你看看NAnt。这是一个非常强大的构建系统，您基本上可以在其中执行任何您需要的操作。

Our NAnt script does this on every build:

我们的 NAnt 脚本在每次构建时都这样做：

1. Migrate the database to the latest version
2. Generate C# entities off of the database
3. Compile every project in our "master" solution
4. Run all unit tests
5. Run all integration tests

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

Additionally, our build server leverages this and adds 1 more task, which is generating Sandcastle documentation.

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

If you don't like XML, you might also take a look at Rake(ruby), Bake/BooBuildSystem(Boo), or Psake(PowerShell)

如果你不喜欢 XML，你也可以看看Rake(ruby)、Bake/BooBuildSystem(Boo) 或Psake(PowerShell)

回答by DevelopingChris

You can use nant to build the projects individually thus replacing the solution and have 1 coding solution and no build solutions.

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

1 thing to keep in mind, is that the solution and csproj files from vs 2005 and up are msbuild scripts. So if you get acquainted with msbuild you might be able to wield the existing files, to make vs easier, and to make your deployment easier.

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

回答by axs6791

We have a similar set up as the one you are describing. We support at least 3 different platforms, so the we found that using CMaketo mange the different Visual Studio solutions. Set up can be a bit painful, but it pretty much boils down to reading the docs and a couple of tutorials. You should be able to do virtually everything you can do by going to the properties of the projects and the solution. Not sure if you can have all three platforms builds living together in the same solution, but you can use CruiseControlto take care of your builds, and running your testing scripts as often as needed.

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