简体   繁体   中英

Building on Windows XP, when development is on VS2012?

We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11). (We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)

But we've hit a little roadblock:

Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.

Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.

Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.

What are our options?

Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?

In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"

Here is what we do:

Use CMake

CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.

You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).

A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.

A big con : You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)

Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.

Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):

  • Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
  • Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM