[cmake-developers] push of LinkOptionsCommand topic branch

[Stephen Kelly]

Brad King wrote:

> What is the status of this topic currently?  It adds a great feature!

I've been waiting for master to re-open for features before working on it. 

Here are some open issues:

1) INTERFACE_LINK_OPTIONS presents a new issue that was not present before 
with the LINK_FLAGS. If I understand correctly, if I set LINK_FLAGS on a 
static library, the contents are passed to the archiver (CMAKE_AR), whereas 
if I set it on a shared library or executable the contents are passed to the 
linker (CMAKE_LINKER). So, we can't have code as simple as:

 add_library(foo STATIC foo.cpp)
 target_link_options(foo INTERFACE --no-undefined)

but require:

 add_library(foo STATIC foo.cpp)
 set (_exe $<STREQUAL:$<TARGET_PROPERTY:EXECUTABLE>>)
 set (_shlib $<STREQUAL:$<TARGET_PROPERTY:EXECUTABLE>>)
 target_link_options(foo INTERFACE 
   $<$<OR:${_exe},${_shlib}>:--no-undefined>
 )

Consider splitting the use-cases and adding both {INTERFACE_,}LINK_OPTIONS 
and {INTERFACE_,}ARCHIVE_OPTIONS instead.

2) Should linker options or compiler driver options be specified in the 
LINK_OPTIONS? That is

 --no-undefined

or 

 -Wl,--no-undefined

My preference currently is the former, and have CMake do transformation if 
passing options to the compiler driver, assuming cmake can tell the 
difference between that and an actual linker.

Thanks,

Steve.