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.
有没有人使用makefile进行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 Debug,X360 Debug,PS3 Debug等。
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解决方案在这里要好得多。使用一些基本的批处理文件或脚本,可以很容易地将配置explotion保持在最低限度,并且只为我们必须执行的所有不同构建维护一小组文件。
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 ++版本)
5 个解决方案
#1
5
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在调用外部工具方面并不是特别快,甚至无法确定是否需要首先构建项目。
尴尬的项目间依赖关系:设置得很好,以便dependee导致基础项目的构建,以及确保它们以正确的顺序构建的fiddlier。让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正常使用它。
#2
2
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正在构建在MSBuild配置文件之上。您可以将* proj和* sln文件视为makefile。它们允许您完全自定义构建过程。
#3
1
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脚本在每个构建中执行此操作:
- Migrate the database to the latest version
- Generate C# entities off of the database
- Compile every project in our "master" solution
- Run all unit tests
- Run all integration tests
将数据库迁移到最新版本
从数据库生成C#实体
在我们的“主”解决方案中编译每个项目
运行所有单元测试
运行所有集成测试
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)
#4
0
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更容易,并使您的部署更容易。
#5
0
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.
我们有一个与您描述的类似的设置。我们支持至少3个不同的平台,因此我们发现使用CMake来管理不同的Visual Studio解决方案。设置可能有点痛苦,但它几乎可以归结为阅读文档和一些教程。通过转到项目属性和解决方案,您应该能够做几乎所有可以做的事情。不确定是否可以将所有三个平台构建在同一个解决方案中,但是您可以使用CruiseControl来处理构建,并根据需要经常运行测试脚本。
#1
5
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在调用外部工具方面并不是特别快,甚至无法确定是否需要首先构建项目。
尴尬的项目间依赖关系:设置得很好,以便dependee导致基础项目的构建,以及确保它们以正确的顺序构建的fiddlier。让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正常使用它。
#2
2
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正在构建在MSBuild配置文件之上。您可以将* proj和* sln文件视为makefile。它们允许您完全自定义构建过程。
#3
1
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脚本在每个构建中执行此操作:
- Migrate the database to the latest version
- Generate C# entities off of the database
- Compile every project in our "master" solution
- Run all unit tests
- Run all integration tests
将数据库迁移到最新版本
从数据库生成C#实体
在我们的“主”解决方案中编译每个项目
运行所有单元测试
运行所有集成测试
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)
#4
0
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更容易,并使您的部署更容易。
#5
0
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.
我们有一个与您描述的类似的设置。我们支持至少3个不同的平台,因此我们发现使用CMake来管理不同的Visual Studio解决方案。设置可能有点痛苦,但它几乎可以归结为阅读文档和一些教程。通过转到项目属性和解决方案,您应该能够做几乎所有可以做的事情。不确定是否可以将所有三个平台构建在同一个解决方案中,但是您可以使用CruiseControl来处理构建,并根据需要经常运行测试脚本。