Brad King wrote: > On 12/03/2012 11:23 AM, Stephen Kelly wrote: >> If the policy is NEW and I export a static library, then >> only IMPORTED_LINK_INTERFACE_LIBRARIES(_<CONFIG>) will be on the >> generated IMPORTED targets (as is my understanding - I have not tried >> this). > > Correct, but please test if you have a chance. Also, try hacking the > ExportImport test's Export side to set the policy to NEW. The test > should still pass. > >> If I then try to use that IMPORTED target, the >> IMPORTED_LINK_INTERFACE_LIBRARIES(_<CONFIG>) will be ignored, and the >> INTERFACE_LINK_LIBRARIES will also not give me anything useful (because >> it does not exist, despite upstream using CMP0019 == NEW), though it >> would be populated in a future CMake release. > > The policy doesn't affect the dependents directly anymore. In > cmTarget::ComputeImportInfo we no longer look at its setting. > Therefore the old name will be used because the new name is not > set.
Ok, but that's dependent on the version of CMake used to generate the Config file. CMake 2.8.11 and 2.8.12 could generate different content for static libraries which could have a different result on downstream. Anyway, I think the discussion is moot. As you wrote, you're not going to merge the INTERFACE_LINK_LIBRARIES topic until the LINK_LIBRARIES topic is ready to merge too. Once that's in it will be easy to add the fix for the static library case, so we can ensure that it's in the same release. Another patch that I think should go into the same release as the one that introduces INTERFACE_LINK_LIBRARIES and the policy is the patch to make FindQt4.cmake include the Windows-specific qtmain.lib in the INTERFACE_LINK_LIBRARIES of QtGui. I would like that inclusion to be the default, so that people don't have to do set(QT_LINK_IN_QTMAIN ON) find_package(Qt4) or similar. Having that change in the same release as the one that introduces the policy means that the downstream only gets the qtmain.lib linked in if the policy is NEW. We could even emit a warning from FindQt4 if the policy is WARN. Otherwise, we probably can't add it to the INTERFACE_LINK_LIBRARIES in a future release by default, and downstream will have to do something like above (cf QT_USE_IMPORTED_TARGETS). I think it might make sense to try to get all of it in at the beginning of a release cycle for a future cmake release, and not plan to get any of it into 2.8.11. That takes pressure off. Actually I just yesterday discovered a problem with my goal of linking qtmain.lib into executables on Windows automatically. If using QtActiveQt, qtmain.lib should not be linked in (because activeQt supplies its own WinMain function). I don't think there is currently a way to express that in a generator expression. Maybe a genex like $<IS_LINKED:Qt::ActiveQt> ($<IS_LINKED:file_or_target>) would be possible, but it would require further discussion. 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
