[cmake-developers] [CMake 0014673]: Add support for targeting a custom Visual Studio Platform?

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
http://www.cmake.org/Bug/view.php?id=14673 
====================================================================== 
Reported By:                jujjyl
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   14673
Category:                   CMake
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2013-12-30 05:56 EST
Last Modified:              2013-12-30 05:56 EST
====================================================================== 
Summary:                    Add support for targeting a custom Visual Studio
Platform?
Description: 
CMake is not able to target custom target Platforms when generating Visual
Studio projects files.

Additional Information: 
Looking through the sources, I notice that CMake hardcodes the Solution Platform
property of the generated project files, instead of allowing toolchain files to
choose which Platform to generate project+solution files for.

There are multiple Visual Studio/MSBuild projects in development that create new
custom build Platforms into VS itself, see e.g. the following:

https://github.com/juj/vs-tool (I am the author of this)
  - Adds new platforms "Clang", "Emscripten", "MinGW" and "NaCl"
https://code.google.com/p/vs-android/
  - Adds new platform for Android
https://developers.google.com/native-client/devguide/devcycle/vs-addin#install
  - Adds new platform for NaCl.

These plugins are more featured than just wrapping NMake/MinGW Make/Cygwin Make
Makefile invocations to drive the build. The approach is that they implement a
new MSBuild platform target DLLs written in .Net that enable MSBuild to build
for those platforms, presenting integrated project property pages for the
platforms.

I see that CMake hardcodes support in the sources for only the MS built-in
platforms "win32", "x64" and "Itanium". I would like to be able to generate
Visual Studio project files for CMake projects for the above platforms, so that
I can use the VS IDE to edit and build the project for those targets. 

To see what it would require to add support for the Emscripten platform, I
forked the CMake sources and hacked a few commits in that let me do basic
CMake+Visual Studio+Emscripten targeting. In the end, I only needed to do one
change:

https://github.com/juj/CMake/commit/b526ab42492ec1dfc999d85c15b6e930ebb0afe7

The generator object gets allocated all the way in the startup of CMake, so I
could not make a string property in the CMake toolchain script that would define
the target Platform. I resorted to using the convention of parsing that -G
"Visual Studio 10 <foo>" will generate for the VS Platform "foo".

This let me do (at least basic) builds of CMake projects for Emscripten. I
suspect though that in the long run, there would be need to be able to add
custom XML properties in the generated VS project files that are
platform-specific. For example, I initially had to remove this hardcoded logic:
https://github.com/juj/CMake/commit/ea37570f1a682dfd017fbbed72de7cd3b18d8a4c ,
but later on, we added a workaround to Emscripten compiler itself so that it
doesn't get confused by this directive:
https://github.com/kripken/emscripten/pull/1946 .

I think there are too many target Platform plugins out there in development that
it doesn't make sense to hardcode support for each of them specifically into the
CMake C++ sources. Perhaps it would be best to develop some kind of generic set
of CMake variables/functions for supporting customizing VS project file
generation, so that the toolchain.cmake files for each platform could then
configure in detail what they need to generate in the VS project XML files.

What do you think about all this? How would this be accomplished cleanly?

Best Regards,
   Jukka

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2013-12-30 05:56 jujjyl         New Issue                                    
======================================================================