[cmake-developers] push of LinkOptionsCommand topic branch

[Brad King]

On 02/19/2014 11:00 AM, Stephen Kelly wrote:
> I've been waiting for master to re-open for features before working on it. 

It is now open for post-3.0 development :)

> 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).

I don't think LINK_FLAGS are used for the archiver or librarian.
We have a separate STATIC_LIBRARY_FLAGS for that:

 http://www.cmake.org/cmake/help/v2.8.12/cmake.html#prop_tgt:STATIC_LIBRARY_FLAGS

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

Yes.  That will be consistent with LINK_FLAGS/STATIC_LIBRARY_FLAGS
but with better naming.

> 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.

Yes, that makes sense.  It may take some work in the platform info
file rule variables so that the generators can tell when they are
invoking the linker directly v. through a compiler, and what the
wrapper option (-Wl,) for the compiler should be.

Thanks,
-Brad