[CMake] Private dependencies of static libraries exported as targets

[Tamás Kenéz]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160818/55f04fcc/attachment.html>