[CMake] Private dependencies of static libraries exported as targets

[Nicholas Braden]

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.

On Wed, Aug 17, 2016 at 4:11 AM, Ivan Shapovalov <intelfx at intelfx.name> wrote:
> On 2016-08-16 at 20:14 -0500, Nicholas Braden wrote:
>> Ah, I misunderstood what you were asking about. It would be pretty
>> weird if CMake didn't know that static libraries always need all
>> their
>> dependencies linked regardless of privacy, but I agree it should at
>> least be mentioned somewhere. My bad.
>>
>> As for include path bloat, I cannot replicate this in my test project
>> - CMake will link all the dependencies as required but will NOT
>> violate "PRIVATE" for other things like include directories. Could
>> you
>> give an example where you are seeing a static library's private
>> dependency's include path being added when linking the static
>> library?
>
> Please take a look at https://github.com/intelfx/cmake-demo. This is a
> sample dependency chain of two libraries and one executable (client ->
> foo -> bar), both libraries are found and linked as IMPORTED targets.
> The client is built with VERBOSE=1 -- notice the compiler command
> lines.
>
> On my system it says (pretty self-explanatory):
>
> /usr/bin/c++    -isystem /home/intelfx/devel/__auxiliary/experiments/cmake-static-transitive/prefix/foo/include -isystem /home/intelfx/devel/__auxiliary/experiments/cmake-static-transitive/prefix/bar/include   -o CMakeFiles/client.dir/src/
> main.cpp.o -c /home/intelfx/devel/__auxiliary/experiments/cmake-static-transitive/client/src/main.cpp
>
> --
> Ivan Shapovalov / intelfx /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake-private-static-dependencies.zip
Type: application/zip
Size: 1503 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160817/20a9df13/attachment.zip>