For variables like CMAKE_C_FLAGS one can append to them like this: set(CMAKE_C_FLAGS "${CMAKE_CFLAGS} -some_option")
For target properties like LINK_FLAGS I was using this command: set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS /NODEFAULTLIB:"LIBCMT") to do the append. However, when I append a second time: set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS /INCLUDE:_InitLibrary) then it breaks because the string that Visual Studio sees contains a semicolon in between the 2 options. I can work round this by writing my append like this: get_property(link_flags TARGET myDLL PROPERTY LINK_FLAGS) set(link_flags "${link_flags} /INCLUDE:_InitLibrary") set_target_properties(myDLL PROPERTIES LINK_FLAGS ${link_flags}) but that is a bit verbose for my liking. I understand that the semicolons are how cmake separates list items from one another but shouldn't cmake automatically stringify the list (by replacing semicolons with spaces) before passing it through to the generator code ? The same problem will occur for any of the XXX_FLAGS properties like COMPILE_FLAGS that are passed through unchanged to the makefile or Visual Studio project file. Is it worth filing a feature request to ask for cmake to stringify lists for the appropriate variables ? Or is there a good reason why cmake can't or shouldn't implement this behaviour ? -- Glenn
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake