The `Transitive Usage Requirements` section of the cmake-buildsystem documentation quickly covers this idea but it could be elaborated on. This might be a good place for a concrete example.
Any thoughts Brad? On Tue, Aug 22, 2017 at 11:31 AM, Miller Henry <millerhe...@johndeere.com> wrote: > Is that the right place to say things like > > If a header file contains > #include <OtherLibraryClassHeader.h> > Then OtherLibrary is probably candidate for PUBLIC, if the header contains > the predeclaration > class OtherLibraryClass; > then OtherLibrary should be PRIVATE? > > I'm not against putting that content in official cmake documentation, but it > seems like something that has never been done before. > > -----Original Message----- > From: Robert Maynard [mailto:robert.mayn...@kitware.com] > Sent: Tuesday, August 22, 2017 9:46 AM > To: Miller Henry <millerhe...@johndeere.com> > Cc: cmake@cmake.org > Subject: Re: [CMake] target_link_libraries - private public interface rules > > You could look at extending the official CMake documentation, specifically > the build system documentation ( > https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html ). > > The documentation is all in restructure text and we accept documentation > changes through our gitlab instance. > > cmake gitlab: https://gitlab.kitware.com/cmake/cmake > > build-system restructure page: > https://gitlab.kitware.com/cmake/cmake/blob/master/Help/manual/cmake-buildsystem.7.rst > > contribution guideline: > https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst > > On Tue, Aug 22, 2017 at 9:44 AM, Miller Henry <millerhe...@johndeere.com> > wrote: >> >> I’ve been playing with the private/public/interface keyword to >> target_link_libraries. It seems to me that WHAT they do is well >> documented, but nobody has ever actually documented what they correct >> rules of WHEN/WHY you should use any of them. After a lot of misstarts >> I think I’ve started to understand what the rules should be. I think >> they need to be written down someplace so that others don’t have to >> make the mistakes I have. Also it would be nice if others would look >> this list over to see what else might be overlooking. >> >> Can somebody point me to a good place to do this? Sending to the >> mailing list seems like a poor solution as corrections will not be easily >> findable. >> A wiki seems ideal, but which? KDE in particular should probably have >> these rules in their official requirements, but I’m not sure if they >> are the correct ones to own them. >> >> >> -- >> >> 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