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