[cmake-developers] Policy for INTERFACE_LINK_LIBRARIES

[Stephen Kelly]

Brad King wrote:
> Well, we want generator expressions in tll() to work for static
> libraries.  Therefore we must populate INTERFACE_LINK_LIBRARIES
> for IMPORTED targets generated from static libraries.  However,
> in the producing (exporting) project it does not make sense to
> have separate LINK_LIBRARIES and INTERFACE_LINK_LIBRARIES for
> static libraries.  The property must remain undefined for static
> libraries just as LINK_INTERFACE_LIBRARIES is now.


add_library(picon STATIC libone.cpp)
add_library(picoff STATIC libtwo.cpp)
target_link_libraries(picoff LINK_INTERFACE_LIBRARIES picon)

get_target_property(_res picoff LINK_INTERFACE_LIBRARIES)
message("PROP : ${_res}")

outputs this with cmake 2.8.9:

 PROP : picon

I don't know if that's a bug, or if you mean that the IMPORTED_ variant is 
never defined by export() or install(EXPORT). I can confirm that the 
property contents are not exported for static libraries.

> 
> Somehow the "link implementation" must be turned into
> IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG> and/or the new
> INTERFACE_LINK_LIBRARIES when exporting targets.

 add_library(picon STATIC libone.cpp)
 add_library(picoff STATIC libtwo.cpp)
 target_link_libraries(picoff picon)

causes the IMPORTED_LINK_INTERFACE_LIBRARIES_<CONFIG> of the IMPORTED picoff 
to contain picon with CMake 2.8.9, because 
cmExportFileGenerator::SetImportDetailProperties populates that with the 
link implementation in the case of static libraries.

Currently, in the add-INTERFACE_LINK_LIBRARIES-property branch, the 
INTERFACE_LINK_LIBRARIES property is read for static libraries if the policy 
is new, even though it is LINK_LIBRARIES that we want to read in the case of 
STATIC libraries. That can only really be addressed when my followup topic 
to introduce the LINK_LIBRARIES property is merged. The question is how to 
deal with that? 

I can update add-INTERFACE_LINK_LIBRARIES-property to skip reading 
INTERFACE_LINK_LIBRARIES for STATIC libraries, and then revert that later 
when LINK_LIBRARIES is in, or I could simply not add such a patch, in the 
understanding that the case for STATIC libraries will be handled in a future 
topic.

I prefer the latter.

> That must be
> built into ComputeLinkInterface if it is not already.  Again I'm
> not sure how to know when to not export the old interface.  In
> this case it is never set explicitly by the user.  Perhaps it can
> depend on whether the link implementation requires any generator
> expressions besides $<CONFIG:>.  Such expressions would not be
> representable in the old interface anyway.

Reading this again, I think I agree with that. I think it should be handled 
in a future topic though.

Thanks,

Steve.