在 Visual Studio (2005) 下使用 Makefile 代替解决方案/项目文件
是否有人有使用 makefile 进行 Visual Studio C++ 构建（在 VS 2005 下）而不是使用项目/解决方案设置的经验？ 对于我们来说，项目/解决方案的工作方式并不直观，当您尝试使用特定的编译时标志调整构建时，会导致配置爆炸。
在 Unix 下，设置一个 makefile 的默认选项被用户设置（或其他配置设置）覆盖是非常容易的。 但在 Visual Studio 中做这些类型的事情似乎很困难。
举例来说，我们有一个项目需要针对 3 个不同的平台进行构建。 每个平台可能有多种配置（例如调试、发布和其他几种配置）。 我对新组建的项目的目标之一是拥有一个可以让所有平台一起构建的解决方案，这使得构建和测试代码更改变得更容易，因为您不必只是为了测试代码而打开 3 个不同的解决方案。 但 Visual Studio 将需要 3 *（基本配置数量）配置。 即 PC 调试、X360 调试、PS3 调试等。
看起来 makefile 解决方案在这里要好得多。 用一些基本的批处理文件或脚本包装起来，可以很容易地将配置扩展保持在最低限度，并且只为我们必须执行的所有不同构建维护一小组文件。
但是，我没有在 Visual Studio 下使用 makefile 的经验，想知道其他人是否有可以分享的经验或问题。
谢谢。
（经过编辑后提到这些是 C++ 版本）
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)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我发现大型项目的 makefile 有一些好处，主要与统一项目设置的位置有关。 如果源文件列表、包含路径、预处理器定义等都位于 makefile 或其他构建配置文件中，那么管理它们会更容易一些。 对于多个配置，添加包含路径意味着您需要确保通过 Visual Studio 繁琐的项目属性手动更新每个配置，随着项目规模的增长，这可能会变得非常乏味。
使用大量自定义构建工具的项目也可以更容易管理，例如，如果您需要编译像素/顶点着色器，或者在没有本机 VS 支持的情况下使用其他语言编写代码。
然而，您仍然需要有各种不同的项目配置，因为您需要区分每个配置的构建工具的调用（例如传递不同的命令行选项来制作）。
我立即想到的缺点是：
简而言之，您将花费更少的时间来管理项目配置，而花更多的时间来引导 Visual Studio 正常使用它。
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:
In short, you'll spend less time managing your project configurations, but more time coaxing Visual Studio to work properly with it.
Visual Studio 构建在 MSBuild 配置文件之上。 您可以将 *proj 和 *sln 文件视为 makefile。 它们允许您完全自定义构建过程。
Visual studio is being built on top of the MSBuild configurations files. You can consider *proj and *sln files as makefiles. They allow you to fully customize build process.
虽然这在技术上是可行的，但它在 Visual Studio 中并不是一个非常友好的解决方案。 它会一直和你战斗。
我建议您查看NAnt。 这是一个非常强大的构建系统，您基本上可以做任何您需要做的事情。
我们的 NAnt 脚本在每次构建时都会执行此操作：
此外，我们的构建服务器利用此功能并添加 1更多任务，正在生成 Sandcastle 文档。
如果您不喜欢 XML，您还可以看看 Rake (ruby)、Bake/BooBuildSystem (Boo)，或 Psake (PowerShell)
While it's technically possible, it's not a very friendly solution within Visual Studio. It will be fighting you the entire time.
I recommend you take a look at NAnt. It's a very robust build system where you can do basically anything you need to.
Our NAnt script does this on every build:
Additionally, our build server leverages this and adds 1 more task, which is generating Sandcastle documentation.
If you don't like XML, you might also take a look at Rake (ruby), Bake/BooBuildSystem (Boo), or Psake (PowerShell)
您可以使用 nant 单独构建项目，从而替换解决方案，并且有 1 个编码解决方案而没有构建解决方案。
要记住的一件事是，vs 2005 及更高版本的解决方案和 csproj 文件是 msbuild 脚本。 因此，如果您熟悉 msbuild，您可能能够利用现有文件，使 vs 更容易，并使您的部署更容易。
You can use nant to build the projects individually thus replacing the solution and have 1 coding solution and no build solutions.
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.
我们的设置与您所描述的类似。 我们支持至少 3 个不同的平台，因此我们发现使用 CMake 来管理不同的 Visual Studio 解决方案。 设置可能有点痛苦，但基本上可以归结为阅读文档和一些教程。 您应该能够通过转到项目和解决方案的属性来完成几乎所有您能做的事情。
不确定是否可以在同一解决方案中同时构建所有三个平台，但您可以使用 CruiseControl 负责您的构建，并根据需要经常运行您的测试脚本。
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 CMake to 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 CruiseControl to take care of your builds, and running your testing scripts as often as needed.