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

[Alexander Neundorf]

On Friday 19 July 2013, Stephen Kelly wrote:
> Stephen Kelly wrote:
> > 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'.
> 
> To be more clear. I'm saying only what CMake requires. Public dependencies
> (if correctly listed) can't be removed or changed without breaking binary
> compatibility.
> 
> For policy of what to do in KF5, don't ask me :). I prefer minimalism but
> I'll let others figure out what to do there.

As everybody probably knows in the meantime, I prefer making things obvious 
and explicit. This may need somewhat more code, but makes it easier to 
understand and maintain.

In this case: if C directly uses A and B, I would prefer to list both as 
dependencies for C, instead of relying on the fact that the author knows that 
A will be dragged in via B.


What happens if you would hide the dependency from C to A ?

Maybe B at some point does not use A anymore, then C will not build anymore 
because A is missing.
Without listing A, a patch is needed to make C build again (although C was not 
changed):
-target_link_libraries(C B)
+target_link_libraries(C B A)

Or if I refactor C and port it away from B (but still use A), if I simply 
remove B from the dependencies it will not build anymore, because A is 
missing.
Without listing A, the patch would be
-target_link_libraries(C B)
+target_link_libraries(C A)
which looks like "I replaced B by A". With listing A, the patch would be 
-target_link_libraries(C B A)
+target_link_libraries(C A)
which IMO clearly says "C doesn't use B anymore".

Or somebody else reads the code (who does not know that B drags in A) and does 
not see A listed as dependency, he may think that C does not depend on A, or 
only accidentially depends on A.

So, yes, I'm for clearly stating the public dependencies.

Alex