Using Visual Studio for the IDE, but using CMake for cross-platform configuration

Question

I have found a lot of similar questions to what I'm about to ask, but they don't seem to flat out help me understand how to do what I want to do, assuming it's even feasible.

I enjoy Visual Studio quite a bit, and I want to use it as a development environment for C++ projects, but I also want to be able to build any projects of mine on my dual boot Linux system if I want. I also want to be able to organize my headers and source files into a specific directory structure on a shared drive. I want to use CMake to configure a project to build it either with Make on Linux or Visual Studio on Windows.

So is it possible to maintain a project in Visual Studio 2012 Pro to take advantage of its IntelliSense and compiling for the sake of quickly writing code and testing it, and then easily making the source files part of a CMake configuration in a different directory (I figure I will still have to maintain my CMake .txt files no matter what)?

I can do something like copying my source from my project directory to my CMake files folder every time I add or modify the code, and then update my CMake .txt files, but that seems time consuming.

I know there is a converter that converts solutions into CMake files. Is that my best option? If so, does it work well?

Answer 1

My best answer for your question:

While I cannot recommend this tool since I have not used it, it seems to be the closest in line to what you are looking for.

http://sourceforge.net/projects/vcproj2cmake/

It requires a Ruby runtime to be installed on your machine, but it will generate CMakeLists.txt files based on your Visual Studio project.

I would be cautious depending on this too much, as there may be some subtle CMake nuances that are lost in the conversion, but it has several favorable reviews and will certainly make the process easier, even if there are some manual steps involved prior to checking in (to verify the CMake script is correct).

Perhaps you can integrate this with unit testing to verify the integrity of the CMake scripts? And you could always offer patches for issues you do find.

A potential alternative:

I am inferring some things, so forgive me if I am making any assumptions.

If your goals are to be cross platform and CMake isn't a requirement as a technology (just a means to that ends), but you don't want to adopt using the recommended CMake workflow because it's not very intuitive (I can totally understand that), perhaps you can take a look at Premake, which is newer, but still a fairly robust project generation tool:

I've found that the syntax (pure Lua) is much easier to grok, and it models its projects much more closely to Visual Studio solutions. This might be a more natural workflow for you.

Also it's open source, and I found it's actually surprisingly easy to add extensions to it (it's been a year since I last used it so, and I am not sure what the state of it is in now). Perhaps you could build a reverse generator as well, since the library comes complete with a Visual Studio project parser and with a little creativity you could have it generate in both directions.

I chose not to adopt it a year ago, because at that time it had difficulty generating Xcode projects that depended on one another (perhaps it's fixed!). I didn't have any problems with Makefiles or Visual Studio solutions though.

A final recommendation

The reason I would not recommend reverse generating project generation scripts from a Visual Studio project is simply that it puts a very awkward dependency on your project. Visual Studio projects are not standardized, or even open - and if Microsoft changes the format you could break your workflow until you or someone else creates a patch for your reverse-generator to get you working again.

You could argue that project generation shares the same problems, but Visual Studio has historically always been backwards compatible - or at least shipping with tools to perform project updating. Generating a project in an older version will most likely always work, while trying to parse a newer revision of a Visual Studio solution would be much more prone to error and breakage.

If this is for a serious production project that you hope will continue to be used and maintained for many years to come, I would strongly advise adopting a proven workflow (working directly in CMake or Premake files) even if it's less than ideal or uncomfortable at first for developers. If it's going to be a long-term project, the time it would take you to get familiar in the new workflow would be dwarfed by the time it would take you to continue to maintain an ad hoc build system across multiple platforms and varying teams. Plus, it would add another tool to your belt as a developer. Just my two cents.

Answer 2

Considering my recent experience, when I managed to use CMake to generate an Eclipse or Visual Studio solution file, I do not recommend you to convert solution into a CMake file automatically. Visual Studio project files contain excessive information and parameters, which are often not needed, not directly supported by CMake (functionality expressed with different constructs), or not supported.

Also the solution's layout for all the sources and project files might be quite strange and not convenient for other platforms.

I estimate cleaning up the generated file would take more time than writing a clean CMake file from scratch. It is also a more reasonable way, as you have the full control of the project structure.

In my case, I ended up with the following CMake command to generate a Visual Studio solution:

cmake -G "Visual Studio 10" -D DEBUG=0 .

And for a command-line batch-build and install on Windows, I do:

cmake --build . --target install --config VC_CONFIGURATION_1  -- "/v:m"
cmake --build . --target install --config VC_CONFIGURATION_2  -- "/v:m"

The CMake file itself is cross-platform. Of course, it has a couple of Windows-specific lines defining configurations, and the WIN32 option in add_executable(), but you can condition them for this platform only.