Header cleanup / Link interface (was kdewidgets: fix build)

[Stephen Kelly]

David Faure wrote:
>> 3. We have situation
>> 
>> a) framework A (public header use QObject and QWidget)
>> -> LINK_PUBLIC only to Qt5::Widgets? or both Qt5::Core and Qt5::Widgets?
> 
> I don't know if deps become part of it. I guess not, but I'm no expert.
> Stephen? Alex?

I say

 target_link_libraries(A LINK_PUBLIC Qt5::Widgets)

If B uses A, then it will do something like 

 target_link_libraries(B LINK_PUBLIC A)

that is, no need to list all public dependencies there, or for dependencies 
of B when using that etc. 

Qt5::Core is a public dependency of Qt5::Widgets (as is Qt5::Gui), so 
there's no need to try to be exhaustive with dependencies which cmake will 
add anyway. You only need to add 'leaf modules'.

>> b) framework B (public header use QObject and QWidget and classes from
>> frameworkA)
>> -> LINK_PUBLIC same as in framework A plus KF5::FrameworkA? or only to
>> KF5::FrameworkA because Qt5::Core and Qt5::Widgets are linked in
>> frameworkA?

Yes. I'm sure over time (and the further you get 'away' from Qt5::Core), 
people won't be listing it anyway.

>> in short LINK_PUBLIC libraries are propagated and LINK_PRIVATE are not?
>> :)

Yes, exactly. If B uses Qt5::Sql internally, you would use:
 
 target_link_libraries(B LINK_PUBLIC A)
 target_link_libraries(B LINK_PRIVATE Qt5::Sql)

or just 

 target_link_libraries(B LINK_PUBLIC A 
                         LINK_PRIVATE Qt5::Sql)

Thanks,

Steve.