MantisBT - CMake
View Issue Details
0014640CMakeCMakepublic2013-12-09 08:592014-10-06 10:32
Arunmozhi 
 
normalminoralways
closedno change required 
CMake 2.8.12 
 
0014640: PRIVATE linking with target_link_libraries propagates "usage requirements" for static libraries
I have projects in the structure shown below

    module (EXECUTABLE)
       |
       \-- submodule (STATIC_LIBRARY)
               |
               \-- subsubmodule (STATIC_LIBRARY)

'submodule' links with 'subsubmodule' using PRIVATE linking as below

   target_link_libraries(submodule PRIVATE subsubmodule)

'module' links with 'submodule'. It is expected that the 'module' does not get the public include directories of 'subsubmod'. However we see this happening in cmake 2.8.12.

It is understood that the libraries linked with 'subsubmodule' are propagated to 'module' since 'subsubmodule' and 'submodule' are STATIC libraries. However this does not apply to the INCLUDE directories and COMPILE definitions.

We also note that for SHARED libraries, the PRIVATE linking works fine.
No tags attached.
tar example.tar (20,480) 2013-12-09 08:59
https://public.kitware.com/Bug/file/5011/example.tar
Issue History
2013-12-09 08:59ArunmozhiNew Issue
2013-12-09 08:59ArunmozhiFile Added: example.tar
2013-12-09 10:13Brad KingNote Added: 0034759
2013-12-09 12:53Stephen KellyNote Added: 0034762
2013-12-09 13:00Brad KingNote Added: 0034763
2014-03-06 10:39Brad KingStatusnew => resolved
2014-03-06 10:39Brad KingResolutionopen => no change required
2014-10-06 10:32Robert MaynardNote Added: 0036934
2014-10-06 10:32Robert MaynardStatusresolved => closed

Notes
(0034759)
Brad King   
2013-12-09 10:13   
I can reproduce this with 2.8.12.1 and CMake 'master' as of commit 0ea589fd.

The requirement to link static library dependencies but not bring in their usage requirements is supposed to be handled by the LINK_ONLY expression here:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTargetLinkLibrariesCommand.cxx;hb=v2.8.12.1#l391 [^]

Steve?
(0034762)
Stephen Kelly   
2013-12-09 12:53   
This is controlled by policy CMP0022. If you set the minimum version to 2.8.12, you get the required behavior.

There should possibly be a warning for this case. It's possible we decided not to warn about it though, I don't recall.
(0034763)
Brad King   
2013-12-09 13:00   
Re 0014640:0034762: Right, I didn't notice that the cmake_minimum_required(VERSION) call is not high enough. Patching all sources in the example with

 -CMAKE_MINIMUM_REQUIRED(VERSION 2.8.11)
 +CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12)

sets CMP0022 to NEW and generates the expected behavior.
(0036934)
Robert Maynard   
2014-10-06 10:32   
Closing resolved issues that have not been updated in more than 4 months.