[cmake-developers] Policy CMP0043

[Stephen Kelly]

Steve Wilson wrote:
> While I didn’t see a
> specific policy for COMPILE_FLAGS moving to COMPILE_OPTIONS, the sources
> seem to indicate that COMPILE_FLAGS_<Config> (and indeed the use of
> COMPILE_FLAGS) will be deprecated in favor of COMPILE_OPTIONS and the
> newer methods of modifying COMPILE_OPTIONS such as
> target_compile_options().    

That may indeed happen at some point in the future. COMPILE_OPTIONS is a 
list of items which are properly escaped, while the COMPILE_FLAGS is a raw 
string and you have to manage the whitespace. There are also language-
specific CMAKE_<LANG>_FLAGS_<CONFIG> which would probably need to be cleaned 
up first (that's on my TODO 
 
 http://osdir.com/ml/kde-buildsystem/2014-01/msg00022.html

). Lang specific flags will need to be passed to files of specific language.

> Of course I would assume that LINK_FLAGS and
> LINK_FLAGS_<Config> would go this route as well.   I noticed however that
> target_link_options() does not exist.    Two questions:
> 
> 1. Is there a plan to move LINK_FLAGS to a LINK_OPTIONS replacement and
> provide a target_link_options() command?  

Vaguely. I haven't done it because I don't set them very often. It was part 
of the initial plans and discussions around usage requirements though.

> (BTW, where could I find the
> master feature plans and timetables?)

 http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements

> 
> 2.  If so, is someone already working on this implementation?

Nope.

> If not, I’ve started an implementation branch of my own, but realized I
> probably shouldn’t walk too far down that road without getting answers for
> these two questions.
> 
> Thanks,
> 
> Steve

Great!

Thanks,

Steve 

(we may have to disambiguate ourselves at some point :) )