C++/CLI y CMake

Question

Estoy tratando de configurar un proyecto de C++/CLI utilizando cmake. He tenido éxito haciendo esto con Visual Studio 2010, pero ahora estoy trabajando con una solución legado que requiere Visual Studio 2008. En Visual Studio 2010, es suficiente para configurar mi cmake como esto:

set_target_properties(${PROJECT_NAME} PROPERTIES VS_DOTNET_REFERENCES "${CMAKE_CURRENT_SOURCE_DIR}/../OrionMaster/3rdParty/GMap.NET.Core.dll;System;System.Core;System.Data;System.Drawing;System.Xml;WindowsBase") 
set_target_properties(${PROJECT_NAME} PROPERTIES COMPILE_FLAGS "/clr /EHa") 
set_target_properties(${PROJECT_NAME} PROPERTIES DEBUG_POSTFIX "d") 

if(CMAKE_CXX_FLAGS_DEBUG MATCHES "/RTC1") 
    string(REPLACE "/RTC1" " " CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}") 
endif() 

if(CMAKE_CXX_FLAGS MATCHES "/EHsc") 
    string(REPLACE "/EHsc" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") 
endif() 

Cuando Luego examino el proyecto en Visual Studio 2010, puedo ver todas las referencias y se activa el "Common Language Runtime Support". Cuando lo intento en Visual Studio 2008, no veo ninguna referencia, y el proyecto está configurado en "No Common Language Runtime Support". Si luego miro las opciones del compilador, puedo ver que/clr se está pasando al compilador . Sin embargo, todavía tengo muchos errores de compilación, probablemente porque le faltan referencias. ¿Alguien sabe una manera de configurar esto correctamente?

Answer 1

La única referencia de código fuente "real" a la propiedad VS_DOTNET_REFERENCES está en el archivo de origen de CMake Source/cmVisualStudio10TargetGenerator.cxx.

Lo que esto significa en la práctica: VS_DOTNET_REFERENCES solo se implementa para el generador CMake para Visual Studio 2010 y cualquiera de los generadores que hereden de él. (Que ahora existe en la última versión de CMake para VS 2012 y 2013 ...)

Es probable que sea posible modificar el código fuente de CMake para admitir esta propiedad para versiones anteriores de Visual Studio, pero aún no se ha hecho en este punto.

Answer 2

Como señala @DLRdave, CMake solo hace esto para el generador de Visual Studio 2010.

Pruebe esta solución en lugar de VS_DOTNET_REFERENCES para otros generadores:

# Note that /FU and ${asmPath} must not be separated by a space, else CMake 
# will remove duplicate "/FU" options. 
target_compile_options(target PRIVATE "/FU${asmPath}") 

Para los conjuntos sistema como System.dll, PresentationCore.dll, etc Usted debe proporcionar una ruta absoluta completa al compilador a través asmPath. Debe usar los ensamblajes de referencia y no los ensamblajes no instalados en su computadora. A modo de ejemplo, por un marco blanco de 3.5 en Visual Studio 2008, que había necesidad de buscar el archivo de referencia en estos directorios, en este orden:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5 
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0 
C:\Windows\Microsoft.NET\Framework\v2.0.50727 

Se habrá dado cuenta de que si utiliza MSBuild a cree un proyecto estándar C# o C++/CLI, verá que también pasa rutas absolutas a los archivos en las ubicaciones anteriores (intente examinar el registro de compilación). Lo hace NOT desea utilizar ensamblajes que no sean de referencia fuera de las ubicaciones anteriores excepto la ubicación heredada v2.0 que se muestra arriba.

Para más información sobre conjuntos de referencia: http://blogs.msdn.com/b/msbuild/archive/2007/04/12/new-reference-assemblies-location.aspx

Desafortunadamente, para realmente aprender las reglas para resolver estos lugares, usted tiene que arrastrarse en el archivo C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets. No está exactamente documentado públicamente. También tenga en cuenta que estas reglas de búsqueda/resolución NO son las mismas que las documentadas para csc.exe /reference o cl.exe /FU. Esas reglas parecen que tendrían tendencia a utilizar ensamblajes de tiempo de ejecución, no ensambles de referencia, lo que sería incorrecto.