[CMake] target_link_libraries - private public interface rules

[Robert Maynard]

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
<MillerHenry at 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.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