For variables like CMAKE_C_FLAGS one can append to them like this:<br>
<br>
    set(CMAKE_C_FLAGS &quot;${CMAKE_CFLAGS} -some_option&quot;)<br>
<br>For target properties like LINK_FLAGS I was using this command:<br><br>    set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS /NODEFAULTLIB:&quot;LIBCMT&quot;)<br>
<br>to do the append.  However, when I append a second time:<br>
<br>    set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS /INCLUDE:_InitLibrary)<br>
<br>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:<br><br>    get_property(link_flags TARGET myDLL PROPERTY LINK_FLAGS)<br>
    set(link_flags &quot;${link_flags} /INCLUDE:_InitLibrary&quot;)<br>    set_target_properties(myDLL PROPERTIES LINK_FLAGS ${link_flags})<br><br>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&#39;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.<br>
<br>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&#39;t or shouldn&#39;t implement this behaviour ?<br><br>--<br>Glenn<br>
<br>