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. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers