View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015243CMakeCMakepublic2014-11-11 14:242016-06-10 14:31
ReporterRodrigo Hernandez 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformVS2013OSWindowsOS Version8.1
Product VersionCMake 3.0.2 
Target VersionFixed in Version 
Summary0015243: /EHs-c- or /EHs- /EHc- as COMPILE_FLAGS target property does not remove /EHsc from the global CMAKE_CXX_FLAGS
DescriptionSometimes when adding external projects replacing /EHsc with /EHs-c- to disable exceptions on CMAKE_CXX_FLAGS is not an option because it may break the external project, but when adding /EHs-c- or /EHs- /EHc- to the COMPILE_FLAGS property of the local project, the /EHsc flag remains, causing compiler command line warnings:

cl : Command line warning D9025: overriding '/EHs' with '/EHs-'
cl : Command line warning D9025: overriding '/EHc' with '/EHc-'

This does not seem to happen when /GR- is set, in that case the global flag from CMAKE_CXX_FLAGS seems to vanish.
Steps To Reproduceadd_executable( test test.cpp )
set_target_properties(test PROPERTIES COMPILE_FLAGS "/EHs-c- /D_HAS_EXCEPTIONS=0 /GR-")
Additional InformationThe provided file contains a minimal project on which the issue is reproduced.
TagsNo tags attached.
Attached Fileszip file icon NoExceptions.zip [^] (699 bytes) 2014-11-11 14:24

 Relationships

  Notes
(0037185)
Brad King (manager)
2014-11-11 14:33

 CMake does not have deep knowledge of the interaction of every flag with every other flag for every compiler. It is up to the project to pass the right flags to the right places.

You could use string(REPLACE) to drop the flag from CMAKE_CXX_FLAGS. Then add the appropriate explicitly to every target. With CMake 3.0 this can be simplified with target_compile_options, or even with add_compile_options:

 http://www.cmake.org/cmake/help/v3.0/command/add_compile_options.html [^]

with the flags wrapped in a generator expression that checks your own target property to decide which flag to use.
(0037211)
Rodrigo Hernandez (reporter)
2014-11-13 15:37

 Hi Brad, I considered a similar workaround, removing the flag from the global variable and just adding the negative flags to my target which is the one I have control over, I got errors because of the missing flags on some of the external targets because they use exceptions but no exception model was selected. I decided against manually adding the flags for two reasons, 1- I am lazy :) and it is busy work having to add the flags to each external target dependency 2- It would be overriding some external target flags with the default, which you may not even know it is what the target expects.
In the end I just added the compile flags and am living with the warnings as they are more of an annoyance rather than an issue of the flags reverting back.

In my opinion I think that anything that is implicitly set on CMAKE_CXX_FLAGS should be overridden by a target specific COMPILE_FLAGS, as is the case with -GR, I am not expecting CMake to as you put it "have deep knowledge of the interaction of every flag with every other flag for every compiler", but the handful it implicitly sets should have consistent behavior. Again this is just my opinion on the subject.

I'll take a look at the compile_options command, thanks.
(0037213)
Brad King (manager)
2014-11-13 16:01

 Re 0015243:0037211: I think ideally the exception handling flags need to be abstracted like the POSITION_INDEPENDENT_CODE flags are:

 http://www.cmake.org/cmake/help/v3.0/prop_tgt/POSITION_INDEPENDENT_CODE.html [^]

That way there can be a per-target setting that simply replaces the global default, and CMake would generate the proper flag once.

It isn't a huge task, but it is non-trivial.
(0037219)
Stephen Kelly (developer)
2014-11-13 18:09

 Or it could rather be a compile_feature. See item 5 here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10221 [^]
(0042664)
Kitware Robot (administrator)
2016-06-10 14:29

 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
2014-11-11 14:24 Rodrigo Hernandez New Issue
2014-11-11 14:24 Rodrigo Hernandez File Added: NoExceptions.zip
2014-11-11 14:33 Brad King Note Added: 0037185
2014-11-13 15:37 Rodrigo Hernandez Note Added: 0037211
2014-11-13 16:01 Brad King Note Added: 0037213
2014-11-13 16:01 Brad King Status new => backlog
2014-11-13 18:09 Stephen Kelly Note Added: 0037219
2016-06-10 14:29 Kitware Robot Note Added: 0042664
2016-06-10 14:29 Kitware Robot Status backlog => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team