Re: [CMake] Appending to the LINK_FLAGS target property ?

2011-07-22 Thread David Cole
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 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  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 
>> 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

Re: [CMake] Appending to the LINK_FLAGS target property ?

2011-07-22 Thread Glenn Coombs
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  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 
> 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

Re: [CMake] Appending to the LINK_FLAGS target property ?

2011-07-22 Thread Johan Björk
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  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


[CMake] Appending to the LINK_FLAGS target property ?

2011-06-27 Thread Glenn Coombs
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