[CMake] Link options not transitive

[Robert Maynard]

You should report this on the CMake issue tracker:
https://gitlab.kitware.com/cmake/cmake/issues/

On Sat, Nov 23, 2019 at 12:03 PM Martin Krošlák <kroslakma at gmail.com> wrote:
>
> Hi,
>
> I have recently encountered what I believe might be a bug, where
> INTERFACE_LINK_OPTIONS are not carried over static libraries.
> Following is the simplest CMakeLists.txt that demonstrates the
> problem:
>
> cmake_minimum_required(VERSION 3.16)
> project(LinkOptionsNotTransitive)
> add_library(A SHARED A.cpp)
> add_library(B STATIC B.cpp)
> add_executable(C C.cpp)
> target_link_options(A INTERFACE "/DELAYLOAD:A.dll")
> target_link_libraries(B PRIVATE A)
> target_link_libraries(C PRIVATE B)
>
> I tested this with Visual Studio 2017 generator and both cmake 3.15.4
> and 3.16.0-rc4, with the same result.
>
> When inspecting generated solution, C is linking both A.lib and B.lib
> (as it should), but /DELAYLOAD flag is not applied to it. If B has
> PUBLIC dependency on A, then /DELAYLOAD flag is also correctly carried
> over. I get the impression that target_link_options behaves as eg.
> target_include_directories, which are not carried over PRIVATE
> dependencies. Given that these are linker options, I would expect them
> to follow same rules as target_link_libraries, which will carry over
> until nearest linker invocation. Is there any reason for this
> inconsistency, or is it just a bug and if so, what would be the best
> way to report it?
>
> --
> Sincerely,
> Martin Krošlák
> --
>
> Powered by kitware.com/cmake
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services
>
> Visit other Kitware open-source projects at https://www.kitware.com/platforms
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
> This mailing list is deprecated in favor of https://discourse.cmake.org