[cmake-developers] Policy for INTERFACE_LINK_LIBRARIES

[Stephen Kelly]

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.