[CMake] Private dependencies of static libraries exported as targets

[Nicholas Braden]

Ah! When I do that, it also solves the include path bloat issue. No
longer does `client` know about the include directory of `bar`. Seems
it was a difference in minimum CMake version respecting old behavior.

In FooTargets.cmake, I see this line:
INTERFACE_LINK_LIBRARIES "\$<LINK_ONLY:bar>"

Awesome. Of course, this only helps Ivan if they can use CMake >= 3.0
- still good to know that the solution is simple.

On Thu, Aug 18, 2016 at 8:29 AM, Tamás Kenéz <tamas.kenez at gmail.com> wrote:
> Ivan,
>
>> But, if library `foo` is built as static, then its clients suddenly
>> become required to link to `bar` as well, and this information is not
>> recorded anywhere!
>
> I changed the cmake_minimum_required version in your projects from 2.8 to
> 3.0 which fixed the issue.
> (I tried it with cmake 3.6.1)
>
> Tamas
>
> On Wed, Aug 17, 2016 at 2:55 PM, Ivan Shapovalov <intelfx at intelfx.name>
> wrote:
>>
>> 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 /
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>
>