MantisBT - CMake
View Issue Details
0013590CMakeCMakepublic2012-10-16 05:122013-10-07 10:04
Stephen Kelly 
Stephen Kelly 
normalminoralways
closedwon't fix 
CMake 2.8.9 
 
0013590: LINK_INTERFACE_LIBRARIES is used by STATIC libraries
The documentation of LINK_INTERFACE_LIBRARIES claims that the property is ignored for STATIC libraries.

Having experimented with building Qt statically, this does not seem to be the case (at least for IMPORTED STATIC libraries), so the documentation does not match the code.
No tags attached.
Issue History
2012-10-16 05:12Stephen KellyNew Issue
2012-10-16 06:44Brad KingNote Added: 0031241
2012-10-16 09:40Stephen KellyNote Added: 0031247
2012-10-16 10:42Brad KingNote Added: 0031248
2012-10-16 10:45Brad KingNote Added: 0031249
2013-03-13 12:11Stephen KellyNote Added: 0032607
2013-03-13 13:00Brad KingAssigned To => Stephen Kelly
2013-03-13 13:00Brad KingStatusnew => resolved
2013-03-13 13:00Brad KingResolutionopen => won't fix
2013-10-07 10:04Robert MaynardNote Added: 0034000
2013-10-07 10:04Robert MaynardStatusresolved => closed

Notes
(0031241)
Brad King   
2012-10-16 06:44   
You're mixing it up with the IMPORTED_LINK_INTERFACE_LIBRARIES property:

http://www.cmake.org/cmake/help/v2.8.9/cmake.html#prop_tgt:IMPORTED_LINK_INTERFACE_LIBRARIES [^]
"this property applies to all imported target types, including STATIC libraries"
(0031247)
Stephen Kelly   
2012-10-16 09:40   
Yes, you're right.

This actually relates to the discussion we had here recently too though:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=4922 [^]

If it is an intentional difference between the two properties, what is the reasoning? A non-imported static library target which uses LINK_INTERFACE_LIBRARIES will need to specify what it links to anyway, and that must be used as the link interface too, maybe?

I'm not sure the distinction makes sense. In the sense of QtCore at least, I can specify for third party users that the qtmain.lib static library is part of the LINK_INTERFACE for executables (in the future at least), even if QtCore is built statically. In a hypothetical where QtCore and qtmain.lib are built using CMake (statically) though, executables which are part of the same build-system would not be able to take advantage of that.

Is that intentional, or is it something I'll need to think about and maybe workaround when getting to that part of the target-property-generator-targets feature?
(0031248)
Brad King   
2012-10-16 10:42   
The distinction is intentional:

 http://www.cmake.org/cmake/help/v2.8.9/cmake.html#prop_tgt:LINK_INTERFACE_LIBRARIES [^]
 "This property is ignored for STATIC libraries."

For non-imported static libraries CMake has target_link_libraries() invocations for it that specify its dependencies.

In the C++ implementation within CMake the terminology refers to the target_link_libraries() calls accumulated for a target as its "link implementation" and the LINK_INTERFACE_LIBRARIES target property as its "link interface". For a static library the link interface is *always* the link implementation so it does not make sense to honor the property because it would conflict with tll().
(0031249)
Brad King   
2012-10-16 10:45   
One idea for the future is to implement target_link_libraries() to store the values directly in a LINK_LIBRARIES property for target types that link, but for static libraries directly in LINK_INTERFACE_LIBRARIES. Then always use the value of those properties instead of having separate C++ structures for either.
(0032607)
Stephen Kelly   
2013-03-13 12:11   
I think this can be closed now, right? We agreed not to change the semantic of 'the link implementation is the link interface for static libraries'.
(0034000)
Robert Maynard   
2013-10-07 10:04   
Closing resolved issues that have not been updated in more than 4 months.