It was just committed a week ago... It's not even in 'master' -- but it should make it into 2.8.6...
On Fri, Jul 22, 2011 at 6:36 PM, Glenn Coombs <[email protected]>wrote: > Excellent. Do you know if this option was included in the recent cmake > 2.8.5 release, or will it not appear officially until 2.8.6 ? > > > On 22 July 2011 18:39, Johan Björk <[email protected]> wrote: > >> Glenn, >> >> An option APPEND_STRING was added, see >> http://public.kitware.com/Bug/view.php?id=12342 >> >> /Johan >> >> >> On Mon, Jun 27, 2011 at 4:47 PM, Glenn Coombs <[email protected]> >> wrote: >> > 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 >> > >> > > > _______________________________________________ > 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 >
_______________________________________________ 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
