Appending to the LINK_FLAGS target property ?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Appending to the LINK_FLAGS target property ?

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
Reply | Threaded
Open this post in threaded view
|

Re: Appending to the LINK_FLAGS target property ?

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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Appending to the LINK_FLAGS target property ?

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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Appending to the LINK_FLAGS target property ?

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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