(0015844)
James Bigler (developer)
2009-03-30 01:53

Can't you simply add the /EHsc or /EHa flag to you CMAKE_C_FLAGS or CMAKE_CXX_FLAGS?

(0015853)
Darryl Melander (reporter)
2009-03-30 14:02

I've come pretty close:

STRING(REPLACE "/EHsc" "/EHa" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
STRING(REPLACE "/RTC1" "" CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG})
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /clr")

The compiler seems to be doing the right thing now, although the project is still not flagged as a CLR project in the Visual Studio project properties window.

(0017463)
Bill Hoffman (manager)
2009-09-14 14:31

This should work with the flags in VS 2010.... Those values must be missing from the flag map in 2008. For 2010 the flag table is generated from a MS .xml file, so it is always complete.

(0025574)
Peter Schregle (reporter)
2011-02-24 10:50

The issue is still there with VS 2010.

Darryl Melanders changes do not flag the project as CLR in the Visual Studio properties.

Is there some workaround?

(0029844)
David HUnter (reporter)
2012-06-27 12:14

For extra information I did write up some stuff on MSBuild/VS property sheet usage in CMake here http://www.cmake.org/pipermail/cmake/2011-December/048030.html. [^] This includes building CLR code.

I have been using the string replace method mentioned above as a work around, however I recently discovered that this work around fails if you want to use /CLR:safe. /CLR:safe requires no C calling convention to be set but the calling convention /Gd is set deep in the bowls of MSBuild and is not present in flags like CMAKE_CXX_FLAGS and so can't be removed.

(0032673)
Matthew Bentham (reporter)
2013-03-19 09:14
edited on: 2013-03-20 10:53

The problem I've found, is that while CMake sets the "Common Language RunTime Support" option in the C/C++ section of the configuration properties if "/clr" is in the CXX_FLAGS, it does not set the "Common Language RunTime Support" in the general configuration properties, and that causes problems with linking/.NET references.

I've attached the patch that we're using internally for setting the CLR configuration property, in the hope that someone else will find it useful.

We have found that this is necessary in order to make certain .NET references work correctly, for example to avoid problems with warning C4945 when referencing System.dll.

The patch uses the flag map, so it works for projects setting '/clr' via the CMAKE_CXX_FLAGS as described above, and no further change is needed to CMakeLists.txt.

(0041529)
Kitware Robot (administrator)
2016-06-10 14:27

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2009-03-27 18:24	Darryl Melander	New Issue
2009-03-30 01:53	James Bigler	Note Added: 0015844
2009-03-30 14:02	Darryl Melander	Note Added: 0015853
2009-09-14 14:31	Bill Hoffman	Note Added: 0017463
2009-09-14 14:31	Bill Hoffman	Status	new => assigned
2009-09-14 14:31	Bill Hoffman	Assigned To	=> Bill Hoffman
2011-02-24 10:50	Peter Schregle	Note Added: 0025574
2012-06-27 12:14	David HUnter	Note Added: 0029844
2013-03-19 09:08	Matthew Bentham	File Added: configurationCLRSupport.patch
2013-03-19 09:14	Matthew Bentham	Note Added: 0032673
2013-03-20 10:51	Matthew Bentham	Note Edited: 0032673
2013-03-20 10:53	Matthew Bentham	Note Edited: 0032673
2016-06-10 14:27	Kitware Robot	Note Added: 0041529
2016-06-10 14:27	Kitware Robot	Status	assigned => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:30	Kitware Robot	Status	resolved => closed

Notes
(0015844) James Bigler (developer) 2009-03-30 01:53	Can't you simply add the /EHsc or /EHa flag to you CMAKE_C_FLAGS or CMAKE_CXX_FLAGS?

(0015853) Darryl Melander (reporter) 2009-03-30 14:02	I've come pretty close: STRING(REPLACE "/EHsc" "/EHa" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}) STRING(REPLACE "/RTC1" "" CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG}) SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /clr") The compiler seems to be doing the right thing now, although the project is still not flagged as a CLR project in the Visual Studio project properties window.

(0017463) Bill Hoffman (manager) 2009-09-14 14:31	This should work with the flags in VS 2010.... Those values must be missing from the flag map in 2008. For 2010 the flag table is generated from a MS .xml file, so it is always complete.

(0025574) Peter Schregle (reporter) 2011-02-24 10:50	The issue is still there with VS 2010. Darryl Melanders changes do not flag the project as CLR in the Visual Studio properties. Is there some workaround?

(0029844) David HUnter (reporter) 2012-06-27 12:14	For extra information I did write up some stuff on MSBuild/VS property sheet usage in CMake here http://www.cmake.org/pipermail/cmake/2011-December/048030.html. [^] This includes building CLR code. I have been using the string replace method mentioned above as a work around, however I recently discovered that this work around fails if you want to use /CLR:safe. /CLR:safe requires no C calling convention to be set but the calling convention /Gd is set deep in the bowls of MSBuild and is not present in flags like CMAKE_CXX_FLAGS and so can't be removed.

(0032673) Matthew Bentham (reporter) 2013-03-19 09:14 edited on: 2013-03-20 10:53	The problem I've found, is that while CMake sets the "Common Language RunTime Support" option in the C/C++ section of the configuration properties if "/clr" is in the CXX_FLAGS, it does not set the "Common Language RunTime Support" in the general configuration properties, and that causes problems with linking/.NET references. I've attached the patch that we're using internally for setting the CLR configuration property, in the hope that someone else will find it useful. We have found that this is necessary in order to make certain .NET references work correctly, for example to avoid problems with warning C4945 when referencing System.dll. The patch uses the flag map, so it works for projects setting '/clr' via the CMAKE_CXX_FLAGS as described above, and no further change is needed to CMakeLists.txt.

(0041529) Kitware Robot (administrator) 2016-06-10 14:27	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Relationships