[CMake] target_link_libraries - private public interface rules

[Miller Henry]

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.maynard at kitware.com] 
Sent: Tuesday, August 22, 2017 9:46 AM
To: Miller Henry <MillerHenry at JohnDeere.com>
Cc: cmake at 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 <MillerHenry at 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