C++/CLI e CMake

Question

Sto provando a impostare un progetto C++/CLI usando cmake. Ho avuto successo facendo questo con Visual Studio 2010, ma ora sto lavorando con una soluzione di eredità che richiede Visual Studio 2008. In Visual Studio 2010, è sufficiente impostare il mio cmake come questo:

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() 

Quando Esaminerò quindi il progetto sotto Visual Studio 2010, posso vedere tutti i riferimenti e "Common Language Runtime Support" è attivato. Quando lo provo in Visual Studio 2008, non vedo alcun riferimento, e il progetto è impostato su "No Common Language Runtime Support" Se poi guardo le opzioni del compilatore, posso vedere/clr è passato al compilatore . Tuttavia ho ancora un sacco di errori nel compilatore, probabilmente perché mancano dei riferimenti. Qualcuno sa come configurarlo correttamente?

Answer 1

L'unico riferimento al codice sorgente "reale" della proprietà VS_DOTNET_REFERENCES si trova nel file di origine CMake Source/cmVisualStudio10TargetGenerator.cxx.

Ciò significa in pratica: VS_DOTNET_REFERENCES è implementato solo per il generatore CMake per Visual Studio 2010 e per qualsiasi generatore che ne eredita. (Che ora esistono nell'ultima versione di CMake per VS 2012 e 2013 ...)

La modifica del codice sorgente di CMake per supportare questa proprietà per le versioni precedenti di Visual Studio è probabilmente possibile, ma è lavoro ancora da fare a questo punto.

Answer 2

Come @DLRdave fa notare, CMake lo fa solo per il generatore di Visual Studio 2010.

Prova questa soluzione alternativa, invece di VS_DOTNET_REFERENCES per altri generatori:

# 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}") 

Per gli assiemi di sistema come System.dll, PresentationCore.dll, ecc Si dovrebbe fornire un percorso assoluto completo al compilatore tramite asmPath. È necessario utilizzare gli assembly di riferimento e non gli assembly non installati sul computer. A titolo di esempio, di un quadro obiettivo di 3.5 in Visual Studio 2008, avresti bisogno di cercare il file indicato in queste directory, in questo ordine:

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 

Avrete notato che se si utilizza MSBuild a costruisci un progetto C# o C++/CLI standard, vedrai che passa anche i percorsi assoluti ai file nelle posizioni sopra (prova ad esaminare il log di costruzione). È necessario NON si desidera utilizzare assembly non di riferimento al di fuori delle posizioni di cui sopra, fatta eccezione per la precedente posizione v2.0 mostrata sopra.

Per ulteriori informazioni su assembly di riferimento: http://blogs.msdn.com/b/msbuild/archive/2007/04/12/new-reference-assemblies-location.aspx

Purtroppo, per imparare veramente le regole di risoluzione di questi luoghi, si hanno a strisciare nel file C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets. Non è esattamente documentato pubblicamente. Si noti inoltre che queste regole di ricerca/risoluzione NON sono uguali a quelle documentate per i flag csc.exe /reference o cl.exe /FU. Sembra che queste regole tenderebbero a utilizzare gli assembly runtime, non gli assembly di riferimento, il che sarebbe scorretto.