On Wed, 11 May 2016 21:58:34 +1000 Craig Scott <craig.sc...@crascit.com> wrote:
[..] > If you were paying careful attention, you would have noticed that > when A links in B as PRIVATE, the include directories of B never > propagate to something linking to A, but if A is a static library, > then the *linking* of B behaves as though the relationship was > PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries > only applies to the *linking*, not to the other dependencies > (compiler options/flags and include search paths). The upshot of all > this is that if you select PRIVATE, PUBLIC or INTERFACE based on the > explanations in the dot points above, then CMake will ensure > dependencies propagate through to where they are required, regardless > of whether libraries are static or shared. This does, of course, rely > on you the developer not missing any dependencies or specifying the > wrong PRIVATE/PUBLIC/INTERFACE relationship. Thank you for you long explanation. It was exactly my understanding. So cmake 3.5.0 has a bug then because I don't see the behavior you describe. Have you seen my example I sent in my first mail? http://public.kitware.com/pipermail/cmake/2016-May/063382.html Include-dirs from B are propagated to C which links to A which itself linked privately to B. Should I file a bug? regards, -- Patrick. -- 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
