C++ / CLI и CMake

Я пытаюсь настроить проект C++/CLI с помощью cmake. Мне удалось сделать это с visual studio 2010, но теперь я работаю с устаревшим решением, для которого требуется visual studio 2008. В visual studio 2010 достаточно настроить мой cmake следующим образом:

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

когда я затем рассматриваю проект в visual studio 2010, я вижу все ссылки и включена "поддержка среды выполнения общего языка". Когда я пробую это в visual studio 2008, я не вижу никаких ссылок, и проект имеет значение "Нет поддержки Общеязыковой среды выполнения" если я затем посмотрю параметры компилятора, я увижу, что /clr передается компилятору. Однако я все еще получаю много ошибок компилятора, вероятно, потому, что ему не хватает ссылок. Кто-нибудь знает, как это правильно настроить?

9
.net c++-cli cmake

2 ответов

единственная" реальная " ссылка исходного кода на свойство VS_DOTNET_REFERENCES находится в исходном файле CMake Source / cmVisualStudio10TargetGenerator.cxx.

что это означает на практике: VS_DOTNET_REFERENCES реализуется только для генератора CMake для Visual Studio 2010 и любого из генераторов, которые наследуются от него. (Которые теперь существуют в последней версии CMake для VS 2012 и 2013...)

изменение исходного кода CMake для поддержки этого свойства ранее версии Visual Studio, вероятно, возможны, но на данный момент это еще не сделано.

6

как указывает @DLRdave, CMake делает это только для генератора Visual Studio 2010.

попробуйте это обходное решение вместо VS_DOTNET_REFERENCES для других генераторов:

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

для системных сборок, таких как System.dll, PresentationCore.dll, etc. вы должны предоставить полный абсолютный путь к компилятору через asmPath. Необходимо использовать ссылочные сборки, а не сборки, не установленные на компьютере. Например, для целевой платформы 3.5 в Visual Studio 2008 вам потребуется найдите указанный файл в этих каталогах в следующем порядке:

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

вы заметите, что если вы используете MSBuild для создания стандартного проекта C# или C++/CLI, вы увидите, что он также передает абсолютные пути к файлам в вышеуказанных местоположениях (попробуйте изучить журнал сборки). Ты не хотите использовать сборки без ссылок вне вышеуказанных местоположений, за исключением устаревшей версии v2.0 расположение показано выше.

подробнее о ссылочных сборках: http://blogs.msdn.com/b/msbuild/archive/2007/04/12/new-reference-assemblies-location.aspx

к сожалению, чтобы действительно узнать правила для решения этих мест, вы должны пресмыкаться в . Это не совсем публично задокументировано. также обратите внимание, что эти правила поиска / разрешения не совпадают с задокументированными для csc.exe /reference или cl.exe /FU флаги. Эти правила выглядят так, как будто они будут использовать сборки среды выполнения, а не ссылочные сборки - что было бы неверно.

1