如何在Visual Studio中构建具有不同依赖性版本的多个产品？

Question

I'm building a Ruby C Extensions and I have to build for both Ruby 1.8 and Ruby 2.0. The source code is the same, but I have to link to different Ruby libs and set different build paths.

In Xcode I was able to set up a project where the project contained the common configuration. Then I set up two targets that configured different include paths and libs as well as different output (Debug/Release) paths.

When I build I will get two products built, one for each targeted Ruby version. When I build Release I get:

• build/Release/1.8/Example.bundle
• build/Release/2.0/Example.bundle

Now I am trying to do the same thing for Visual Studio 2010. I've been looking at the Configuration Manager and Property Sheets, but I'm struggling to fond out how I can make the same type of inheritance for the targets as I can in Xcode.

1. Is it possible to have multiple targets in VS, as you can in Xcode, that produce two products from the same project when you build?

2. Do I have to create a Debug and Release configuration for each Ruby core I want to target?

Answer 1

I think I know what you are looking for (but I can't be sure, as I have no experience with Xcode.)

If you are using Visual Studio, one way you can do something like this is to set up you project properties for a build configuration (eg for Release) and then copy that config into a new build type (eg call it "Release20") and go in and change the properties that you want for the new build. You can do this in "Configuration Manager". (When you select to add a new configuration, it lets you copy all properties from an existing one.)

However, it seems that you are already familiar with this, so I'm not sure what the problem is.

Another thing you should know is that the two build configs don't stay linked together (this is not a proper inheritance and overriding of properties, like using property sheets.) If you change something in one, it doesn't affect the other.

Precisely for these reasons (in addition to some others) I myself have foregone trying to wrangle the VS build system. I now use Premake and CMake for all my projects. But of course it's quite a chore building a build system for someone else's large code base.