[CMake] Private dependencies of static libraries exported as targets

[Ivan Shapovalov]

On 2016-08-17 at 05:19 -0500, Nicholas Braden wrote:
> Huh, this is weird. It seems to be an issue with the export/import
> mechanism. If you make a project where everything is in the same
> CMakeLists.txt and there is no install step, there is no include
> directory pollution. See my attached project for example. On my
> system
> I run this to build:
> 
> mkdir build && cd build && cmake -G "MinGW Makefiles" .. && cmake
> --build . -- VERBOSE=1
> 
> When it builds main:
> 
> C:\MinGW\bin\g++.exe    @CMakeFiles/main.dir/includes_CXX.rsp
> -std=gnu++14 -o CMakeFiles\main.dir\main.cpp.obj -c
> C:\Users\LB\Code\cmake-private-static-dependencies\main.cpp
> 
> The entirety of the includes_CXX.rsp file:
> 
> -IC:/Users/LB/Code/cmake-private-static-dependencies/c
> 
> The project you provided definitely has the include directory
> pollution problem - the client includes_CXX.rsp file contains an
> -isystem directive for bar. It looks like the generated
> FooTargets-noconfig.cmake contains this line (setting properties on
> foo):
> 
> IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "bar"
> 
> I'm not fully sure but I think this is wrong because it is saying
> that
> bar is a public dependency. This seems to be an oversight in CMake,
> as
> there is no 'private' alternative of the above variable for imported
> targets - that is, there is no IMPORTED_LINK_LIBRARIES_NOCONFIG, thus
> there is no way for CMake to provide special treatment as in my
> example. It seems CMake literally converts private dependencies of
> static libraries to public dependencies only when using the export
> functionality.
> 
> ...and that's as much as I can figure right now. Can you confirm that
> my attached example doesn't exhibit the problem? If it doesn't have
> the include directory pollution problem, I'd be inclined to say it's
> a
> bug with the export/import functionality.

Indeed, your sample project does not exhibit include path bloat. So
this really looks like a limitation of CMake import/export mechanism
(I say limitation, not bug, because there are simply no target
properties detailed enough to allow this behavior).

There is a property IMPORTED_LINK_DEPENDENT_LIBRARIES_<config> which is
_almost_ what we want, but just for shared libraries.

-- 
Ivan Shapovalov / intelfx /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160817/968b1e2d/attachment.sig>