MantisBT - CMake
View Issue Details
0012652CMakeCMakepublic2012-01-03 15:492016-06-10 14:31
Sean McBride 
Kitware Robot 
normalminoralways
closedmoved 
CMake 2.8.7 
 
0012652: CMAKE_<LANG>_FLAGS are passed for linking too, but this causes warnings for compilation-only flags
Searching the archives, I see that CMake deliberately passes the CMAKE_<LANG>_FLAGS for linking too:

<http://www.cmake.org/pipermail/cmake/2010-July/038090.html> [^]

If I add -std=c++0x to CMAKE_CXX_FLAGS, then compilation is fine, but clang will warn when linking:

clang-3: warning: argument unused during compilation: '-std=c++0x'

For one's own projects, one could do something like:

SET_SOURCE_FILES_PROPERTIES(${MYCPPS} PROPERTIES COMPILE_FLAGS --std=c++0x)

But my hope was to use --std=c++0x on my CMake/VTK/ITK dashboards to make sure their codebases are foreword-compatible with the new language standard.

Above all, it seems weird that something named CMAKE_C_FLAGS is passed to the linker when we already have CMAKE_EXE_LINKER_FLAGS and the like.

I realize changing this has compatibility implications.
No tags attached.
Issue History
2012-01-03 15:49Sean McBrideNew Issue
2012-01-03 16:23David ColeTarget Version => CMake 2.8.8
2012-01-03 16:32Brad KingNote Added: 0028151
2012-02-21 16:07David ColeStatusnew => backlog
2012-04-19 08:41David ColeTarget VersionCMake 2.8.8 =>
2012-04-19 08:42David ColeNote Added: 0029233
2012-10-18 04:35Amine ChadlyNote Added: 0031257
2016-06-10 14:28Kitware RobotNote Added: 0041952
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0028151)
Brad King   
2012-01-03 16:32   
We have always had to pass compilation flags to the compiler front-end when using it for linking. It matters at least for C++ because some compilers actually do real compilation at link time to do template instantiation (pre-linker). Since we've always done it for that reason we don't know where else it matters.

The behavior would have to be configured on a per-flag, per-toolchain basis. This is non-trivial. It really requires the long-requested feature of abstracting all optional behavior into properties that get mapped to flags as implementation details.
(0029233)
David Cole   
2012-04-19 08:42   
Unset target version... This is not going to change unless somebody has a concrete proposal that "fixes it" but also preserves backward compatibility for the cases where the flags are required for linking...
(0031257)
Amine Chadly   
2012-10-18 04:35   
What do you think of using a CMAKE_COMPILE_FLAGS_TO_LINKER or whatever cooler name you can come up with ? We could use it as a Boolean (true by default to keep today's behavior) that appends (or not) the compiler flags to the linker

Or we could use CMAKE_COMPILE_AND_LINK_FLAGS to specify flags that would be appended to both CMAKE_CXX_FLAGS and CMAKE_EXE_LINKERS_FLAGS.

Hope this helps.
(0041952)
Kitware Robot   
2016-06-10 14:28   
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.