[cmake-developers] New INTERFACE_LINK_LIBRARIES policy approach

Stephen Kelly steveire at gmail.com
Wed Dec 26 06:04:52 EST 2012


Hi,

I'm again quite confused by how many things you now want to change compared 
to what we were discussing before. 

I'll try again to deal with it in b(y|i)tesize chunks.

Brad King wrote:
> For STATIC libraries we can
> define that the PUBLIC/PRIVATE/INTERFACE keys are ignored for
> linking and that it always populates both LINK_LIBRARIES
> LINK_INTERFACE_LIBRARIES.

That also means that one can do this:

 add_library(libstatic STATIC ${srcs})
 set_property(TARGET libstatic APPEND PROPERTY LINK_LIBRARIES foo)
 # Warning: foo is not in the 'link interface' of libstatic.

It's quite a footgun. The existing semantic in CMake is 'for static 
libraries, the link implementation is the link interface'. 

I don't see the reason to change that semantic. Exporting the link 
implementation as the link interface is not that complicated. I'd also worry 
that there are other code-complications of trying to treat the link 
implementation as the link interface if it does not come from the property, 
and not otherwise.

I'd rather not change it. Why do you think it's important to try to change? 
You wrote that it allows projects to 'deal with the link interface for all 
targets the same way'. Can you post some code showing that benefit?

Thanks,

Steve.





More information about the cmake-developers mailing list