PRIVATE target_link_libraries on header only imported library results in linkage requirement

Let’s assume I have a library that links privately to an imported, header only library:

FindAsio.cmake (unfortunately does not export itself)

add_library(asio::asio INTERFACE IMPORTED)
set_target_properties(asio::asio PROPERTIES
      INTERFACE_INCLUDE_DIRECTORIES ${Asio_INCLUDE_DIR}
      INTERFACE_COMPILE_DEFINITIONS ASIO_STANDALONE)

and then the project of choice:

add_library (fineftp all_my_sources.cpp)
add_library (fineftp::fineftp ALIAS fineftp)

target_link_libraries(fineftp
    PRIVATE
        asio::asio
        Threads::Threads
)

Exporting this library with CMake leads to the following statements in fineftpTargets.cmake:

add_library(fineftp::server STATIC IMPORTED)

set_target_properties(fineftp::server PROPERTIES
  INTERFACE_COMPILE_DEFINITIONS "ASIO_STANDALONE;__USE_FILE_OFFSET64=1"
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "\$<LINK_ONLY:asio::asio>;\$<LINK_ONLY:Threads::Threads>"
)

This requires the user to locate asio on their machine, too, though it’s a private requirement of a header only library, e.g. there will be no linkage.

Not locating asio as a consumer of fineftp-server leads to the following CMake Error.

CMake Error at CMakeLists.txt:9 (add_executable):
  Target "fineftp_example" links to target "asio::asio" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

How can I avoid this usage requirement? Is this a CMake bug? Or is it necessary because asio::asio could have other transitive dependencies which need to be linked?

The following project has this problem, try building / installing it and then building the samples against the installed version:

It is added to the list because fineftp is a static library. We could probably drop interface targets from the required export set of static and object libraries if the dependent target has no link interface (link options or link libraries).

Cc: @brad.king

See CMake Issue 15415 and its discussion of a possible workaround.

Ah thanks a lot for the feedback. I will try the workaround.