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 <inte...@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 >
-- 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