Brad King wrote: > On 10/30/2013 11:20 AM, Brad King wrote: >> Also please add the corresponding test case and base the topic >> on v2.8.12~2 so we can merge it for 2.8.12.1 after it passes >> in 'next'. > > Thanks. It appears that ImplementationIsInterface bypasses the > checks for EXPORT_LINK_INTERFACE_LIBRARIES and produces the > IMPORTED_LINK_INTERFACE_LIBRARIES properties even when CMP0022 > is set to NEW.
cmake_minimum_required(VERSION 2.8.12.1) project(foo) add_library(foo SHARED foo.cpp) add_library(bar SHARED foo.cpp) target_link_libraries(bar foo) export(TARGETS foo bar FILE myTargets.cmake) It is not obvious to the user that they are causing their downstreams to depend on CMake 2.8.12. There was no warning about it (because there is no bug in the code), no build error and no export error. By populating INTERFACE_LINK_LIBRARIES instead, the result would be that downstreams require 2.8.12. If that's what you want I can change this when the policy is NEW. I think that's fine. If they care about their downstreams, they'd test or examine their export files when they bump their cmake version requirement. Or maybe I can export both INTERFACE_LINK_LIBRARIES and IMPORTED_LINK_INTERFACE_LIBRARIES. But then, when could we ever not export IMPORTED_LINK_INTERFACE_LIBRARIES? As this case is mostly just resulting from a 'very ingrained' pattern of not making the link interface explicit, I don't think it matters if we always export IMPORTED_LINK_INTERFACE_LIBRARIES in this case. We stop exporting it when the user makes their link interface explicit. However, if they do the migration to 2.8.12 (no output from cmake) and then later make their link interface explicit (no output from cmake), then downstream now require 2.8.12. I think that's fine. If they care about their downstreams they need to test or examine their export files in this case too. Or we could make it a CMP0022-NEW-error to export a target which has link dependencies and no explicit link interface and EXPORT_LINK_INTERFACE_LIBRARIES is not used. I think this is still my preference. Everything else is very messy. 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