[cmake-developers] Policy for INTERFACE_LINK_LIBRARIES

[Stephen Kelly]

Brad King wrote:

> Hi Stephen,
> 
> I've looked through the add-INTERFACE_LINK_LIBRARIES-property topic. 
> Unless I'm misunderstanding something I think we can simplify CMP0019
> quite a bit. What made it complicated in earlier discussions was a desire
> to generate and export INTERFACE_LINK_LIBRARIES even from projects that
> have not been modified
> to be aware of it.  

Yes, I think you might be right there.

> However, your implementation does not reflect this,
> which IMO is good.
> 
> In cmExport*.cxx you're generating INTERFACE_LINK_LIBRARIES only when
> CMP0019
> is NEW in the producing project.  Once the policy has been set to NEW then
> we know the project has been modified and can assume the authors are aware
> of
> CMake 2.8.11 and the policy.  In that case we can assume they set or
> dropped any old LINK_INTERFACE_LIBRARIES according to their own needs to
> support consuming projects and older CMake versions.
> 
> I think we can drop the consumer-side policy completely.  Consumers will
> load imported targets with the old and/or new interfaces specified as
> chosen by the
> producing project.
>
> CMake < 2.8.11 will just use the old interface.  CMake
> >= 2.8.11 will just use the new interface if it is available and otherwise
> fall
> back to the old.  The burden of compatibility with existing consumer
> releases falls on the authors modifying the producing project, just as
> with any other change they make.

Yes.

> 
> We can re-work CMP0019 to work purely in the producing (exporting)
> project.
> If the policy is set to OLD we export only the old interface.  If the
> policy
> is set to NEW then we export the old and new interfaces.  If the policy is
> not set then we evaluate/compare the interfaces and warn if they are
> different, but still export only the old interface.
> 
> I'm still not sure how we can eventually stop exporting the old interface.
> Perhaps the export() and install(EXPORT) commands can learn new options
> to specify the minimum supported version of CMake for their consumers.
> We can wait and tackle this later though.

I guess the old interface is not exported if it is unset, so if the producer 
stops populating the old interface, they stop exporting it too. The problem 
is we'd need to provide a way for them to not populate the old interface.

Having them port away from 

 set_property(TARGET foo PROPERTY LINK_INTERFACE_LIBRARIES_DEBUG bar)

is obvious, but what is not so obvious is that 

 target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar)

and 

 target_link_libraries(foo LINK_PUBLIC bar)

also populate that property and cause the old interface to be exported. That 
would be a mystery to someone who doesn't want to export the old interface 
anymore.

Maybe we can deprecate those (and introduce a warning on export if the 
policy is NEW) and introduce 

 target_link_libraries(foo INTERFACE bar)
 target_link_libraries(foo PRIVATE bar)
 target_link_libraries(foo PUBLIC bar)

Not INTERFACE_LINK_LIBRARIES, because tll() will soon be doing more than 
just linking. The names could in theory conflict with existing libraries, 
but we could also handle that while parsing the args with the same policy or 
a new one.

I would like to provide a way for people to not be setting the old 
properties at all anymore.

Thoughts on that?

Steve.